Nginx 反向代理基础：从转发规则到常见故障定位

很多新手第一次部署 Web 应用时，都会遇到一个问题：应用明明在本机跑得好好的，一放到服务器上，域名、端口、HTTPS 就变得一团乱。这时最常见的解法不是改应用，而是加一层 Nginx 反向代理。理解它的转发规则，能解决大部分上线初期的访问问题。

什么是反向代理

正向代理是替客户端去访问外部资源，反向代理正好相反：它站在服务端前面，替后端应用接收外部请求。浏览器只看到 Nginx 的地址，并不知道请求最终被转给了哪台内网服务器。这样做的好处很直接：一是隐藏后端结构，二是可以在一台服务器上用不同域名或路径区分多个应用，三是统一处理 HTTPS、缓存和访问控制。

一个最小可用的配置

假设后端应用监听在 127.0.0.1:3000，希望通过域名访问它，最小配置可以写成下面这样：

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_pass 决定请求去哪里，末尾有没有斜杠会影响路径拼接，改动前要先确认后端期望的路径。Host 头决定后端看到的域名，很多框架靠它生成链接或做域名校验，漏传容易出现跳转错乱。X-Real-IP 和 X-Forwarded-For 则让后端能拿到真实客户端地址，否则日志里全是 Nginx 自己的地址，排查问题时会很被动。

几个常用但容易写错的指令

location 的匹配顺序是新手最容易踩坑的地方。精确匹配优先于普通前缀匹配，正则匹配又在特定条件下优先于前缀匹配，写规则时不要只凭直觉，要用实际请求验证。静态资源可以单独写一个 location，设置较长的缓存时间；接口请求则不要缓存，或者只做短时间缓存，避免用户拿到过期数据。

超时时间也要根据业务调整。默认的连接超时和读取超时对普通网页够用，但对文件上传、大报表导出这类慢接口就不够，超时后用户看到的往往是 502 或 504，而不是后端真正的错误。改配置前先确认慢的是网络、后端处理还是数据库查询，否则盲目放大超时只会把问题拖得更久。

常见故障怎么定位

出现 502 时，先看 Nginx 错误日志，再确认后端进程是否存活、端口是否在监听。很多 502 只是后端重启或端口改了，Nginx 还在往旧地址转发。出现 404 时，先区分是 Nginx 返回的还是后端返回的，再检查 location 和 proxy_pass 的路径拼接是否多了一段或少了一段。出现跳转循环时，通常是 HTTPS 判断出了问题：Nginx 已经终止了 HTTPS，却没有把协议信息正确传给后端，后端以为还是 HTTP，于是反复重定向。

改完配置后，一定要先执行 nginx -t 检查语法，再平滑重载，不要直接重启服务。平滑重载可以在不断开已有连接的情况下生效，对线上用户影响最小。养成先看日志、再改一处、再验证一遍的习惯，比一次改很多地方更容易定位问题。

小结

反向代理的核心并不复杂：接收请求、按规则转发、把响应原样返回。真正需要经验的地方，是路径拼接、请求头传递、超时设置和日志定位这几个细节。把最小配置跑通，再逐步加上缓存、HTTPS 和访问控制，就能用一套稳定的入口管理多个后端服务。