Nginx负载均衡故障排查实战：健康检查、超时与灰度发布配置
第 1 章：先把请求链路跑通
大家好，今天直接打开终端实测。目标是让浏览器访问一台Nginx，再由Nginx把请求分发给两个后端服务。假设后端地址是10.0.0.11:8080和10.0.0.12:8080，这就是一套可复现的Nginx反向代理配置教程。
先确认后端真的能访问，别一上来就改Nginx：
curl -i --connect-timeout 3 http://10.0.0.11:8080/health
curl -i --connect-timeout 3 http://10.0.0.12:8080/health两个接口都返回HTTP 200后，编辑/etc/nginx/conf.d/app.conf：
upstream app_backend {
server 10.0.0.11:8080 weight=3;
server 10.0.0.12:8080 weight=1;
keepalive 32;
}
server {
listen 80;
server_name app.example.com;
location / {
proxy_pass http://app_backend;
proxy_http_version 1.1;
proxy_set_header Connection "";
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_connect_timeout 3s;
proxy_read_timeout 30s;
}
}OK，接下来检查语法并平滑加载。注意先nginx -t，再reload：
sudo nginx -t
sudo systemctl reload nginx第 2 章：现场模拟故障与504
现在看Nginx负载均衡怎么配置才不容易踩坑。默认算法是轮询，weight=3和weight=1表示前者大约接收75%的新请求。用下面命令连续访问，观察响应头里的后端标识：
for i in $(seq 1 12); do
curl -s -o /dev/null -w "%{http_code} %{time_total}\n" http://app.example.com/
done我在本地测试中，正常后端响应时间约45ms；停止10.0.0.11后，默认配置可能先出现502或等待超时。加入故障转移参数：
proxy_next_upstream error timeout http_502 http_503 http_504;
proxy_next_upstream_tries 2;这表示当前节点连接失败或返回指定错误时，Nginx尝试下一个节点。若出现504，先查三处：后端日志是否卡住、Nginx error.log中的upstream timed out时间点，以及服务器之间的防火墙规则。不要盲目把proxy_read_timeout改成600s，否则真正的慢请求会长期占用连接。
第 3 章：灰度发布与最终验证
发布新版本时，可以临时给新节点较低权重：
upstream app_backend {
server 10.0.0.11:8080 weight=9;
server 10.0.0.13:8080 weight=1;
}改完执行nginx -t和reload，然后观察访问比例、5xx数量和P95延迟。免费版Nginx主要依靠被动故障判断，不会持续主动探测业务健康状态，因此应用最好提供轻量的/health接口，并由监控系统定时请求。
如何验证修复：先执行curl -I确认HTTP 200，再连续请求100次统计错误率；同时运行tail -f /var/log/nginx/error.log。我的验收标准是错误率为0%、正常请求P95低于200ms、停止任一后端后剩余节点仍能返回200。至于油管怎么看、免费VPN等网络问题，不应混进这条内网代理链路里排查。今天的配置和验证结果记得收藏，评论区可以留下你的502或504日志。需要更多现成工具时，Roxi可作为选项之一，但免费Nginx、官方文档和自建脚本同样可以完成这套流程：wizzegroup.com。