ip_hash 是 Nginx 基于客户端 IP 哈希实现会话保持的轻量级机制，通过哈希 IPv4 前三段或 IPv6 地址并取模后端数量，确保同 IP 请求固定路由；但依赖真实 IP 可还原、后端列表稳定，易受 NAT、代理、节点变更影响，推荐生产环境改用 cookie 哈希或 Redis 共享 Session。

Nginx 的 ip_hash 是一种会话保持策略，它把同一客户端 IP 的请求始终转发到同一台后端服务器。这种机制对有状态业务（如登录态、购物车）很实用，但也会带来负载不均和单点压力集中的风险。测试它的抗压性能与单机瓶颈，核心不是测“ip_hash 本身快不快”，而是验证：在 ip_hash 策略下，后端节点是否出现明显负载倾斜？哪台机器最先成为瓶颈？整个集群吞吐是否受限于最弱节点？

下面从实操角度分三块说明：

如何验证 ip_hash 是否生效并观察分配效果

这是测试前提，确保策略已正确加载且行为符合预期。

Nginx Config Linter

对 Nginx 配置文件进行语法检查、验证和安全、性能审计。

下载

• 在 Nginx 配置中启用 ip_hash，例如：

  upstream backend {
      ip_hash;
      server 192.168.1.110:80;
      server 192.168.1.109:80;
  }

• 用多台不同公网 IP 的压测机（或通过代理/ NAT 模拟不同源 IP）发起请求；
• 查看 Nginx 访问日志（/var/log/nginx/access.log），确认相同 IP 的请求是否始终打到同一台后端；
• 也可临时加 log_format 打印 $upstream_addr，直接看到转发目标：

  log_format main '$remote_addr - $upstream_addr [$time_local] "$request" $status';

如何压测 ip_hash 下的单机瓶颈

重点是让流量“真实集中”到某一台后端，暴露其极限。

• 使用 固定源 IP + 高并发 方式压测（绕过轮询，强制触发 ip_hash 路由）：
  • Linux 下用 curl 或 wrk 指定源 IP（需 root 权限）：

    wrk -t4 -c500 -d60s --latency http://nginx-lb/ --timeout 10s
    # 同时在另一台机器上，用相同源 IP（如通过 iptables SNAT 或 cloud provider 的固定出口 IP）再发一轮

  • 更可靠的做法：用 3–5 台压测机，每台只用 1 个固定公网 IP，分别向 Nginx 发起 200 并发，这样最多形成 5 个 IP 哈希桶，很可能 2–3 个落到同一台后端；
• 监控目标后端服务器的关键指标：
  • CPU 使用率持续 >85%；
  • 应用线程池满、DB 连接池耗尽、响应时间突增（P95 > 2s）；
  • netstat -ant | grep :80 | wc -l 观察 ESTABLISHED 连接数是否逼近 net.core.somaxconn 或应用最大连接限制；
• 对比另一台空闲后端的资源使用率（应远低于 30%），确认负载倾斜确实存在。

如何评估整体抗压能力是否受 ip_hash 制约

这一步判断的是：是不是因为 ip_hash 把流量锁死在弱节点，拖垮了整条链路？

• 设计两组对比压测：
  • A 组：启用 ip_hash，用 5 个不同源 IP，每个 IP 发起 200 并发（共 1000 并发）；
  • B 组：改用 least_conn 或默认轮询，同样 5×200 并发；
• 对比关键结果：
  • 总 TPS（每秒事务数）：B 组是否显著高于 A 组？
  • 错误率（5xx / timeout）：A 组是否集中在某台后端对应时段？
  • 后端 CPU 分布标准差：A 组的标准差通常比 B 组高 2–3 倍；
• 若 A 组 TPS 下降 >20%，且某台后端 CPU/响应延迟率先飙升，则说明 ip_hash 已成为实际瓶颈，需考虑：
  • 改用 hash $remote_addr consistent;（一致性哈希，扩缩容影响更小）；
  • 加入 down 或 backup 标记临时隔离弱节点；
  • 后端服务自身做横向扩容（比如该节点部署更多 Pod 或进程）。

不复杂但容易忽略：ip_hash 的哈希桶数量固定（默认基于 IPv4 地址 32 位计算），当真实用户 IP 集中（如大量用户走同一个运营商出口 NAT），会导致多个用户被映射到同一后端——这不是配置错误，而是网络现实。所以生产环境用 ip_hash，一定要配合后端服务的弹性伸缩能力。