nginx 中不存在原生 persistent 指令，长效会话绑定依赖 consistent hash 实现；通过 hash $variable consistent 配合多级 fallback、真实 ip 透传、健康检查及合理节点数，可显著减少扩缩容或故障时的会话漂移。
“persistent”不是 Nginx 原生 upstream 指令，官方配置中不存在 upstream ... { persistent ... } 这样的语法。所谓“更长效的会话绑定”，实际是指在集群扩缩容、节点故障等场景下，尽量减少用户会话漂移——这靠的是一致性哈希（consistent hash），而非某个叫 persistent 的功能。
用 hash + consistent 实现长效绑定
原生 ip_hash 只做简单取模，后端少一台，大量 IP 会重映射；而 hash $variable consistent 构建哈希环，增减节点仅影响邻近少量请求，天然支持长效粘性。
-
基础写法：用客户端真实 IP（需透传）
hash $remote_addr consistent; -
更稳写法：加端口或代理标识防冲突
hash "$remote_addr:$server_port" consistent;或hash "$http_x_real_ip:$http_user_agent" consistent; -
权重仍有效：每个 server 的
weight决定其在哈希环上的虚拟节点数量，高配机器可设更高权重
按业务维度绑定，比 IP 更长效
IP 绑定在 NAT、移动网络、CDN 后易失效。若业务已透传用户标识，优先用它：
-
hash $cookie_sessionid consistent;—— 适用于登录态由 Cookie 携带的 Web 应用 -
hash $arg_user_id consistent;—— 如请求带?user_id=789，精准且抗代理干扰 -
hash $http_x_user_id consistent;—— 网关层已注入用户 ID 的微服务架构
避免用 $args（参数顺序敏感）或 $time_iso8601（每次变），否则哈希键不稳定，绑定就失效。
多级 fallback 提升鲁棒性
单一变量可能缺失。Nginx 支持按顺序尝试多个变量，首个非空即生效：
- 配置示例：
hash $arg_user_id consistent;<br>hash $cookie_sessionid consistent;<br>hash $remote_addr consistent;
- 效果：有 user_id 就按 user_id 绑；没有就退到 sessionid；再没有才 fallback 到 IP
配套必须项，否则长效难保障
只配 hash 不够，还需确保：
-
真实 IP 可用：前端有 CDN/负载均衡时，启用
real_ip_module，配置set_real_ip_from和real_ip_header X-Forwarded-For -
健康检查在线：用
max_fails=2 fail_timeout=15s或集成nginx_upstream_check_module，及时剔除故障节点，避免哈希打到不可用机器 -
节点数合理：2 台节点时一致性哈希效果打折，建议 ≥3 台；若只有 2 台，可搭配
backup作兜底
