ip_hash生效的验证方法是：用同一客户端IP多次请求，检查响应标识或Nginx日志中$upstream_addr是否始终指向同一后端；若全部命中一台，需排查real_ip_module配置；若分散多台，则检查upstream配置是否误加weight等干扰参数。
直接用 curl 多次请求，配合后端日志或简单响应标识，就能验证 ip_hash 是否生效。关键不是“能不能配”，而是“有没有真实走通”。
准备可识别的后端响应
让每台后端返回唯一标识（比如主机名、IP 或序号），方便区分请求落到哪台机器：
- 后端服务返回 HTTP 响应头，如
X-Backend-ID: server-a - 或在响应体中输出固定字符串，例如
{"server": "192.168.1.10"} - 更简单：每台后端在 access.log 里记录 $host 或自定义字段，统一查日志
用同一客户端 IP 多次发起请求
确保测试时源 IP 不变（避免 NAT、代理干扰）：
- 本地直连 Nginx（不经过 CDN/WAF/公司代理），执行：
for i in {1..10}; do curl -s http://your-domain.com/api/test | grep server; done - 如果用浏览器测试，需禁用开发者工具里的“禁用缓存”以外的干扰项，并清空 Cookie（避免 cookie 策略覆盖 ip_hash）
- 若只能通过公网访问，且已配置 real_ip_module，请确认
$remote_addr在 Nginx 日志中确实是真实用户 IP，而不是上一跳地址
检查 Nginx 日志确认路由一致性
在 Nginx 的 access_log 中添加后端目标变量，快速比对：
- 修改 log_format：
log_format main '$remote_addr - $upstream_addr - $time_local "$request" $status'; - 每次请求日志会显示类似：
203.208.60.1 - 192.168.1.10:8080 - [08/Oct/2026:12:55:33 +0000] "GET /api/test HTTP/1.1" 200 - 连续 10 次请求，
$upstream_addr应始终指向同一台后端 IP:PORT
模拟客户端 IP 变化看是否切换
换一个网络环境（如手机热点、另一台电脑）再测，应落到不同后端：
- 新 IP 的多次请求，也应稳定落在同一台（但可能和前一个 IP 不同）
- 若所有请求都打到同一台——大概率是
$remote_addr没还原真实 IP（被代理遮蔽），触发了“伪粘性”（实为雪崩） - 若同一 IP 请求分散到多台——检查 upstream 块里是否误加了
weight、backup等参数，或ip_hash;没写在第一行
