Nginx ip_hash怎么测试ip_hash抗压性能与单机瓶颈-Nginx-PHP中文网

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

nginx ip_hash怎么测试ip_hash抗压性能与单机瓶颈

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

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

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

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

Nginx Hosting

通过服务器本地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 或进程）。