说到反向代理，这个看似简单的技术在实际运维中可藏着不少门道。去年我们团队就曾在生产环境踩过一个典型的坑——当Nginx配置不当的反向代理遇到上游服务超时，整个系统就像多米诺骨牌一样连锁崩溃。那次惨痛经历让我明白，要想玩转反向代理，光会写proxy_pass可远远不够。
健康检查真的不能省
你知道吗？超过60%的反向代理故障都是因为忽略了健康检查。我在AWS上遇到过真实案例：某个微服务实例因为内存泄漏已经半死不活，但由于没有健康检查机制，Nginx还在持续把请求往这个”僵尸节点”转发。建议至少配置以下两种检查方式：
- 主动式检查：用
health_check interval=5s uri=/health这样的指令 - 被动式检查：通过
proxy_next_upstream处理5xx错误
超时设置的艺术
看到这个配置项了吗？proxy_read_timeout 60s;——它可能正在默默谋杀你的系统性能！有一次我们把超时设得过长，导致前端连接池耗尽，整个网站直接瘫痪。但设置太短又会让正常长事务失败。我的经验法是：
对于API网关：建议3000-5000ms
对于文件上传：至少设置120s
关键是要配合proxy_buffer使用，别忘了设置proxy_connect_timeout应该比read_timeout短30%
小心头部信息泄露
曾经有次安全审计把我们吓出一身冷汗——Nginx默认会把上游服务器的Server头透传给客户端，这等于告诉黑客我们用的Tomcat具体版本！现在我的配置模板里必加这几行：
proxy_hide_header Server;
proxy_hide_header X-Powered-By;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;说到IP透传，有个坑特别容易踩：当你的Nginx前面还有CDN时，记得检查X-Forwarded-For头的处理逻辑，不然所有日志记录的客户端IP都会变成CDN节点IP！
负载均衡的隐藏技巧
你以为round-robin就是最公平的算法？在我们电商大促时，least_conn算法反而让某些服务器过载了。后来我们改用带权重的ip_hash方案，解决了会话保持和负载均衡的矛盾。具体可以参考这个配置精髓：
upstream backend {
zone backend 64k;
least_conn;
server 192.168.1.1:8080 weight=3;
server 192.168.1.2:8080 weight=2;
keepalive 32;
}对了，那个keepalive 32可不是随便写的数字！经过我们压测，这个值设为worker_processes的4倍时，长连接复用率能达到最优。太大反而会导致内存浪费。
最后说句掏心窝的：反向代理配置真的不能复制粘贴就完事。每个参数背后都连着真实的用户体验，下次改配置前，不妨先问问自己——这个改动会让凌晨三点接到的报警电话变少吗？
评论