排查ip_hash异常需先确认nginx收到的真实源ip是否准确：检查access log中$remote_addr是否为预期公网ip；若前置cdn/waf等，须配置set_real_ip_from与real_ip_header透传真实ip；验证ip_hash行为时注意ipv4按前三字节哈希、同一c段ip可能映射相同后端；确保日志使用经real_ip处理的$remote_addr而非不可靠的$http_x_forwarded_for；并检查upstream中server状态是否稳定，避免因down/max_fails导致fallback破坏一致性。
排查 ip_hash 日志中客户端 IP 异常，核心是确认 Nginx 实际收到的源 IP 是否与预期一致。常见异常包括：日志里出现内网地址（如 10.x.x.x、172.16.x.x、192.168.x.x）、固定几个 IP 占据大量会话、或同一真实用户每次请求被分到不同 upstream 服务器（违背 ip_hash 一致性）。
检查 Nginx 是否直连客户端
如果 Nginx 前面有 CDN、WAF、LB 或反向代理（如另一层 Nginx、Traefik、ALB），它默认只能拿到该中间层的 IP，而非真实用户 IP。此时 ip_hash 会基于中间层 IP 计算，导致大量用户被哈希到同一个后端——表现为日志中出现少数几个 IP 高频出现。
- 查看 Nginx access log 中记录的 IP 字段（例如
$remote_addr），对比你期望的真实用户 IP 段 - 确认上游设备是否透传了真实 IP；若使用 HTTP 头（如
X-Forwarded-For），需配合set_real_ip_from和real_ip_header指令启用可信 IP 解析 - 示例配置片段：
set_real_ip_from 10.0.0.0/8; set_real_ip_from 172.16.0.0/12; set_real_ip_from 192.168.0.0/16; real_ip_header X-Forwarded-For; real_ip_recursive on;
验证 ip_hash 是否生效且行为符合预期
ip_hash 基于 IPv4 的前三个字节（如 192.168.1.x → 视为 192.168.1）做哈希，IPv6 则取完整地址。这意味着同一 C 段内不同 IP 可能被哈希到相同后端，造成“IP 不同但路由一致”的假象。
- 开启 Nginx debug 日志（需编译时含
--with-debug），或临时加error_log /path/to/debug.log debug;，观察upstream hash相关输出 - 用不同真实 IP（跨网段）发起多次请求，检查 access log 中
$remote_addr和后端$upstream_addr的对应关系是否稳定 - 注意：Nginx 1.7.2+ 支持
hash $remote_addr consistent;替代ip_hash，支持更均匀分布和节点增减时的稳定性，适合大规模场景
排查日志字段是否误用或配置错位
日志中显示的 IP 异常，有时并非转发逻辑问题，而是日志变量本身选错。例如：$remote_addr 是 Nginx 接收连接的对端地址；而 $http_x_forwarded_for 是原始请求头，未经校验可能被伪造。
- 确保 access log format 中用于分析的 IP 字段是
$remote_addr（经real_ip模块处理后已更新） - 避免在日志中直接使用
$http_x_forwarded_for做ip_hash分析依据，它不可信且未参与哈希计算 - 检查
log_format定义位置是否在http块顶层，且access_log指令引用正确格式名
检查 upstream 配置与健康状态
ip_hash 在 upstream 中启用后，会将同一 IP 固定映射到某台 server，但若该 server 处于 down、max_fails 触发、或被 slow_start 临时剔除，Nginx 会临时 fallback 到其他可用节点——造成“同一 IP 有时走 A、有时走 B”。
- 用
nginx -T | grep -A 20 "upstream.*{"查看 upstream 配置，确认ip_hash;存在且未被注释 - 检查各 server 行是否误加
down、backup，或设置了过激的max_fails=1 fail_timeout=10s导致频繁抖动 - 通过
stub_status或 Prometheus exporter 观察 upstream server 的当前状态（active、unavail、health checks 结果）
