ip_hash模式下后端“塞满”主因是哈希倾斜，需通过日志分析ip分布、检查后端健康状态、验证upstream配置、临时切换least_conn来确认。
排查 ip_hash 模式下某台后端被“塞满”，核心是确认请求是否真因哈希倾斜导致单节点过载，而非业务异常、客户端 IP 集中或后端自身处理能力不足。
确认 ip_hash 是否真在生效且分布不均
nginx 默认的 ip_hash 基于客户端 IP 的 IPv4 前三段（或 IPv6 的特定前缀）做哈希，这意味着：
- 同一局域网、NAT 网关后的大量用户（如企业出口、校园网、运营商 CGNAT）会映射到同一个哈希值，全部打到同一台后端；
- IPv4 地址本身分布不均匀（例如大量私有网段、云厂商分配的连续 IP 段），哈希结果天然可能倾斜；
- 后端服务器数量变化（增/删 upstream server）会导致哈希环重分布，部分老连接仍保持、新请求重新打散，短期出现不均衡。
✅ 建议：临时开启 log_format 记录 `$remote_addr` 和 `$upstream_addr`，采样分析 1000+ 请求，统计各后端接收的请求数及对应客户端 IP 段分布。例如：
检查后端真实负载与健康状态
“被塞满”可能是表象，需排除后端自身问题：
- 该后端响应变慢（如 DB 连接池耗尽、GC 频繁、磁盘 I/O 高），导致请求堆积，nginx 仍持续转发（默认不主动摘除慢节点）；
- 该节点未正确上报健康检查失败（如 health_check 配置缺失、check interval 过长、/health 接口返回假阳性）；
- 该节点系统资源（CPU、内存、TIME_WAIT 连接数、文件描述符）已达上限，无法及时 accept 新连接。
✅ 建议：登录该后端，运行 top、ss -s、netstat -an | grep :80 | wc -l、cat /proc/sys/fs/file-nr，同时检查应用日志是否有线程阻塞或超时错误。
验证 upstream 配置是否引入隐式偏差
ip_hash 本身不支持权重（weight 被忽略），但以下配置会干扰实际分发逻辑：
- 混用了
ip_hash和least_conn或hash $arg_xxx等其他负载策略（语法错误或嵌套错误）； - upstream 中某台 server 显式配置了
down或backup，缩小了有效节点数，放大了剩余节点的哈希碰撞概率； - 使用了
max_fails/fail_timeout，但某节点曾短暂异常被标记为不可用，恢复后未自动恢复，导致流量长期压在其余节点上。
✅ 建议：执行 nginx -t && nginx -s reload 后，用 curl -I http://your-nginx-ip/upstream_conf?upstream=your_backend（需启用 upstream_conf 模块）查看实时 upstream 状态，确认所有 server 状态为 up 且无 down 标记。
临时绕过 ip_hash 快速验证
若怀疑是 ip_hash 机制本身导致，可快速切为 least_conn 或轮询测试：
- 注释掉
ip_hash;，添加least_conn;，reload nginx； - 观察 5–10 分钟内各后端 QPS、响应时间、连接数是否迅速趋于均衡；
- 若立即缓解，基本确认是 ip_hash 分布问题；若依旧不均，则聚焦后端自身或网络路径（如某台后端前有额外代理、防火墙限速）。
⚠️ 注意：切换期间需确保业务允许 session 丢失（ip_hash 常用于有状态服务），生产环境建议配合前端加 cookie 或后端共享 session 使用。
