Nginx默认不支持Sticky会话，因其upstream采用轮询、ip_hash等无状态策略，不解析应用层会话且不维护客户端与后端绑定；需借助nginx-sticky-module、ip_hash或Session共享实现。
在Nginx反向代理场景中，会话保持（Session Persistence）不是Nginx原生内置的功能，而是通过第三方模块（如 nginx-sticky-module）或上游服务协同实现的。Sticky配置的核心目标是：让同一客户端的后续请求持续转发到同一台后端服务器，避免因负载均衡打散会话导致登录态丢失、购物车清空等问题。
为什么Nginx默认不支持Sticky会话？
Nginx的 upstream 默认采用轮询（round-robin）、IP哈希（ip_hash）等无状态调度策略。它不解析应用层会话（如 JSESSIONID、PHPSESSID），也不主动维护客户端与后端之间的绑定关系。因此，若后端应用依赖内存级会话（如未使用Redis共享Session），就必须显式启用Sticky机制。
常用Sticky实现方式对比
- ip_hash：最轻量方案，按客户端IP做哈希，固定分发到某台后端。缺点是NAT环境下失效（多用户共用IP）、移动端IP易变、无法应对IP漂移。
-
cookie-based sticky（nginx-sticky-module）：由Nginx在响应中注入自定义Cookie（如
route=1），后续请求携带该Cookie，Nginx据此路由。需编译安装模块，支持过期时间、加密、domain/path设置。 - upstream配合应用层Session共享：更现代的解法——禁用Sticky，改用Redis/Memcached集中存储Session，所有后端读写同一份会话数据。此时Nginx可完全无状态运行，扩展性与容错性更强。
nginx-sticky-module实战配置示例
假设已编译安装该模块（常见于OpenResty或手动编译Nginx时添加），典型配置如下：
upstream backend {
sticky name=route expires=1h domain=.example.com path=/;
server 10.0.1.10:8080;
server 10.0.1.11:8080;
server 10.0.1.12:8080;
}
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
说明：
– name=route 指定Cookie名，后端无需识别，Nginx自行解析；
– expires=1h 控制Cookie有效期，超时后重新分配；
– 若后端主动返回同名Cookie（如应用设了 Set-Cookie: route=2），Nginx会优先信任该值并绑定对应server。
注意事项与排错要点
- Sticky Cookie必须在首次响应中由Nginx注入，若后端应用提前写了同名Cookie（尤其带HttpOnly或Secure标记），可能覆盖或冲突，建议统一由Nginx管理route cookie。
- 健康检查（health_check）需与Sticky协同：当某台server宕机，Nginx应自动剔除并重映射route值，避免“粘滞失效”导致502/503。
- HTTPS环境下务必配全
secure和httponly参数（如sticky ... secure httponly;），否则浏览器可能拒绝发送Cookie。 - 测试时可用
curl -I查看响应头是否含Set-Cookie: route=...，再带该Cookie发起二次请求，验证是否命中同一后端（可通过日志或后端返回的X-Backend-ID确认）。
Sticky不是银弹。高可用架构中，优先推荐解耦会话存储；仅当短期迁移受限、后端改造成本过高时，才选用Nginx Sticky作为过渡方案。理解其原理与边界，才能避免陷入“粘住了却不可用”的运维陷阱。
