在 nginx 中，ip_hash 和 hash 指令不能同时用于同一个 upstream 块，因为它们是互斥的负载均衡算法。要实现基于 ip 地址的哈希一致性，应使用 hash $remote_addr consistent; 替代 ip_hash。consistent 参数启用一致性哈希算法，能显著减少服务器节点变动时的缓存失效问题。
ip_hash 与 hash 的核心区别是什么
ip_hash 是 Nginx 内置的简单哈希算法，它根据客户端 IP 计算哈希值并映射到后端服务器列表，不支持一致性哈希，且无法自定义哈希键。而 hash 指令允许指定任意变量（如 $remote_addr）作为哈希键，并通过 consistent 关键字开启一致性哈希算法。两者在实现机制上完全不同，配置时只能二选一。
http {
upstream backend {
# 错误示范：这两行会引发配置冲突
# ip_hash;
# hash $remote_addr consistent;
# 正确做法：仅使用 hash 指令配合 consistent
hash $remote_addr consistent;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
server {
listen 80;
location / {
proxy_pass http://backend;
}
}
}
如何验证一致性哈希的效果
一致性哈希通过虚拟节点技术，使得当某个后端服务器上线或下线时，只有少量请求需要重新路由，从而保护缓存命中率。验证方法是通过日志观察不同客户端 IP 的请求分布，并在模拟服务器宕机后检查剩余服务器的负载变化。相比 ip_hash 的固定轮询映射，hash ... consistent 能更平滑地处理节点变更。
# 测试脚本示例 (Python)
import requests
servers = ['http://192.168.1.10:8080', 'http://192.168.1.11:8080', 'http://192.168.1.12:8080']
ips = [f'10.0.0.{i}' for i in range(1, 11)]
# 模拟请求，实际需通过 Nginx 代理层注入 X-Forwarded-For 头
for ip in ips:
resp = requests.get('http://localhost/', headers={'X-Forwarded-For': ip})
print(f"IP: {ip} -> Server: {resp.headers.get('Server')} | Status: {resp.status_code}")
# 预期结果：相同 IP 始终访问同一服务器，且节点增减时影响最小化
当后端服务器权重不同时如何处理
在使用 hash $remote_addr consistent; 时，Nginx 默认对所有后端服务器赋予相同权重。若需调整权重，可在 server 指令后添加 weight 参数，但需注意一致性哈希算法对权重的支持有限，通常建议结合 zone 共享状态或使用外部一致性哈希服务。对于大多数场景，保持权重一致即可确保哈希分布均匀。
