Nginx报“ip_hash and weight cannot be used together”是设计限制而非语法错误；需检查upstream是否混用互斥指令、server行是否含weight等参数、real_ip_module是否干扰$remote_addr、proxy_pass是否指向正确upstream，以及IPv4哈希精度导致的绑定偏差。
直接报错“ip_hash and weight cannot be used together”时，说明 Nginx 在解析 upstream 块时检测到逻辑互斥指令共存——这不是语法错误，而是设计限制。排查重点不是改语法，而是确认配置结构是否违反了 ip_hash 的使用前提。
检查 upstream 块是否混用互斥指令
ip_hash 必须独占 upstream 的负载策略，不能与任何其他分配逻辑并存：
- 删除所有与负载算法相关的指令：least_conn、hash、fair（第三方模块）、keepalive（非负载类，但常被误放）等，都不可与 ip_hash 同块出现
- 逐行检查每个 server 行：只要出现 weight=、max_fails=、fail_timeout=、backup、down 等参数，哪怕只写了一个，Nginx 启动就会拒绝
- 特别注意注释后残留的隐藏字符或换行符，有时看似没写 weight，实际配置被格式污染导致解析异常
验证 real_ip_module 是否干扰哈希源
ip_hash 实际作用于 $remote_addr 变量。若启用了 real_ip_module，该变量可能已被覆盖，导致你以为“没生效”，其实是哈希对象变了：
- 在 log_format 中加入 $remote_addr 和 $http_x_forwarded_for，对比日志确认真实参与哈希的 IP 是什么
- 如果前端有 CDN 或 LB，且 set_real_ip_from 配置不全，$remote_addr 可能全是 10.0.0.x 或 127.0.0.1，此时 ip_hash 会把大量用户映射到同一台后端
- 临时注释掉 real_ip_module 相关指令（set_real_ip_from / real_ip_header），重启后测试，可快速判断是否为此类干扰
确认 proxy_pass 是否命中正确 upstream
即使 upstream 定义正确，location 中的 proxy_pass 若指向错误名称、拼写偏差或被 rewrite 覆盖，ip_hash 实际不会触发：
- 运行 nginx -T | grep -A10 "upstream your_upstream_name"，查看最终加载的 upstream 内容是否含 ip_hash
- 检查 access 日志中 $upstream_addr 字段：若值频繁变动，说明请求根本没走你定义的 ip_hash upstream，而是落到默认轮询或其他 upstream
- 排除 if、rewrite、return 等指令在 location 中提前终止流程，导致 proxy_pass 未执行
检查 IPv4 地址哈希精度是否引发误判
ip_hash 对 IPv4 默认只取前三段（如 192.168.1.x 视为同一组），在 NAT 环境下容易造成“多个用户绑定同一后端”：
- 用 curl -H "X-Forwarded-For: 192.168.1.100" 测试，再换 192.168.1.101，观察 $upstream_addr 是否相同
- 若业务允许，改用 hash "$remote_addr:$remote_port" consistent 替代 ip_hash，可提升区分度（需确保端口稳定）
- 公网场景强烈建议放弃纯 IP 绑定，改用 hash $cookie_sessionid consistent，避免共享出口 IP 导致粘性失效
