先验证 ip_hash 是否生效：配置 log_format 包含 $remote_addr 和 $upstream_addr，观察同一客户端 IP 是否始终转发至同一后端地址；若失效，常见原因包括多 location 引用冲突、其他负载策略覆盖、动态 proxy_pass 未触发 upstream，或 NAT/CDN 导致 $remote_addr 非真实 IP。
确认 ip_hash 是否真正在生效
别急着调配置，先验证它有没有起作用。在 upstream 块中启用 ip_hash 后，Nginx 并不会自动记录哈希过程，必须靠日志反推。在 log_format 中加入 $remote_addr 和 $upstream_addr，例如：
log_format debug_hash '$remote_addr - $upstream_addr - $time_local';
然后观察一段时间内相同 $remote_addr 是否始终打到同一个 $upstream_addr。如果同一 IP 出现在多个后端地址中，说明 ip_hash 没生效——常见原因包括：
- upstream 块被多个 location 引用，但其中某个 location 用了别的 proxy_pass（比如直连某台 server）；
- 配置了 hash 或 least_conn 等其他负载策略，覆盖了 ip_hash；
- 使用了 proxy_pass 动态变量（如 proxy_pass http://$backend;），导致 upstream 机制未触发。
识别 NAT/CDN 导致的“假同 IP”现象
看到大量请求来自同一个公网 IP（如 112.65.32.1），不等于问题出在 Nginx。这往往是真实网络结构造成的：企业出口网关、运营商 CGNAT、CDN 回源节点或中间 LB 未透传原始 IP。此时 $remote_addr 是代理 IP，不是用户真实 IP。
排查步骤：
- 检查请求头是否携带 X-Forwarded-For（注意可能有多个值，取最左或最右需结合网络路径判断）；
- 查看 $http_x_forwarded_for 日志字段，对比是否呈现多层 IP（如 203.124.5.6, 112.65.32.1, 10.1.2.3）；
- 若上游设备（如 WAF、CDN）支持透传且可信，在 Nginx 中配置：set_real_ip_from 192.168.0.0/16;set_real_ip_from 112.65.32.0/24;real_ip_header X-Forwarded-For;real_ip_recursive on;
- 配置后再次检查 $remote_addr 是否已变为内网或真实客户端地址。
分析哈希倾斜是否由 IPv4 截断规则引发
ip_hash 对 IPv4 默认只取前 3 段做哈希（如 192.168.1.100 → 192.168.1.0）。这意味着整个 C 类网段所有 IP 都映射到同一后端——在办公网、IDC 内网或 DHCP 地址池密集场景下，极易造成单点过载。
验证方法：
- 统计日志中 $remote_addr 的前 3 段分布（如用 awk 提取并去重）；
- 若发现大量请求集中在少数几个 /24 网段，且这些网段都固定落到同一台 backend，则基本确认是此机制导致；
- 此时不能靠“优化权重”解决，因为 ip_hash 不参与权重计算，也不响应负载变化。
缓解方向：
- 改用完整 IP 哈希：hash $binary_remote_addr consistent;（需 Nginx ≥ 1.11.0）；
- 或组合其他变量增强区分度：hash $binary_remote_addr$http_user_agent consistent;；
- 注意：加 consistent 可减少后端扩缩容时的重散列冲击，但无法解决初始倾斜。
检查会话中断与节点变更的连锁反应
ip_hash 的哈希结果强依赖 upstream 列表顺序和成员数量。一旦增删 server 行、调整 weight（即使 weight=1）、或临时注释某行，整个哈希映射表都会重算——用户 IP 会突然跳转到另一台后端，造成登录态丢失、WebSocket 断连、本地缓存失效等问题。
典型表现：
- 发布后部分用户反馈“反复登出”“消息收不到”；
- 监控显示某 backend 请求量骤降，另一台同步激增；
- 日志中同一 IP 的 $upstream_addr 在某时间点批量切换。
应对建议：
- 上游服务器扩容时，优先使用 backup 标记新节点，灰度验证后再正式加入；
- 避免在生产环境随意调整 server 行顺序或注释/取消注释；
- 如业务已具备 Redis Session 共享能力，应逐步迁移到 least_conn 或轮询 + 集中式状态管理，摆脱对 ip_hash 的强依赖。
