内容摘要：把 Nginx 当代理网关用，第一件要搞清楚的事不是配置文件怎么写，而是流量到底从哪个 IP 的哪个端口进来、又被转到哪里去。这个问题听起来简单，实际上一台机器上跑三四个 Nginx 实例、每个实例监

把 Nginx 当代理网关用，代理p端第一件要搞清楚的服务事不是配置文件怎么写，而是代理p端流量到底从哪个 IP 的哪个端口进来、又被转到哪里去。服务这个问题听起来简单，代理p端实际上一台机器上跑三四个 Nginx 实例、服务每个实例监听不同端口、代理p端后面还挂着若干后端服务的服务时候，光靠脑子记是代理p端记不住的。

我见过一个典型的服务翻车案例。某项目在测试环境用 8080 端口做网关入口，代理p端上线时运维改成了 80，服务但上游调用方那边的代理p端配置没同步更新，结果请求全部打在 8080 上，服务Nginx 压根没监听这个端口，代理p端直接 connection refused。排查了快两个小时，最后发现就是端口对不上。这种事不复杂，但足够让人抓狂。

listen 指令决定一切

Nginx 的 listen 指令是入口的锚点。写 listen 80; 意味着监听本机所有网卡的 80 端口。写 listen 192.168.1.10:8080; 就只绑定那个特定 IP 的 8080。差别很大——前者外部任何能路由到这台机器的请求都能进来，后者只有目标地址是 192.168.1.10 的才生效。

多网卡服务器上这点特别关键。一台机器同时有内网 IP 和公网 IP，如果网关只应该对内网提供服务，那就必须显式绑定内网 IP，否则公网流量也能打进来。我一般会建议在 listen 后面加上 so_keepalive=on 和 backlog=2048 这类参数，不是必须的，但高并发场景下能减少一些连接建立的开销。

proxy_pass 里的 IP 和端口才是真正干活的

入口搞定了，接下来是出口。proxy_pass 决定了请求被转发到哪个后端。写法有两种：带 URI 和不带 URI。

location /api/ {  proxy_pass http://10.0.0.5:3000; } 

这种写法会把 /api/user 原样转发成 http://10.0.0.5:3000/api/user。如果写成 proxy_pass http://10.0.0.5:3000/;，注意末尾那个斜杠，路径就变成了 http://10.0.0.5:3000/user，/api 被吃掉了。这个斜杠坑过太多人，我自己也踩过。

后端如果有多台机器，用 upstream 块来定义。每台机器的 IP 和端口列进去，Nginx 默认轮询转发。哪台挂了，默认情况下请求还是会打过去然后超时，得配合 max_fails 和 fail_timeout 才能自动踢掉。

upstream backend {  server 10.0.0.5:3000 max_fails=3 fail_timeout=30s; server 10.0.0.6:3000 max_fails=3 fail_timeout=30s; } 

怎么确认实际生效的 IP 和端口

配置文件写完了不代表就对了。我习惯用几个命令交叉验证。

ss -tlnp | grep nginx 看 Nginx 进程实际监听了哪些地址和端口。这个最直接，配置文件写错了这里一眼就能看出来。

nginx -T 把最终合并后的完整配置打印出来。include 了一堆文件的时候，这个命令能让你看到 Nginx 真正读到的内容，而不是你以为它读到的内容。

再就是 curl -v 直接打请求，看响应头里的 Server 字段和连接信息。如果前面还有一层 SLB 或者防火墙，curl 的结果和 ss 的结果可能对不上，这时候就得逐层排查了。

一个容易忽略的细节

Nginx 做代理时，转发给后端的请求默认用的是 HTTP/1.0，除非显式设置 proxy_http_version 1.1;。HTTP/1.0 不支持 keepalive，每次请求都要重新建立到后端的 TCP 连接。后端服务 QPS 一高，TIME_WAIT 状态连接堆积，端口耗尽，整个链路就瘫了。加上 proxy_set_header Connection ""; 配合 HTTP/1.1，才能复用长连接。

这个问题在低流量测试时根本暴露不出来，一上生产就炸。端口和 IP 配置对了只是第一步，协议版本和连接复用这些参数同样影响整条链路的稳定性。