nginx代理网站

我见过太多人把Nginx当成一个黑盒子，理网配置完就再也没碰过。理网直到有一天，理网一个客户的理网生产环境突然挂了，我才意识到很多人根本没搞懂Nginx到底在做什么。理网

那次事故很典型。理网客户说网站打不开，理网我ssh上去一看，理网Nginx进程还在，理网但所有请求都返回502。理网检查后端，理网Java服务正常，理网端口也在监听。理网问题出在哪？理网Nginx的error.log里写着“upstream prematurely closed connection”。后来发现是理网后端服务的keep-alive超时设置比Nginx短，导致Nginx还在复用旧连接，后端已经关了。就这么个小参数，让整个服务瘫痪了半小时。

讲这个例子是想说，Nginx代理远不止“把请求转发过去”这么简单。它站在客户端和后端之间，像个挑剔的门卫，每个连接都要经过它的审查。默认配置下，Nginx会缓存后端返回的响应头，管理连接池，甚至能改写请求路径。这些行为如果不理解，出了问题就抓瞎。

拿最常见的反向代理配置来说：

location /api/ {  proxy_pass http://backend_server; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } 

这段配置看起来简单，但里面藏着不少坑。第一行location匹配规则，如果你写的是“location /api”，那访问“/apixyz”也会被匹配到，可能不是你想要的结果。而proxy_pass后面的URL，如果带了路径（比如http://backend_server/），Nginx会把location匹配的部分替换掉；如果不带路径，就原样转发。这两种行为差异很大，很多人就是在这里栽跟头。

还有那个proxy_set_header，你不设置X-Forwarded-For的话，后端看到的IP全是Nginx的IP，日志分析直接废了。更隐蔽的是，如果你用了HTTPS，后端却不知道请求是加密的，可能会生成错误的重定向链接。

我自己习惯在proxy_pass后面不加斜杠，这样路径完全由后端控制，减少一层心智负担。但这只是个人偏好，关键是要明白每个参数的作用。

再往深了说，Nginx代理还涉及缓冲机制。默认情况下，Nginx会缓冲后端的响应，等整个响应收完再发给客户端。这对大文件下载是好事，但对流式接口（比如SSE或WebSocket）就是灾难。WebSocket需要特殊的Upgrade头，Nginx默认不支持，必须显式配置：

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

少了这三行，WebSocket连接根本建立不起来。我第一次调这个的时候，花了一个下午才从文档角落翻出来。

还有一个容易忽略的点：Nginx的worker_processes和worker_connections决定了它能同时处理多少连接。默认配置在低流量下没问题，但一旦遇到突发流量，连接数打满，新请求直接排队等待，表现为响应变慢而不是报错。很多人这时候去查后端性能，其实瓶颈在Nginx本身。

所以我的建议是，别把Nginx当透明代理用。花点时间读一下官方文档的ngx_http_proxy_module部分，把每个指令都过一遍。你不需要记住所有参数，但至少要知道有哪些旋钮可以拧。生产环境出问题时，这些知识就是你的救命稻草。

那次事故之后，我给自己定了个规矩：任何Nginx配置改动，先在staging环境压测一遍，专门测试连接复用、超时、缓冲这三个维度。虽然麻烦点，但总比半夜爬起来处理502强。