ip_hash在跨公网、NAT、代理等场景下不可靠，因依赖源IP导致用户集中或会话跳变；sticky模块通过加密Cookie实现与后端绑定，脱离IP依赖，提升会话稳定性。
Nginx 原生 ip_hash 确实存在跨公网、NAT、代理等场景下失效的问题——多个真实用户可能共享同一个出口 IP，导致被哈希到同一台后端，而另一些后端却长期空闲；更严重的是，当客户端 IP 因网络切换（如移动网络重连、Wi-Fi 切换）发生微小变化时，会直接“跳槽”到另一台后端，破坏会话连续性。
为什么 ip_hash 在跨网环境下不可靠
ip_hash 仅基于客户端 TCP 连接的源 IP 做哈希，不感知应用层身份。在以下常见情况中完全失准：
- 企业内网或校园网经统一出口 NAT，成百上千用户共用 1–3 个公网 IP
- 移动端频繁切换基站或 Wi-Fi，IP 地址动态变更（如从 101.22.33.44 → 101.22.33.45）
- 用户通过 CDN、反向代理（如 Cloudflare、Nginx 前置代理）访问，后端只能看到代理 IP
- HTTP/2 多路复用或长连接复用，单个 IP 可能承载多个逻辑会话
sticky 模块的核心价值：绑定会话而非 IP
第三方 nginx-sticky-module（由Evans Ye维护的主流分支）通过在响应中注入加密 Cookie（如 route=98a7f3），将客户端与某台上游服务器“粘连”。后续请求携带该 Cookie，Nginx 即路由至对应后端，彻底脱离对源 IP 的依赖。
它不修改业务逻辑，不侵入应用，只需 Nginx 层配置即可实现稳定会话保持。
编译安装与基础配置示例
注意：官方 Nginx 不内置 sticky，需重新编译（支持 1.16–1.24 主流版本）：
- 下载模块源码：
git clone https://github.com/EvansYe/nginx-sticky-module.git - 进入 Nginx 源码目录，追加编译参数：
--add-module=/path/to/nginx-sticky-module - 执行
./configure && make && sudo make install
配置示例（upstream 块中启用）：
upstream backend {
sticky expires=1h domain=.example.com path=/ httponly secure;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
关键参数说明：
-
expires：Cookie 过期时间（建议设为略长于业务会话预期生命周期） -
domain：确保子域名间共享 Cookie（如设为.example.com） -
secure+httponly：生产环境必须开启，保障传输与存储安全
进阶建议：容错与平滑迁移
单一 sticky 机制仍有风险（如 Cookie 被禁、客户端清理），推荐组合策略提升鲁棒性：
-
fallback to ip_hash：在 sticky Cookie 无效时，降级使用
ip_hash（需 patch 或配合 map 指令判断） -
健康检查联动：启用
health_check，自动摘除故障节点，sticky 会自动重分配新 route - 灰度上线验证：先对部分 location 或 header 标识用户启用 sticky，对比日志中 backend 分布与 session 错误率
-
避免与 proxy_cache 冲突：若启用缓存，确保
stickyCookie 不被缓存污染（添加proxy_ignore_headers Set-Cookie;）
sticky 模块不是银弹，但它精准补上了 ip_hash 在现代网络拓扑下的关键短板——用可管理的、应用无关的会话标识替代脆弱的网络层地址。只要合理配置加密强度、过期策略与降级路径，就能在不改一行业务代码的前提下，显著提升多实例部署下的会话稳定性。
