摘要： 在 AI 运维实践中，很多人已经可以照抄照用 Nginx 配置片段，但对"这一行配置会怎样改变请求路径""内网 IP 在哪一层被用到"缺乏统一的理解。要稳定维护一套前后端分离、三节点部署的系统，需要先把完整访问链路讲清，再逐条拆解
server、location、proxy_pass等指令的含义。本文围绕一个典型部署形态展开：入口节点上运行 Nginx 并托管前端静态资源，业务节点上运行后端 Jar 包服务，数据节点上运行数据库和缓存。重点回答两个问题：(1) 浏览器或小程序发出的请求如何一步步到达后端服务；(2)proxy_pass http://内网IP:端口/...这行配置在做什么，location、root、index、try_files与接口转发之间如何协同。
一、完整访问链路：从浏览器 / 小程序到后端服务
在三节点架构下，从终端用户到后端服务的访问过程可以分为几个连续环节。
第一，用户在浏览器输入域名，或在微信小程序中触发网络请求。DNS 将域名解析为一台 ECS 的公网 IP，这台 ECS 上运行 Nginx。浏览器和小程序只感知到这个域名和对应的公网地址。
第二，请求到达 Nginx 后，Nginx 根据**listen（通常是HTTP指示的80端口） 和server_name判断该使用哪个 server 配置块，再根据 location 匹配 URL 路径，选择静态资源流程或接口转发流程。路径前缀在这里起到了"分类器"的作用，/ 视为静态页面入口，/prod-api/ 视为接口入口**。
第三，对静态页面请求，Nginx 在本机文件系统中查找目标文件。当找到对应文件时，Nginx 直接将文件内容返回给客户端。
第四，对接口请求，Nginx 匹配到接口前缀后，会根据 proxy_pass 配置，自行构造一个新的 HTTP 请求发往后端服务。这里使用的目标地址是"后端 ECS 在 VPC 内的内网 IP + 端口"，例如 http://192.168.88.102:8080/zzyl-admin/。在这一层，Nginx 作为客户端访问后端，节点之前的访问，是通过节点的IP进行的，可通过ip a或者云端控制台查看节点内网ip。如果 Nginx 和后端部署在同一台机器上，那么这个地址会写成 127.0.0.1:8080 或者 localhost:8080；如果后端是多台机器，还可以写成 upstream 里的多个内网 IP。
第五，后端服务接收请求后执行业务逻辑，并通过内网访问 MySQL、Redis 等组件。MySQL 负责结构化数据持久化，Redis 负责缓存热点数据和管理会话等。后端与这些组件之间同样使用 VPC 内网地址通信。
第六，后端生成响应并返回给 Nginx，Nginx 再将响应转发给浏览器或小程序。终端用户始终只与网关节点交互，对内部节点和内网 IP 无需感知。
二、server 块：用域名和端口划定站点边界
理解任何一段 Nginx 配置，通常从 server { ... } 这一层开始。server 块对应一个虚拟主机，用来描述某个域名与端口上的整体处理规则。
从运维角度看，一台物理服务器或一台 ECS 上，可以同时对外提供多个"网站"或"服务入口"。每个网站在用户眼中有独立的域名、端口、日志和处理规则，看上去像一台单独的主机。Nginx 用配置把这些逻辑上的"网站"划分开来，这个逻辑上的网站就称为一个"虚拟主机" 。一台 ECS 节点上通常只跑一个 Nginx 实例，但这个实例的配置文件中可以存在多段
server { ... }。
一个简化示例如下：
bash
server {
listen 80;
server_name example.com;
root /var/www/dist;
index index.html index.htm;
# 若干 location 配置
}其中，listen 80; 指定了监听的端口号，表示此配置负责处理发往 80 端口的 HTTP 请求。server_name example.com; 声明了对应的域名，Host 头为 example.com 的请求会落入该 server 块。root /var/www/dist; 与 index index.html index.htm; 在 server 级别给出了默认的静态资源根目录和首页文件名，用于后续静态资源查找。
从结构上看，server 块使用"域名 + 端口"的组合定义了站点边界 ，站点内部针对不同 URL 路径的处理则交给若干 location 子块实现。
三、location /：静态资源映射与前端路由兜底
在前后端分离项目中，location / 通常负责处理前端页面与静态资源请求。常见写法如下：
bash
location / {
try_files $uri $uri/ /index.html;
}结合前面在 server 里设置的 root /var/www/dist; 和 index index.html index.htm;，整个逻辑可以这样理解：当用户访问某个路径时，（1）Nginx 会先把这个路径当成一个静态文件名 去 /var/www/dist 下面查找，比如访问 /js/app.js，实际上去找的是 /var/www/dist/js/app.js；（2）如果访问的是 / 或者看起来像目录的路径，就按首页规则去找 index.html 这一类默认文件；（3）如果前两步都找不到任何真实文件，就执行 try_files 的兜底分支，把请求统一交给 /index.html。
这一点对单页应用非常关键，例如前端路由里有 /visual/detail/1 这个页面，用户在地址栏直接输入这个路径或在该页面刷新时，浏览器会向服务端请求 /visual/detail/1，Nginx 在磁盘上找不到对应静态文件，于是回退到 /index.html，重新加载前端应用，让前端路由接管剩下的页面跳转。这样配置之后，有真实文件的路径正常返回文件，没有真实文件的路径全部回到入口页面，前端路由在用户刷新或分享链接时都能保持稳定访问体验。
四、location /prod-api/：接口前缀与 proxy_pass 的含义
接口请求往往通过统一前缀进行区分，例如 /prod-api/。在 Nginx 中可以为该前缀单独定义一个 location：
bash
location /prod-api/ {
proxy_pass http://192.168.88.102:8080/zzyl-admin/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
}这一段涉及路径映射和头部传递两个维度。
在路径层面，location /prod-api/ 会匹配所有以 /prod-api/ 开头的请求路径 ，例如 /prod-api/login、/prod-api/user/page。匹配成功后，请求进入代理逻辑。
proxy_pass http://192.168.88.102:8080/zzyl-admin/;定义了上游服务的访问地址。192.168.88.102是后端 ECS 节点在 VPC 内的内网 IP，8080是后端应用监听的端口，/zzyl-admin/是后端应用的上下文路径。
当前端调用 /prod-api/login 时，Nginx 会将其转发为 http://192.168.88.102:8080/zzyl-admin/login。这样，对外暴露的是 /prod-api/ 前缀，对内使用的是真实的应用前缀 /zzyl-admin/ 与私网地址（若有不懂，可见新篇04，具体讲解前端里的/prod-api：）：
-
浏览器 → Nginx：域名 +
/prod-api/login； -
Nginx → 后端：内网 IP +
/zzyl-admin/login。
在网络拓扑上，Nginx 所在节点与后端所在节点处于同一 VPC 内，可以通过 192.168.*.* 这样的私网地址直接通信。公网用户只能访问 Nginx 暴露的域名和端口，后端 ECS 的内网地址并不暴露在公网层。这种布局有利于控制攻击面和公网流量成本。
在头部层面，proxy_set_header 系列指令用于保持请求上下文信息。
proxy_set_header Host $host;维持原始 Host 头，便于后端识别访问域名。proxy_set_header X-Real-IP $remote_addr;与proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;将客户端真实 IP 及转发链路记录到头部，后端可以据此进行日志分析、限流与安全策略。proxy_set_header Upgrade $http_upgrade;与proxy_set_header Connection $connection_upgrade;支持 WebSocket 等协议升级场景，将升级相关信息传递给后端服务。
通过这一配置组合，Nginx 在接口转发过程中既完成了路径和地址映射，又保留了必要的请求上下文。
五、静态资源与接口转发：统一入口下的分工
当 location / 与 location /prod-api/ 同时存在时，Nginx 在同一个站点内部形成了一套清晰的分工机制。
以 /prod-api/ 为前缀的接口请求，统一进入反向代理逻辑，由 Nginx 使用内网 IP 和端口访问后端服务。其余路径优先视为静态资源请求，在 root 指定的目录下寻找文件，找不到时回落到 index.html，交由前端路由解释。
对于 AI 运维相关系统，这种"统一入口 + 内网转发"的结构使得新增模型服务、监控组件或管理后台时，只需要在 Nginx 中增加相应的 location 或 upstream 配置，无需频繁调整对外接口。
六、小结：从一条 proxy_pass 到一套配置框架
综合前文内容，可以将 Nginx 配置与内网转发的理解归纳为几条主线。
第一条主线是访问链路。从客户端视角看，所有请求都发往一个域名和端口；从服务端视角看，请求先交给 Nginx，再根据路径分为静态资源和接口请求，接口请求通过内网转发到后端，后端进一步访问数据库和缓存。
第二条主线是指令与行为的对应关系。server 决定站点的域名和端口边界，location 决定 URL 路径的分流方式 ，root 与 index 确定静态资源所在位置，try_files 处理前端路由的兜底，proxy_pass 建立 Nginx 与后端服务之间的转发关系，proxy_set_header 补充和传递请求上下文。
第三条主线是内外地址的分层使用。公网 IP 与域名用来对外提供统一入口，内网 IP 用于节点之间的服务访问，proxy_pass 将这两层连接起来，在保证后端节点隐蔽性的同时完成流量调度。
在后续的 AI 运维实践中，可以在这一基础上继续引入 HTTPS 证书、负载均衡 upstream 集群、健康检查与熔断等机制。只要抓住访问链路、配置语义和地址分层这三条主线，Nginx 相关的配置与演进就会保持清晰和可控。