ip_hash在NAT环境下会将共享同一出口IP的所有用户请求全部分配至同一台后端服务器，因其仅对$remote_addr机械哈希且IPv4取前三段，无法区分真实用户；需通过real_ip_module还原真实IP或改用cookie哈希等替代方案。
直接在 NAT 环境下测试 ip_hash 的分布效果，核心是模拟“多个用户共享同一出口 IP”的真实场景，并观察请求是否全部落到同一台后端服务器上。这不是测配置对不对，而是验证它在现实网络中的实际行为。
用真实 NAT 网络或代理模拟出口 IP 一致
家庭路由器、企业防火墙、运营商级 NAT 都会让不同内网用户共用一个公网 IP。测试时不必等上线，可主动构造：
- 找至少 3 台不同设备（手机、笔记本、虚拟机），连到同一个 WiFi 或同一台家用路由器下
- 确保它们访问服务时的
$remote_addr在 Nginx 日志里显示为同一个 IP（比如112.65.34.101） - 如果前端有 CDN/WAF/SLB，先确认
real_ip_module已启用且set_real_ip_from配置正确，否则日志看到的是代理 IP，测了也白测
快速验证请求是否全部打到同一台后端
不用写脚本也能判断分布是否“失效”：
- 在每台后端服务器的访问日志里加标识，比如用
log_format记录$server_addr或主机名 - 从 NAT 内发起 10–20 次请求（
curl http://your-domain.com/test或浏览器反复刷新） - 检查所有请求是否只出现在其中一台后端的日志中——如果是，说明
ip_hash正常工作，但也暴露了单点风险
对比轮询模式看差异
临时把 upstream 中的 ip_hash 注释掉，重启 Nginx，再同样从 NAT 内发起请求：
- 这时请求应均匀分散到各台后端（轮询默认行为）
- 若仍集中到一台，说明 upstream 里某台 server 被标记为
down或健康检查失败，不是ip_hash的问题 - 这个对比能帮你排除配置干扰，聚焦在 IP 分布逻辑本身
补充：用 curl 指定不同 X-Forwarded-For 测试（需 real_ip_module 支持）
如果已配置 real_ip_header X-Forwarded-For 和可信源，可以用伪造头的方式批量模拟不同客户端 IP：
curl -H "X-Forwarded-For: 192.168.1.100" http://your-domain.com/testcurl -H "X-Forwarded-For: 192.168.1.101" http://your-domain.com/test- 观察这些不同 IP 是否稳定落在不同后端——这是检验哈希逻辑是否按预期工作的最干净方式
