Nginx 反向代理入门：把请求转发到正确的服务

平时我们部署一个 Web 服务时，常常会遇到这样的问题：服务本身只监听本机端口，对外却希望用户通过 80 端口访问；或者一台服务器上跑了好几个服务，希望按路径分发到不同的后端。这时最常用的办法，就是在前面加一层 Nginx 反向代理。

一、什么是反向代理
反向代理是站在服务端一侧的代理。用户请求先到达 Nginx，Nginx 再按规则把请求转发给真正的后端服务，后端处理完把结果返回给 Nginx，最后由 Nginx 交给用户。用户只看到 Nginx，并不知道后端长什么样。它和正向代理正好相反：正向代理是替客户端去访问外部服务，反向代理是替服务端接收外部请求。反向代理的好处很直接：隐藏后端细节、统一入口、做负载均衡、做缓存和限流，还能在入口处统一处理安全头。

二、一个最小可用的配置
先看最简单的形态。假设后端服务监听在本机 8000 端口，我们希望用户访问 80 端口时由 Nginx 转发过去：
upstream app_server {
    server 127.0.0.1:8000;
}
server {
    listen 80;
    location / {
        proxy_pass http://app_server;
    }
}
这里 proxy_pass 是核心指令，告诉 Nginx 把请求交给谁。upstream 把后端起一个名字，方便以后扩到多台机器做轮询。

三、按路径分发到不同服务
一台服务器跑多个服务很常见，比如接口服务和静态页面分开：
location /api/ { proxy_pass http://app_server; }
location / { proxy_pass http://web_server; }
请求路径以 /api/ 开头就去接口服务，其余去页面服务。这样做的好处是前端只需要记住一个入口，不用记一堆端口。

四、斜杠这个小细节最容易踩坑
proxy_pass 末尾有没有斜杠，转发结果完全不同。带斜杠会把 location 匹配到的前缀替换掉，不带斜杠会把原始路径原样追加。比如 location /api/ 加上 proxy_pass http://app_server/ ，用户请求 /api/users ，后端收到的是 /users 。如果写成 proxy_pass http://app_server （没有斜杠），后端收到的还是 /api/users 。到底用哪一种，要看后端路由本身带不带 /api 前缀。写错了最常见的现象就是后端返回 404，明明服务是通的，路径却对不上。

五、别忘了把真实信息传给后端
请求经过代理之后，后端看到的来源地址会变成 Nginx 自己的地址，拿不到真实用户地址，也不知道用户当初用的是哪种协议。所以通常要补上几行头：
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;
第一行保证后端拿到的域名不变，第二、三行把真实客户端地址传下去，第四行告诉后端原始请求是普通访问还是加密访问。做日志、限流和登录风控时，这些头都很关键。

六、常见坑与排查思路
第一，改完配置先做语法检查再重载，不要直接重启。第二，超时时间要结合后端耗时设置，默认超时太短会导致大请求被切断。第三，静态文件出现 404 时，先确认是 Nginx 自己的根目录配置错了，还是代理到后端的路径错了。第四，接口需要长连接时，要记得把连接升级相关的头一并转发，否则连接会反复断开。第五，多后端时先确认每个后端本身能直接访问，再怀疑代理配置。

七、一个简单的自查清单
入口端口是否监听、转发规则是否按预期命中、后端收到的路径是否和预期一致、真实地址和协议头是否传到、改完配置是否做了语法检查和重载。按这个顺序查，大多数反向代理问题都能在几分钟内定位。

反向代理本身并不复杂，难的是把请求路径、头信息和超时这些细节一次配对。先从一个最小配置跑通，再按路径分发、再补头信息，最后处理超时和长连接，一步步来，就能把请求稳稳地转发到正确的服务。