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)。
它适合什么场景
适用于客户端 IP 相对稳定、且后端无状态或 Session 已集中存储(如 Redis)的轻量级部署。
使用 Playwright 为 jimeng.jianying.com 管理浏览器会话,导入 cookies/localStorage 以自动化视频生成工作流,支持图片上传等功能
- 内网服务调用(如公司内部系统,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 行为
不复杂但容易忽略










