nginx反向代理

Nginx 最常被提起的向代功能就是反向代理。你访问一个域名，向代请求先到 Nginx，向代再由它转给后面真正的向代应用服务器，用户端完全感知不到中间这层。向代这件事听起来简单，向代但实际用起来有几个点很容易踩坑。向代

先说个具体场景。向代假设你有一台服务器跑了三个 Node.js 应用，向代分别监听 3000、向代3001、向代3002 端口。向代对外只开放 80 和 443，向代不可能让用户直接访问这些高位端口。向代这时候 Nginx 就派上用场了——它监听 80，向代根据域名或路径把请求分发到不同的后端端口。

配置本身不复杂。一个最基础的 proxy_pass 长这样：

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

用户请求 yourdomain.com/api/users，Nginx 把请求转发到 127.0.0.1:3000/api/users。注意这里有个细节：proxy_pass 末尾有没有斜杠，行为完全不同。写 http://127.0.0.1:3000 和写 http://127.0.0.1:3000/，路径拼接结果不一样。这个坑我见过至少三个人踩过，包括我自己第一次配的时候。

反向代理不只是转发请求那么简单。它顺手解决了好几件事。后端服务器的真实 IP 不会暴露在公网上，安全性提升一截。SSL 证书只需要配在 Nginx 这一层，后端应用不用操心 HTTPS。静态文件交给 Nginx 直接返回，动态请求才转发给应用，性能差距很明显。我之前做过一个对比，同一个 CSS 文件，Nginx 直接返回和经过 Node.js 中间件返回，QPS 差了将近十倍。

代理头部信息也得留意。Nginx 转发请求时，默认会把 Host 头改成 proxy_pass 里写的地址。后端应用如果依赖原始 Host 做判断，就会出问题。解决办法是加一行：

proxy_set_header Host $host;

还有 X-Real-IP 和 X-Forwarded-For，这两个头用来传递用户的真实 IP。后端拿到的 remote_addr 其实是 Nginx 的 IP，不是用户的。做日志分析或限流的时候，不拿到真实 IP 基本没法干活。

超时设置是另一个容易忽略的地方。Nginx 默认的 proxy_read_timeout 是 60 秒。如果你的后端有个接口要跑两分钟——比如生成报表——那请求到 60 秒就被 Nginx 掐断了，用户看到 504。这种问题排查起来很烦，因为后端日志显示请求还在跑，但前端已经报错了。把超时调大就行，但别调太大，否则慢请求会堆积。

负载均衡也顺带提一下。反向代理天然支持 upstream 配置，把请求分给多台后端：

upstream backend {  server 127.0.0.1:3000; server 127.0.0.1:3001; server 127.0.0.1:3002; }

默认是轮询策略，每台轮流来。如果某台机器性能更强，可以加权重。某台挂了 Nginx 会自动跳过，但默认的失败判定有点迟钝——需要连续失败几次才标记为不可用。生产环境建议配合 max_fails 和 fail_timeout 一起调。

WebSocket 代理需要额外配置。普通的 HTTP 代理配置直接拿来用，WebSocket 连接会在握手阶段断掉。得加上：

proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade";

这三行不加，Socket 连接建不起来，前端控制台会报 400 或 502。我第一次配 WebSocket 代理的时候折腾了快一个小时，最后发现就差这几行。

缓存也值得说一句。proxy_cache 能把后端响应缓存到本地磁盘，同样的请求再来直接返回缓存，不走后端。对读多写少的接口效果很好。但缓存过期策略要配好，不然用户看到的是旧数据，那就尴尬了。

实际部署中，Nginx 反向代理的配置文件通常按站点拆开，放在 /etc/nginx/conf.d/ 或 sites-available 目录下。一个站点一个文件，改起来清晰，也不容易互相干扰。改完配置记得 nginx -t 测一下语法，没问题再 nginx -s reload。直接 reload 不测试，语法错了 Nginx 会拒绝加载新配置，但老进程还在跑，你以为生效了其实没有。

反向代理这个事，配起来门槛不高，但细节多。上面提到的路径拼接、头部传递、超时、WebSocket，每一个都是实际项目中会碰到的。把这些搞明白了，Nginx 这层基本就不会出什么大问题。