项目上Nginx负载均衡突然不工作了，运维应该如何排查？

1. 问题现象初探：你的负载均衡真的在偷懒吗？

最近小王负责的电商平台在大促期间突然出现首页无法访问的情况。用户投诉像雪片般飞来，但奇怪的是监控系统显示所有后端服务器CPU和内存都处于低位。经过排查，发现Nginx的负载均衡策略突然失效，所有流量都被导向了一台已经挂掉的服务器。

典型症状自查清单：

部分或全部请求返回502/504错误
Nginx访问日志显示请求集中在个别后端节点
后端服务器的实际负载与预期分布严重不符
健康检查接口频繁报错但未触发熔断

2. 第一现场勘查：配置检查四步法

2.1 检查upstream基础配置

# 错误示例：缺少必要的协议声明
upstream backend {
    server 192.168.1.101;  # 未指定端口，默认使用80
    server 192.168.1.102:8080 max_fails=3;
}

# 正确配置（Nginx 1.9+）
upstream backend {
    zone backend_zone 64k;        # 共享内存区域
    server 192.168.1.101:80 weight=5; 
    server 192.168.1.102:8080 max_fails=3 fail_timeout=30s;
    keepalive 32;                 # 长连接池配置
}

常见陷阱：

未指定zone指令导致worker进程间状态不同步
weight参数设置不合理导致流量倾斜
keepalive连接数不足引发频繁建连开销

2.2 负载均衡算法验证

# 轮询算法（默认）
upstream backend {
    least_conn;  # 改为最小连接数算法
    server srv1.example.com;
    server srv2.example.com;
}

# IP哈希算法的典型错误
upstream backend {
    ip_hash;
    server srv1.example.com weight=2;  # 注意：ip_hash与weight不兼容
    server srv2.example.com;
}

关键点：

使用sticky模块时需要确保Nginx编译时包含该模块
不同算法对会话保持的影响需要提前评估
动态权重调整需要商业版Nginx Plus支持

3. 后端服务侦探：你以为活着的服务器真的健康吗？

3.1 手动验证后端状态

# 使用curl模拟Nginx健康检查
curl -I http://192.168.1.101:80/health-check
# 期望响应：HTTP/1.1 200 OK

# 测试响应超时阈值（单位：秒）
timeout 0.5 curl -svo /dev/null http://192.168.1.102:8080

排查重点：

检查后端服务的监听端口是否变更
验证防火墙规则是否意外更新
确认应用进程是否假死（监听端口存在但无响应）

3.2 被动健康检查陷阱

# 危险的默认配置
upstream backend {
    server 192.168.1.101:80 max_fails=1 fail_timeout=10s;
    server 192.168.1.102:8080;
}

# 推荐的健康检查配置
upstream backend {
    server 192.168.1.101:80;
    server 192.168.1.102:8080;
    
    # 主动健康检查配置（需要http_upstream_check_module）
    check interval=3000 rise=2 fall=5 timeout=1000 type=http;
    check_http_send "HEAD /health HTTP/1.1\r\nHost: localhost\r\n\r\n";
    check_http_expect_alive http_2xx http_3xx;
}

经验教训：

被动健康检查依赖真实请求失败，存在滞后性
主动检查需要合理设置检测频率避免性能损耗
健康检查接口本身要做好熔断保护

4. 网络迷宫：当问题不在代码在传输

4.1 端口连通性测试全家桶

# 快速TCP端口检测
nc -zv 192.168.1.101 80 2>&1 | grep succeeded

# 全链路追踪（需要root权限）
traceroute -T -p 80 192.168.1.101

# 连接耗时分析
time curl -o /dev/null -s -w '%{time_connect}\n' http://192.168.1.101

4.2 DNS解析黑洞

# 问题配置：使用域名且DNS缓存时间过长
resolver 8.8.8.8 valid=300s;  # 缓存5分钟
upstream backend {
    server api-cluster.example.com:80 resolve;
}

# 改进方案
resolver 192.168.1.253 valid=10s;  # 使用内网DNS
upstream backend {
    zone backend_zone 64k;
    server api-cluster.example.com:80 resolve;
}

注意要点：

动态DNS场景建议配合resolver指令
Kubernetes环境需注意Service DNS的特殊性
生产环境建议使用IP直连避免DNS依赖

5. 日志解密：从访问日志中找破案线索

5.1 错误日志精读

# 典型错误日志示例
2023/08/20 14:05:23 [error] 1521#1521: *735810 connect() failed 
(111: Connection refused) while connecting to upstream, 
client: 10.2.3.4, server: example.com, 
request: "GET /product/123 HTTP/1.1", 
upstream: "http://192.168.1.102:8080/product/123", 
host: "example.com"

# 健康检查失败日志
2023/08/20 14:05:25 [warn] 1521#1521: *735812 upstream server 
temporarily disabled while connecting to upstream

5.2 访问日志分析技巧

log_format upstream_log '$remote_addr - $host [$time_local] '
                       '"$request" $status $body_bytes_sent '
                       '"$http_referer" "$http_user_agent" '
                       'upstream: $upstream_addr response_time: $upstream_response_time';

# 实时监控后端分布
tail -f access.log | awk '{print $NF}' | sort | uniq -c

# 响应时间异常检测
cat access.log | grep "upstream: 192.168.1.102" | 
awk '{if($(NF-1)>1) print $0}'

6. 关联技术：那些你可能忽略的周边因素

6.1 Keepalive连接池调优

upstream backend {
    keepalive 32;       # 每个worker保持的长连接数
    keepalive_requests 10000;  # 单个连接最大请求数
    keepalive_timeout  60s;    # 空闲超时时间
}

调优指南：

根据QPS和平均响应时间计算合理值
使用netstat -ant | grep ESTABLISHED验证实际连接数
高并发场景建议配合SO_REUSEPORT使用

6.2 协议版本陷阱

# 问题场景：后端服务不支持HTTP/1.1
location / {
    proxy_http_version 1.0;  # 强制降级协议版本
    proxy_set_header Connection "";
}

注意事项：

gRPC等特殊协议需要配置HTTP/2
WebSocket需要特殊的长连接配置
代理请求头需要根据后端服务调整

7. 终极大招：系统性排查流程图

检查Nginx进程状态 ps aux | grep nginx
验证配置文件语法 nginx -t
抓包分析TCP握手过程 tcpdump -i eth0 port 80
压力测试验证负载分布 wrk -t4 -c100 -d30s http://example.com
逐步增加后端节点观察流量变化
使用debug日志级别定位疑难问题

8. 技术选型思考：Nginx LB的适用场景

适合场景：

七层协议负载均衡
静态资源缓存加速
需要灵活路由规则的场景
混合云环境下的统一入口

不适用场景：

四层负载高性能要求（建议使用LVS）
需要动态服务发现的场景（建议结合Consul）
复杂的服务网格需求（建议使用Istio）

9. 总结：构建可靠的负载均衡体系

通过这次排查之旅，我们总结出保持Nginx负载均衡稳定运行的三大法宝：

预防性配置：完善的健康检查机制+合理的超时设置
立体化监控：从内核参数到应用指标的全面监控
防御性设计：优雅降级方案+自动故障转移机制

记住，负载均衡不是一劳永逸的配置，而是需要持续优化的活系统。下次当你面对Nginx罢工时，不妨按照这个排查路线图逐步推进，相信很快就能让流量重新欢快地流动起来！

敲码拾光专注于编程技术，涵盖编程语言、代码实战案例、软件开发技巧、IT前沿技术、编程开发工具，是您提升技术能力的优质网络平台。