ip_hash是否生效需通过多方法组合验证：查access.log中$upstream_addr是否一致、curl多次调用/whoami看返回主机名是否稳定、确认$remote_addr为真实客户端IP（非代理IP）、测试upstream变更时路由是否动态重哈希。
直接验证 ip_hash 是否生效，关键不是看配置有没有写对，而是观察请求是否真被“钉”在了同一台后端上。下面几个方法组合使用，结果才可靠。
查 Nginx 访问日志确认路由一致性
这是最直接、最可信的方式。你需要让 Nginx 记录每条请求打到了哪台后端：
- 在 upstream 块中为每台 server 显式命名，例如：
server 10.0.1.10:8080 weight=1 max_fails=2 fail_timeout=10s; - 在 log_format 中加入 $upstream_addr 变量（它会记录实际转发的目标地址）：
log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$upstream_addr" $request_time'; - 用同一客户端（比如固定一台测试机或手机连 WiFi 不切网）发起 5–10 次请求（如 curl 或浏览器刷新），再查看 access.log
- 如果所有请求的 $upstream_addr 都指向同一个 IP:port（比如始终是 10.0.1.10:8080），说明 ip_hash 生效；若来回跳动，就未生效或被干扰
用 curl 模拟多轮请求并比对响应头或内容
适用于后端服务能体现“本机标识”的场景（比如 Spring Boot 应用返回服务器 hostname）：
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 在后端每个实例上部署一个简单接口，返回当前机器名：
curl -s http://10.0.1.10:8080/whoami → "backend-01"
curl -s http://10.0.1.11:8080/whoami → "backend-02" - 通过 Nginx 代理访问该接口多次：
for i in {1..5}; do curl -s http://nginx-proxy/whoami; echo; done - 输出全部一致（如全是 backend-01），说明请求稳定落在同一节点；出现混杂则 ip_hash 未起作用
检查真实 IP 是否被正确还原
很多 ip_hash 失效，根本原因不是配置错，而是 $remote_addr 拿到的是代理 IP（如 CDN、WAF、公司出口 NAT）：
- 在 Nginx 日志里加 $remote_addr 和 $http_x_forwarded_for 字段，对比看是否一致
- 如果 $remote_addr 是 10.x.x.x 或 192.168.x.x 这类内网地址，而 $http_x_forwarded_for 有公网 IP，说明你没配 set_real_ip_from 和 real_ip_header
- 必须确保：前置代理 IP 段已通过 set_real_ip_from 203.0.113.0/24; 声明，并设置 real_ip_header X-Forwarded-For;，否则所有用户哈希值都一样（全算成代理 IP），全部打到同一台后端
验证 upstream 变更是否触发漂移（可选压力测试）
ip_hash 的映射关系非常敏感，适合做一次破坏性验证来确认机制是否按预期工作：
- 先用上述方法确认当前 3 台后端下，某 IP 固定打到 backend-01
- 临时注释掉 upstream 中的 server 10.0.1.11:8080;，重载 Nginx（nginx -s reload）
- 再次用同一 IP 请求，观察是否仍打到 backend-01（正常情况：是，因为 backend-01 仍在列表中且索引未变）
- 再把 backend-01 注释掉，重载，此时该 IP 应切换到新计算出的节点（比如 backend-02），说明哈希逻辑在动态调整
