ip_hash验证核心是固定ip路由一致性与高并发下是否异常漂移：需用curl/ab对同一源ip发起百次请求，检查access_log中$upstream_addr是否恒定；压测时关注502/504、$upstream_addr突变、nat导致单节点过载等现象，并排除cdn、ipv6截断及localhost测试干扰。
直接测 ip_hash 的“节点命中率”没有实际意义——它本就不保证均匀分布，而是强制同一 IP 固定打到某台后端。真正该测的是：固定 IP 是否始终落在同一节点，以及高并发下是否出现异常漂移或失败。
验证固定性：单 IP 多次请求是否路由一致
这是 ip_hash 的核心行为，必须先确认。方法简单有效：
- 用 curl 或 ab 工具对同一目标发起 100+ 次请求，显式指定源 IP（如通过代理或本地 hosts 绑定）
- 在 Nginx access_log 中开启 $upstream_addr 和 $remote_addr 记录，例如： log_format debug_hash '$remote_addr → $upstream_addr "$request" $status';
- 执行后检查日志：所有该 IP 的请求，$upstream_addr 字段是否完全相同
观察高并发下的稳定性表现
压测时重点不是“命中率数字”，而是看有没有违背 ip_hash 设计预期的现象：
- 是否有请求返回 502/504：说明某台后端宕机且未标记 down，ip_hash 仍持续转发，暴露了无故障转移缺陷
- 是否出现 $upstream_addr 突然切换：比如前 98 次都打到 node-a，第 99 次跳到 node-b —— 这往往意味着 upstream 配置被热重载、节点上下线，或用了不兼容参数（如混入 weight）
- 大量请求集中在一台后端：结合 $remote_addr 分析，若发现成百个不同用户（实为 NAT 后）共用一个公网 IP，就会全部压向单节点，属正常但需预警
配合日志统计做节点级行为分析
要量化影响，得把请求落到具体节点上统计：
- 按节点分离日志：用 map 将 $upstream_addr 映射为 node-a/node-b，再写入独立 access_log 文件
- 用 awk 快速统计各节点接收的请求数量，例如：
awk '{count[$10]++} END{for (i in count) print i, count[i]}' /var/log/nginx/backend/node-a-access.log - 对比各节点请求数差异：若 node-a 接收 12000 次，node-b 仅 800 次，大概率是 NAT 或 CDN 回源导致，不是配置错误，而是架构现实
注意真实环境干扰项
很多“看似命中异常”的情况其实与 ip_hash 无关，需提前排除：
- CDN 或反向代理场景下，$remote_addr 是 CDN 节点 IP，不是真实用户 IP —— 应改用可信的 $http_x_forwarded_for，并确保 header 不可伪造
- IPv6 用户会被截断前 64 位哈希，多个 IPv6 地址可能映射到同一后端，属设计如此，非 bug
- 测试时若用 localhost 或 127.0.0.1 发起请求，所有请求的 $remote_addr 都一样，必然全进一台，不能代表线上效果
