ip_hash能确保同一客户端IP始终转发至同一台后端服务器，前提是真实IP准确透传、upstream列表稳定、未配置weight等冲突参数，并通过curl绑定源IP与$upstream_addr日志双向验证。
要验证 Nginx 的 ip_hash 是否真正实现了“同一客户端 IP 始终转发到同一台后端服务器”，关键在于**控制变量、隔离干扰、可重复观测**。它不是靠猜或看日志片段，而是要有明确的请求来源标识和后端响应反馈。
确保测试环境满足前提条件
ip_hash 生效有硬性依赖，不满足就无法正确测试：
- 后端服务器必须在
upstream块中明确定义，且未配置weight、backup等与 ip_hash 冲突的参数 - Nginx 配置中已启用
ip_hash;（写在 upstream 块内，不能放在 server 或 location 中） - 客户端真实 IP 必须能被 Nginx 正确获取：若前端有代理（如 CDN、WAF、另一层 Nginx），需确保已通过
X-Forwarded-For或real_ip_header+set_real_ip_from正确还原，否则 hash 的是代理 IP，所有请求都会打到同一台后端 - 测试期间不要增删 upstream 中的 server，否则哈希映射会整体偏移，导致“固定性”失效
用 curl + 源 IP 控制做基础验证
在 Linux/macOS 上，可通过指定网络接口或绑定源地址发起请求，模拟固定 IP 客户端：
- 若测试机有多个 IP（如
192.168.1.100和192.168.1.101），分别执行：curl -s http://your-domain/whoami --interface 192.168.1.100curl -s http://your-domain/whoami --interface 192.168.1.101 - 每条命令重复执行 5–10 次，观察返回的后端标识（如主机名、IP 或自定义响应头）是否始终一致
- 注意：Windows 的 curl 不支持
--interface，可用 WSL 或改用 Python 脚本绑定源地址
用简单后端服务输出可识别标识
后端服务器需主动暴露自身身份，便于区分路由结果：
- 在每台后端上部署一个轻量接口，例如返回 JSON：
{"server": "web01", "ip": "192.168.1.10"}（web01）、{"server": "web02", "ip": "192.168.1.11"}（web02） - 避免用容器名或动态 hostname，优先用固定字符串或配置文件注入的标识
- 配合 Nginx 日志中的
$upstream_addr字段（记录实际转发目标），双向印证
借助日志与时间戳交叉比对
开启 Nginx 访问日志并加入关键字段，让判断更可靠：
- 在 log_format 中加入：
log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$upstream_addr" $request_time'; - 用相同客户端 IP 发起 10+ 次请求，检查日志中
$remote_addr相同时，$upstream_addr是否完全一致（包括端口） - 特别留意 IPv6 地址——ip_hash 对 IPv6 使用完整地址哈希，若日志中显示缩写（如
::1），需确认是否真为同一地址
不复杂但容易忽略：真实 IP 识别和 upstream 结构稳定性，才是测试能否成立的根基。只要这两点稳了，固定性验证就是一次 curl 加一眼日志的事。
