Nginx本身不管理Session，粘性会话仅通过ip_hash或cookie绑定客户端与后端服务器以避免会话丢失；真正可靠方案是后端集中存储（如Redis），ip_hash最简但受NAT、IP变动影响，cookie方案更稳定但开源版需第三方模块或后端配合。
Nginx 本身不存储或管理 Session，所谓“粘性会话”只是让同一客户端的请求持续转发到同一台后端服务器，避免因 Session 存在本地内存导致的掉线、购物车清空等问题。真正可靠的 Session 一致性，必须靠后端集中存储（如 Redis），但若短期无法改造后端，可通过 Nginx 层做请求路由绑定。
用 ip_hash 实现最简粘性
这是开源版 Nginx 原生支持、无需编译模块的方式，适合测试环境或用户 IP 相对稳定的小型部署：
- 必须写在 upstream 块内，且不能与
least_conn、hash $cookie_xxx等其他 hash 类指令共存 - 对 IPv4 使用前三个字节哈希（如
192.168.1.x→ 视为同一 IP 段），IPv6 则使用完整地址 - 当某台后端宕机时，Nginx 会自动将该 IP 的请求切到其他可用节点，但会话即丢失
示例配置：
upstream backend {
ip_hash;
server 10.0.1.10:8080;
server 10.0.1.11:8080;
server 10.0.1.12:8080;
}
server {
location /api/ {
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
用 cookie 实现更稳定的粘性（需额外支持）
基于 Cookie 的方案能规避 NAT、移动 IP 变动等问题，但开源 Nginx 默认不支持 sticky 指令：
- Nginx Plus（商业版）原生支持：
sticky cookie srv_id expires=1h domain=.example.com path=/; - 开源版需手动编译第三方模块（如
nginx-sticky-module-ng），但存在兼容风险：不同 Nginx 版本需匹配特定 commit，HTTP/2 或 TLS 场景下 cookie 注入可能失效 - 替代做法：由后端应用首次响应时 Set-Cookie（如
Set-Cookie: ROUTEID=backend-01; Path=/; HttpOnly），Nginx 再用hash $cookie_ROUTEID转发——这要求后端配合，且首请求仍需靠ip_hash或轮询落定
绕开 Nginx，从后端根治 Session 问题
所有粘性方案都是临时缓解，本质缺陷未变：单点故障导致会话丢失、扩缩容引发哈希重散列、无法真正共享状态。推荐优先改造后端：
- Java/Spring Boot：接入
spring-session-data-redis，Session 全量存 Redis - PHP：修改
php.ini：session.save_handler = redis，session.save_path = "tcp://10.0.2.5:6379" - Node.js：用
express-session配合connect-redisStore - 老旧 ASP.NET：若无法改代码，至少把 Session 存 SQL Server 或 StateServer，而非默认 InProc
注意事项与常见踩坑
实际配置中容易忽略的关键细节：
-
ip_hash对公司内网、校园网、4G/5G 用户效果差——大量真实用户共用一个出口 IP，流量全压到一台后端 - 添加或删除 upstream 中的 server 会导致全部 IP 的哈希结果重分布，已有用户大概率跳节点
- 不要在
location块里写ip_hash，它只在upstream块中生效 - 若前端还有 LVS/HAProxy 等四层负载，需确认它是否做了 SNAT——若做了，Nginx 收到的全是负载均衡器 IP，
ip_hash就完全失效
