测试 nginx ip_hash 策略的会话保持效果，核心在于验证来自同一客户端 ip 的请求是否始终被路由到同一个后端服务器。具体做法是启动一个包含多个后端节点的 nginx 集群，配置 upstream 块使用 ip_hash 指令，然后通过脚本模拟不同 ip 或固定 ip 发起多次 http 请求，观察响应头或日志中返回的后端节点 id 是否一致。
如何配置 ip_hash 并验证单 IP 一致性
在 Nginx 配置文件中，只需在 upstream 块中添加 ip_hash 指令即可启用该策略。为了验证效果，需要编写一个简单的 Python 脚本，使用固定的源 IP（或通过代理模拟）向 Nginx 发送请求，并检查每次请求到达的后端服务器地址。如果配置正确，连续多次请求应始终指向同一个后端实例，除非该实例宕机触发故障转移。
events {
worker_connections 1024;
}
http {
upstream backend {
ip_hash;
server 127.0.0.1:8081;
server 127.0.0.1:8082;
server 127.0.0.1:8083;
}
server {
listen 80;
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
}
}
}
上述配置定义了三个本地后端服务，Nginx 将根据客户端 IP 的哈希值分配请求。运行以下 Python 脚本进行验证：
import requests
# 假设 Nginx 监听在 localhost:80
url = "http://127.0.0.1/"
headers = {
"X-Forwarded-For": "192.168.1.100" # 模拟固定客户端 IP
}
for i in range(5):
response = requests.get(url, headers=headers)
print(f"Request {i+1}: Backend returned status {response.status_code}")
# 实际测试中，可通过后端返回其端口号来确认具体节点
预期结果是所有请求都成功返回，且后端日志显示它们都被分发到了同一个端口（例如 8081）。若后端服务返回了其监听的端口号作为响应体，则可以看到输出中端口号保持一致。
如何处理 ip_hash 导致的负载不均问题
ip_hash 策略的一个显著缺点是可能导致负载不均，特别是当客户端 IP 分布不均匀或存在大量用户共享同一个出口 IP（如 NAT 环境）时。为了解决这个问题，可以结合 hash 指令的自定义键值功能，或者引入一致性哈希算法。此外，可以通过调整后端服务器的权重来平衡流量，尽管这不能完全解决哈希分布不均的问题，但能在一定程度上缓解热点节点压力。
upstream backend_weighted {
hash $remote_addr consistent;
server 127.0.0.1:8081 weight=3;
server 127.0.0.1:8082 weight=1;
server 127.0.0.1:8083 weight=1;
}
使用 hash $remote_addr consistent; 替代 ip_hash 可以实现一致性哈希，减少服务器变更时的数据迁移。同时，通过设置不同的 weight 参数，可以让处理能力更强的服务器承担更多请求。测试时，同样使用之前的 Python 脚本，但观察各后端节点的请求数量分布，确保高权重节点确实接收了更多流量，且同一 IP 的请求仍保持粘性。
当后端服务器宕机时 ip_hash 的行为表现
在 ip_hash 策略下，如果某个后端服务器宕机，Nginx 会自动将该服务器从可用列表中移除，并将原本分配给它的请求重新哈希到其他存活服务器上。这意味着，对于受影响的客户端 IP，其会话可能会被转移到新的后端节点，导致短暂的会话丢失。这种故障转移行为是自动的，无需手动干预，但应用层需具备处理会话中断的能力。
