启用ip_hash需在upstream块首行添加ip_hash;，但生产环境还需确保真实IP透传、避开NAT干扰、避免与weight/backup等混用，并警惕扩容导致的会话漂移。
直接在 upstream 块首行写 ip_hash; 就启用了，但真要跑稳生产环境，光这一行远远不够——它看似简单，实则对网络结构、IP 分布、扩容节奏和配套配置极其敏感。
必须放在 upstream 第一行，且不能混用其他策略
ip_hash 是独占型指令，一旦启用，以下配置会失效或导致 Nginx 启动报错：
-
weight参数：加了会直接拒绝加载配置 -
backup、down状态标记：无法与 ip_hash 共存 - 其他 hash 类指令：如
hash $cookie_session;或hash $arg_token;，二者冲突，只认第一个 - least_conn、fair 等第三方模块策略：不兼容，需二选一
正确写法示例：
upstream app_backend {
ip_hash;
server 10.0.1.10:8080;
server 10.0.1.11:8080;
server 10.0.1.12:8080;
}
真实客户端 IP 必须还原，否则全流量打到一台
若前端有 CDN、WAF、LVS 或另一层 Nginx 代理，$remote_addr 默认是上一跳的 IP（比如 10.0.0.5），所有请求哈希结果一致，后端只剩一台在干活。
必须做三件事闭环：
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 在
http块中声明可信代理段：set_real_ip_from 10.0.0.0/8;<br>set_real_ip_from 192.168.0.0/16;<br>real_ip_header X-Forwarded-For;
- 在
location中透传头信息：proxy_set_header X-Real-IP $remote_addr;<br>proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
- 确认日志中
$remote_addr已变成用户真实 IP（可临时加log_format验证）
内网慎用“C类子网”场景，避免整网哈希坍塌
Nginx 对 IPv4 默认取前三个字节哈希（如 192.168.1.x → 视为 192.168.1）。若企业内网大量机器都在 192.168.1.0/24 段，成百上千用户会被映射为同一个哈希值，全部落到同一台后端——这不是负载均衡，是单点压测。
应对方式：
- 改用更细粒度的哈希源，例如：
hash $remote_addr consistent;（需 Nginx ≥ 1.11.0，且配合upstream内keepalive） - 或升级架构，用
hash $cookie_jsessionid;/hash $arg_token;，前提是应用能稳定生成业务标识 - 若坚持用 ip_hash，至少把内网划分子网（如
192.168.10.0/24、192.168.20.0/24），分散哈希基数
扩容缩容即会话漂移，别指望平滑过渡
ip_hash 的哈希逻辑是「IP 哈希值 % 后端服务器数量」。增减任意一台 server，模数改变，90% 以上已有用户的哈希结果都会变——意味着登录态丢失、上传中断、WebSocket 断连。
生产中必须提前预案：
- 扩容前，先用
curl -s http://your-domain/health检查当前各节点 session 关联量，评估影响面 - 缩容时，用
down标记节点并观察流量自然回落（注意：ip_hash 下down不生效，得靠健康检查+max_fails 强制剔除） - 长期方案不是扛着 ip_hash 扩容，而是推动后端接入 Redis Session 或改用 JWT 无状态认证
不复杂但容易忽略。
