很多人第一次配 Nginx ，都是从这几行开始的：
location /api/ {
proxy_pass http://127.0.0.1:3000;
}能跑。
但真出问题的时候，就开始懵了。
为什么浏览器访问的是 https://example.com/api/user，后端收到的路径变了？
为什么本地接口正常，经过 Nginx 就 502 ？
为什么后端拿不到真实 IP ？
为什么 WebSocket 一代理就断？
为什么上传文件过大， Nginx 先拦了？
这些问题背后，其实都指向同一件事：
反向代理不是简单转发请求，它是在客户端和后端服务之间重新组织访问路径。
什么是反向代理
先别急着背概念。
看访问路径。
没有反向代理时，客户端直接访问后端服务：
浏览器↓
后端服务
有反向代理后，路径变成：
浏览器
↓
反向代理
↓
后端服务浏览器以为自己访问的是 example.com。
但真正处理业务的，可能是内网里的：
127.0.0.1:3000
10.0.0.12:8080
api-service:9000反向代理站在前面，替后端接住外部请求，再把请求转给真正的业务服务。
所以“反向”是什么意思？
它不是站在客户端那边，替客户端访问外网。
它是站在服务端这边，替一组后端服务接收外部请求。
这就是反向代理。
正向代理和反向代理差在哪
正向代理代理的是客户端。
比如你在公司网络里访问外部网站，请求先经过代理服务器：
客户端
↓
正向代理
↓
目标网站目标网站看到的，通常是代理服务器。
反向代理代理的是服务端。
用户访问一个统一入口：
客户端
↓
反向代理
↓
后端服务 A / B / C客户端不关心后面有几台机器，也不知道请求最终落到哪个服务。
一句话：
正向代理：替客户端出去
反向代理：替服务端接客别笑。
这个说法土，但记得住。
Nginx 最常见在代理什么
Nginx 做反向代理，通常代理三类东西。
第一，代理路径。
比如：
location /api/ {proxy_pass http://127.0.0.1:3000/;
}
外部访问：
请求会被转到后端服务。
但这里有个很容易踩的坑：proxy_pass 后面有没有 /，行为不一样。
location /api/ {proxy_pass http://127.0.0.1:3000/;
}
这个会把 /api/ 替换掉。
而：
location /api/ {proxy_pass http://127.0.0.1:3000;
}
这个通常会保留原始 URI 。
一个斜杠，能让后端路由直接 404 。
第二，代理域名。
比如同一台 Nginx ，根据域名转发到不同服务：
server {server_name api.example.com;
location / {
proxy_pass http://127.0.0.1:3000;
}
}
server {
server_name admin.example.com;
location / {
proxy_pass http://127.0.0.1:4000;
}
}
用户看到的是不同域名，后端实际是不同端口。
第三，代理协议升级。
最典型的是 WebSocket 。
普通 HTTP 请求代理过去就结束了。
WebSocket 需要协议升级，所以要额外处理：
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";少了这些配置，前端可能连接上又马上断。
反向代理为什么常放在最前面
因为它适合做统一入口。
很多系统后端不止一个服务：
用户服务
订单服务
支付服务
管理后台
静态资源
文件服务如果每个服务都直接暴露公网，管理会很乱。
反向代理可以把入口收敛成一个：
example.com/api/user -> 用户服务
example.com/api/order -> 订单服务
example.com/admin -> 管理后台
example.com/static -> 静态资源它还能顺手做很多事：
HTTPS 证书终止
负载均衡
路径转发
域名转发
限流
访问控制
静态资源缓存
压缩
日志记录
灰度发布所以很多时候， Nginx 不只是“转发工具”。
它是系统的入口层。
入口层一错，后端再正常也没用。
后端为什么拿不到真实 IP
这是反向代理里最常见的问题之一。
因为后端服务收到的请求，不是用户直接发来的，而是 Nginx 转发来的。
所以后端看到的客户端 IP ，可能是：
127.0.0.1
10.0.0.1
Nginx 所在机器的内网 IP这时候要把真实来源传给后端：
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $host;几个头的含义：
X-Real-IP：当前直接连接 Nginx 的客户端 IP
X-Forwarded-For：经过的代理链路
X-Forwarded-Proto：原始协议，http 还是 https
Host：用户访问的原始域名但注意，后端不能无脑相信这些头。
如果你的服务直接暴露公网，用户可以自己伪造 X-Forwarded-For。
正确做法是：只信任来自可信代理层写入的头。
502 、 504 、 404 分别看什么
反向代理出问题，最常见是这几个状态码。
404 通常说明请求到后端了，但路径不对。
重点看：
location 是否匹配
proxy_pass 是否多了或少了斜杠
后端路由是否真的存在
前端 base path 是否配置正确502 通常说明 Nginx 找不到或连不上上游服务。
重点看：
后端服务是否启动
端口是否正确
upstream 地址是否能解析
容器网络是否通
防火墙是否拦截可以直接在 Nginx 机器上测：
curl -i http://127.0.0.1:3000/health如果这里都不通，问题不在 Nginx 。
504 通常是上游响应超时。
重点看：
后端是否处理太慢
proxy_read_timeout 是否太短
数据库或外部接口是否卡住
是否有长连接或大文件场景比如：
proxy_connect_timeout 10s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;不要一看到 504 就盲目把超时调大。
先确认后端为什么慢。
一个可用的基础配置
如果只是代理一个后端服务，可以从这个配置开始：
server {listen 80;
server_name example.com;
location / {
proxy_pass http://127.0.0.1:3000;
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 X-Forwarded-Proto $scheme;
proxy_connect_timeout 10s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;
}
}
如果代理 WebSocket ，再加：
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";如果有上传文件，再看：
client_max_body_size 50m;如果要避免缓存影响接口，注意：
proxy_buffering off;不是所有场景都要关。
但 SSE 、流式输出、部分长连接场景，会被缓冲坑到。
排查时按这条链路走
反向代理排障，不要一上来改配置。
先按访问路径查：
1. DNS 是否解析到 Nginx- 客户端是否能连到 Nginx
- Nginx server_name 是否命中
- location 是否命中
- proxy_pass 转发地址是否正确
- Nginx 机器能否访问上游服务
- 上游服务日志是否收到请求
- 响应是否被超时、限流、缓冲、大小限制拦截
几个命令很实用：
nginx -tnginx -T
curl -i http://127.0.0.1:3000/health
curl -i https://example.com/api/health
tail -f /var/log/nginx/access.log
tail -f /var/log/nginx/error.log
nginx -t 只能证明语法没错。
不代表转发链路正确。
这点和证书自动续期、内网穿透一样：
配置存在，不等于链路可靠。
最后怎么理解反向代理
反向代理不是“把请求转一下”这么简单。
它至少做了三件事：
接住入口
改写路径
转发到上游再往上，它还可能负责：
HTTPS
负载均衡
限流
鉴权
日志
缓存
灰度
长连接
上传限制所以 Nginx 这类反向代理，表面是配置文件，实际是系统入口的交通规则。
一条规则写错，后端服务可能完全没问题，但用户就是访问不了。
以后再看反向代理，不要只盯 proxy_pass。
要看完整路径：
用户请求从哪里来
Nginx 怎么匹配
路径有没有被改
请求头有没有传
上游服务是谁
响应怎么返回
失败时日志在哪里这条线理清楚， 502 、 504 、路径错乱、真实 IP 丢失、 WebSocket 断连，就不会再是一团乱麻。
评论 (0)