ip_hash 无语法关键字冲突，但存在逻辑冲突：不可与 least_conn 等混用；需确保 proxy_pass 正确指向 upstream；real_ip_module 会改变哈希源 IP；server 行中 weight 参数被忽略。

Nginx 的 ip_hash 本身不涉及“语法关键字冲突”——它是一个独立的 upstream 指令，不会与 hash、least_conn、weight 等其他负载均衡策略的关键字发生语法层面的冲突。真正需要排查的，是配置逻辑冲突和语义误用，比如在同一个 upstream 块中混用互斥指令，或错误覆盖了哈希行为。

以下是实际排查要点，聚焦可验证、可操作的问题：

检查 upstream 中是否混用了互斥指令

ip_hash 不能和其他负载均衡方法共存于同一 upstream 块，否则 Nginx 启动会失败或静默忽略后者：

• ❌ 错误写法（启动报错或行为不可控）：

  upstream backend {
      ip_hash;
      least_conn;          # 冲突！Nginx 不允许
      server 10.0.1.10;
      server 10.0.1.11;
  }

• ✅ 正确写法（仅保留一个主策略）：

  upstream backend {
      ip_hash;              # 或用 hash $cookie_session_id; 或 least_conn;
      server 10.0.1.10;
      server 10.0.1.11;
  }

验证是否被 proxy_pass 或 location 级配置意外绕过

ip_hash 只在 upstream 层生效；若在 location 中写了 proxy_pass http://backend/，但 upstream 名拼错、未加载、或被 if / rewrite 重定向到其他 upstream，则 ip_hash 实际不执行：

Nginx Config Linter

对 Nginx 配置文件进行语法检查、验证和安全、性能审计。

下载

• 检查日志中 $upstream_addr 字段：正常应显示固定后端地址（如 10.0.1.10:8080），若频繁变动，说明未命中预期 upstream
• 运行 nginx -t 确认配置语法合法，再用 nginx -T | grep -A5 "upstream backend" 查看最终生效的 upstream 定义

排查 real_ip_module 相关指令干扰哈希源

set_real_ip_from 和 real_ip_header 不是语法冲突，但会改变 $remote_addr 的值，从而让 ip_hash 哈希的对象不再是原始连接 IP：

• 若已启用 real_ip_module，ip_hash 实际基于还原后的 IP 计算——这本是正确做法，但容易误判为“失效”
• 验证方式：在 log_format 中加入 $remote_addr 和 $http_x_forwarded_for，对比压测时日志，确认哈希前的 IP 是否符合预期（例如是否全变成 10.0.0.5）

注意 server 行中的隐式冲突参数

ip_hash 要求所有 server 行不能带 weight（加权轮询专属），否则 weight 会被忽略且可能触发警告：

• ⚠️ 以下虽能启动，但 weight 无效，且易引发理解偏差：

  upstream backend {
      ip_hash;
      server 10.0.1.10 weight=3;   # weight 被忽略！ip_hash 不支持权重
      server 10.0.1.11;
  }

• 若需权重能力，必须改用 hash + consistent 或放弃 ip_hash

不复杂但容易忽略。