ip_hash不支持平滑扩容，因其哈希映射依赖ip、后端顺序与数量三者稳定；短期可用健康检查+只增不删+真实ip还原缓解，中长期须外置session或改用token实现无状态。
ip_hash 本身不支持平滑扩容，后端增减服务器会改变哈希映射关系，导致大量用户被重新分配到不同节点，原内存中的 Session 就丢了。这不是配置技巧问题，而是算法固有局限——它依赖“IP + 后端列表顺序 + 数量”三者稳定才能保持映射一致。
必须前置：别把 ip_hash 当长期方案
动态扩容场景下硬扛 ip_hash，只会放大风险。真正可行的路径是分两步走：
- 短期过渡：用 ip_hash + 健康检查 + 故障隔离，控制影响范围
- 中长期落地：剥离 Session 对单机的依赖，让 ip_hash 变得可弃用
扩容时降低冲击的实操要点
如果暂时无法改造后端，至少做到以下几点来减少会话中断：
- 扩容只加不删：新增 server 行，但不删除旧节点；等流量自然迁移或灰度完成后再下线老节点。避免哈希表重散列
- 禁用自动剔除：不要配 max_fails/fail_timeout 触发自动摘除——否则一台宕机，ip_hash 会强行重算，所有落在它上面的用户全断。改用主动运维下线 + reload
- 配合 real_ip_module 还原真实 IP：若前端有 CDN 或代理，$remote_addr 是代理 IP，会导致所有用户哈希到同一台后端。需配置 set_real_ip_from 和 real_ip_header，确保哈希基于用户真实 IPv4
- 限制哈希粒度（慎用）：默认对整个 IPv4 哈希，可改用 hash $remote_addr consistent;（需 nginx 1.11.5+ 且启用一致性哈希模块），在增减节点时仅少量 key 迁移，但注意这已不是原生 ip_hash，且不解决 Session 本地存储的根本问题
比“减少丢失”更有效的解法
与其花力气兜底 ip_hash 的缺陷，不如直接切断 Session 和服务器的绑定关系：
- Session 外置 Redis：所有后端共用一个 Redis 实例存 JSESSIONID/PHPSESSID，ip_hash 是否启用都不影响登录态连续性
- 改用 Token 鉴权：前端存 JWT，后端全部无状态校验签名和有效期，彻底不需要服务端存 Session
- Cookie 级粘性替代：用 hash $cookie_jsessionid;（需 Cookie 存在且安全可信），比 IP 更稳定——用户换网络也不丢，但要求前端能可靠携带并刷新 Cookie
ip_hash 是个快速止血的绷带，不是手术刀。动态扩容需求一出现，就说明系统已进入成长期，该把 Session 架构升级提上日程了。
