ip_hash是nginx内置的ip哈希会话保持机制，通过客户端ipv4前三个字节或完整ipv6地址哈希，将同一ip请求固定转发至同一后端服务器；它配置简单、零侵入，但存在nat倾斜、ip变更失联、不支持weight、故障时会话中断等局限，适用于内网稳定ip且无代理的场景。
IP Hash 在 Nginx 中主要解决会话保持问题，但它的性能开销和分发效果需要具体权衡——不是“用了就稳”，而是“用得对才值”。
哈希计算带来可观 CPU 开销
ip_hash 对客户端 IP 做固定哈希（IPv4 用 32 位，IPv6 取前 64 位再哈希），每次请求都要执行完整哈希运算。在万级 QPS 场景下，这部分计算可能占 worker 进程总 CPU 时间的 8%～20%。尤其当大量 IPv6 请求或 URI 动态参数混杂时，分支判断和内存读取进一步放大开销。
- 用 hash $remote_addr 替代 ip_hash，可跳过 IPv6 兼容逻辑，实测降低约 15% 哈希耗时
- 避免在不需要会话粘滞的静态服务中启用 ip_hash，纯轮询模式下 worker CPU 通常仅 5%～15%
- 若必须用哈希且追求更高一致性，ketama 模式虽运行时查询为 O(log N)，但首次加载 upstream 时内存与初始化 CPU 成本明显上升
分发不均是常见隐性代价
IP Hash 的本质是把 IP 映射到固定后端，天然无法应对真实流量分布：NAT 网关、移动基站、CDN 节点会让大量用户共享同一个出口 IP，导致单台后端瞬间承接远超平均值的请求。三台服务器配置下，实测流量倾斜达 6:2:2 甚至更极端。
- 公网用户经运营商 NAT 后，几十万人可能只呈现几百个源 IP
- 企业内网访问常集中于少数出口防火墙 IP，加剧后端负载失衡
- 没有自动降级机制，某台 server 故障时，对应哈希槽位的全部请求直接 502，不像轮询或 least_conn 可自动绕过
适用场景其实很窄
ip_hash 不是通用解法，只在明确需要服务端强会话绑定、且客户端 IP 分布足够离散时才合理。例如内部管理系统、后台运营平台，用户基数小、出口 IP 多样、无 CDN 中转。
- 电商前台、API 网关、微服务入口等场景，优先考虑 cookie hash 或 token-based session 路由，把亲和逻辑交给业务层
- 若必须用 IP 级粘滞，建议搭配 proxy_cache_use_stale error timeout updating 缓解故障节点影响
- 上线前务必用真实 IP 分布做压测，而非本地 loopback 或简单 ab 工具模拟
真正影响稳定性的，往往不是算法多先进，而是它是否匹配你的流量特征和容错预期。
