排查Nginx ip_hash异常需先确认配置被正确加载并生效：检查upstream中是否混用互斥指令、ip_hash是否首行顶格、proxy_pass名称是否严格匹配、$remote_addr是否被real_ip_module正确还原，以及后端节点是否因健康检查失败被标记为down。
排查 Nginx ip_hash 配置语法错误引发的网关异常，核心不是找“关键字冲突”，而是验证配置是否被 Nginx 正确加载并生效——语法错误往往不报错，却导致 ip_hash 被静默忽略，流量退化为轮询或直接失败。
检查 upstream 块中是否存在互斥指令
ip_hash 不能与其它负载策略共存，否则 Nginx 启动会失败或跳过该指令：
- 若配置中同时出现
ip_hash;和least_conn;、hash $arg_id;、weight=2;等，Nginx 将拒绝加载该 upstream（nginx -t报错）或仅保留第一个有效指令 - server 行中显式写
weight、backup、max_fails不会报错，但weight会被强制忽略，容易误判为“配置未生效” - 确保
ip_hash;是 upstream 块内第一行，顶格书写，前面无空格、无注释
确认 proxy_pass 是否真正指向该 upstream
配置写了 ip_hash，但 proxy_pass 拼错名字、被 if 或 rewrite 覆盖、或位于未启用的 server 块中，都会使 ip_hash 完全不触发：
- 运行
nginx -T | grep -A10 "upstream your_name"查看最终生效的 upstream 定义，确认名称与proxy_pass http://your_name严格一致 - 在对应 location 中添加日志字段：
$upstream_addr，观察实际转发目标：若该值频繁变动（如10.0.1.10:8080, 10.0.1.11:8080交替出现），说明未命中ip_hash，大概率是 upstream 名称不匹配或被重定向绕过 - 避免在
if块内写proxy_pass，Nginx 官方明确不推荐，易导致变量作用域异常和 upstream 解析失败
验证 real_ip_module 是否干扰哈希源
ip_hash 只基于 $remote_addr 计算，而该变量可能已被 set_real_ip_from 修改——这不是语法错误，却是最常被当成“配置失效”的根源：
- 在 log_format 中加入
$remote_addr $http_x_forwarded_for $realip_remote_addr，压测时查看 access.log：若$remote_addr全是内网地址（如10.0.0.5），说明set_real_ip_from未生效或代理段填错 -
set_real_ip_from必须写在 http 块顶层，不能放在 location 内；real_ip_header必须与上游真实透传的头一致（如 Cloudflare 用CF-Connecting-IP，Nginx 反向代理常用X-Real-IP） - 开启
real_ip_recursive on;，否则多层代理下会取到中间跳 IP，导致大量用户哈希到同一后端
排除启动阶段因节点异常导致的初始化失败
当所有 upstream server 都被标记为 down（如健康检查连续失败），Nginx 在初始化 ip_hash 表时会直接放弃，后续请求报 no live upstreams：
- 检查 error.log 中是否有类似
upstream "backend" has no servers或is down (max_fails=3 fail_timeout=10s)的记录 - 临时禁用健康检查逻辑（如注释掉
max_fails和fail_timeout），用curl -v http://backend-ip:port直连验证后端是否真实可达 - 注意：即使只配了一台 server，
ip_hash也能启动，但若该节点被标记为 down，整个 upstream 就会不可用
