ip_hash与SSL会话复用不直接冲突，但因哈希源错位、ticket.key集群不一致、shared cache耦合及真实IP未还原，会导致复用表象失效；须统一ticket.key、启用real_ip_header、禁用shared cache，并分步用openssl和access.log验证。
ip_hash 和 SSL Session 复用本身不直接冲突，但它们在实际部署中会因配置叠加、作用对象错位或日志误判，引发“看似复用失效”或“会话保持异常”的现象。排查重点不是找二者互斥的代码逻辑，而是厘清：谁在哈希？谁在复用？哈希源和复用锚点是否一致？
确认 ip_hash 的哈希源是否被 SSL 配置干扰
ip_hash 默认基于 $remote_addr 计算，而 SSL 会话复用（尤其是票据模式）依赖客户端真实 IP + TLS 层协商。若前置有 CDN/WAF/反向代理，且未正确还原真实 IP：
- ip_hash 实际哈希的是代理节点 IP（如 10.10.10.1），导致大量用户被“钉”到同一后端，掩盖了复用行为
- SSL 复用日志中显示 Reused，但请求全挤在一台机器上，误以为“复用没起作用”，实则是负载不均放大了单点压力
- 必须配置 set_real_ip_from + real_ip_header X-Forwarded-For（或 CF-Connecting-IP 等），确保 $remote_addr 是用户真实 IP，ip_hash 和 SSL 日志才具备可比性
检查 SSL 会话票据（tickets）是否跨节点一致
ip_hash 保证请求路由固定，但 SSL 复用需票据密钥全局统一。若集群中各 Nginx 节点 ticket.key 不一致：
- 客户端首次连接 A 节点，获得票据；第二次连接因 ip_hash 仍落到 A，复用成功 → 日志显 Reused
- 但若某次请求因健康检查临时切到 B 节点（如 A 暂时不可用），B 无法解密 A 发的票据，强制新建会话 → 表现为“复用中断”
- 验证方式：所有节点执行 sha256sum /etc/nginx/ticket.key，结果必须完全相同；文件大小必须为 48 字节
排除 shared session cache 与 ip_hash 的隐性耦合
若同时启用了 ssl_session_cache shared:SSL:10m 和 ip_hash：
- shared cache 依赖 worker 进程间共享内存，而 ip_hash 的路由结果可能让多数请求只命中少数 worker，导致缓存利用率低、命中率差
- 更严重的是：当某台后端因 ip_hash 过载重启，其关联的 session 缓存条目失效，客户端重连时即使还在同一台 Nginx 上，也可能因缓存 miss 而重建会话
- 建议：启用 ssl_session_tickets on 后，显式关闭有状态缓存 —— ssl_session_cache off
用 openssl 分步验证，分离问题归属
别依赖单一日志判断。分两步终端验证：
- 第一步（验证 ip_hash 是否生效）：用同一公网 IP（如手机热点）连续发起 5 次请求，检查 Nginx access.log 中 $upstream_addr 是否始终相同
-
第二步（验证 SSL 复用是否生效）：在该 IP 下执行：
openssl s_client -connect example.com:443 -servername example.com -reconnect 2>/dev/null | grep -E "(New|Reused|Session-ID)"
若多次输出 Reused 且 Session-ID: 为空，则票据复用正常；若出现 New 或 Session-ID 非空，问题在 SSL 配置侧，与 ip_hash 无关
