ip_hash是Nginx内置的会话保持机制，通过对客户端IPv4前三个字节或完整IPv6地址哈希，将同一IP请求固定转发至同一台后端服务器；它无需额外模块，但不支持weight、易受NAT和IP变更影响，适用于内网稳定IP场景。

用 ip_hash 是 Nginx 实现会话保持最直接的方式，它让同一 IP 的请求始终打到同一台后端服务器，从而避免 Session 丢失。但要注意它不是万能解，得看你的业务场景是否适配。

ip_hash 是怎么工作的

它对客户端真实 IP 做哈希运算，再根据结果固定映射到某台 upstream 服务器。只要 IP 不变、后端列表不变，路由就稳定。Nginx 内置支持，无需额外编译模块或安装插件。

• 只作用于 IPv4 地址的前三个字节（如 192.168.1.x → 视为同一组）
• IPv6 地址则取完整地址哈希
• 如果某台 server 被标记为 down 或不可用，Nginx 会自动将其从哈希环中剔除，后续请求重新分配

基础配置写法

在 upstream 块里加一行 ip_hash; 就够了：

upstream backend {
    ip_hash;
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
}

server {
    listen 80;
    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

注意：ip_hash 和 weight 不能共存——加了 weight 会导致 Nginx 启动报错。如需权重控制，得换用其他策略（比如 hash $remote_addr consistent）。

Browser Session Manager

使用 Playwright 为 jimeng.jianying.com 管理浏览器会话，导入 cookies/localStorage 以自动化视频生成工作流，支持图片上传等功能

下载

它适合什么场景

适用于客户端 IP 相对稳定、且后端无状态或 Session 已集中存储（如 Redis）的轻量级部署。

• 内网服务调用（如公司内部系统，IP 段固定）
• 后台管理类应用（用户少、不频繁切换网络）
• 临时验证环境或灰度发布阶段快速绑定

不适合公网高并发场景：手机用户切 WiFi/4G、企业 NAT 出口、CDN 回源等都会导致大量用户被压到同一台机器，反而引发负载倾斜甚至雪崩。

常见问题与应对

ip_hash 本身简单，但线上容易踩坑：

• 后端宕机导致会话丢失：挂掉的机器上所有活跃 Session 都无法恢复。建议搭配 Session 外置（如 Redis）使用
• IP 变更中断会话：用户从 4G 切到 WiFi，IP 改了，Nginx 就会换机器，原 Session 找不到。此时应前端加 token + 后端统一鉴权，而非强依赖 IP 绑定
• 无法和 health_check 共用默认参数：若用了第三方健康检查模块（如 nginx_upstream_check_module），要确认其兼容 ip_hash；原生 Nginx 的 keepalive 不影响 ip_hash 行为

不复杂但容易忽略