对无状态业务来说，ip_hash完全没必要且有害；因其破坏负载均衡、阻碍扩缩容、增加运维负担，而轮询或least_conn等策略更契合无状态架构的弹性与高可用需求。
对无状态业务来说，ip_hash 完全没有必要，甚至可能带来反效果。
无状态业务的本质不需要会话绑定
真正的无状态业务（如 RESTful API、静态资源服务、JWT 鉴权的前后端分离应用）不依赖服务器内存中的 Session 或本地缓存。用户凭证（如 token）自包含校验信息，后端只需解析验证，无需查 session、不读写本地状态。这种场景下：
- 轮询或 least_conn 就能均匀分发请求，天然支持弹性扩缩容
- 任意节点故障，流量自动切走，用户无感知
- 加节点、减节点、滚动发布都不影响会话连续性
强行启用 ip_hash 反而破坏无状态优势
如果在无状态架构中误配 ip_hash，会导致：
- 负载不均：IP 分布不均时，部分节点承接过多请求（尤其内网 NAT 环境）
- 扩容失效：新增后端节点不会被自动纳入均衡，哈希结果固定映射，新机器长期空转
- 运维负担：必须手动维护 upstream 列表顺序，禁止动态变更，丧失云原生弹性能力
- 代理干扰风险：若未正确配置 real_ip，所有请求哈希为同一代理 IP，流量全部打到一台机器
什么情况下容易误以为“需要 ip_hash”
常见误解来源是业务尚未真正无状态化，例如：
- 虽用 JWT，但后端仍查 Redis 缓存用户权限，且缓存 key 依赖本地进程变量
- 前端传 token，后端却把登录态二次写入 HttpSession（如 Spring Security 默认配置）
- 日志、限流、埋点等中间件依赖 request 层面的“会话上下文”，实际耦合了节点生命周期
这类情况应修复业务逻辑，而非用 ip_hash 掩盖状态残留。
替代方案更匹配无状态设计
无状态业务推荐直接采用：
- 轮询（默认）：简单、公平、零配置开销
- least_conn：适合响应时间波动大的接口，优先分发给连接数少的节点
- hash $request_uri consistent：需缓存一致性时（如 CDN 回源），按 URI 哈希保证相同路径总打同节点
只要后端不存状态，路由策略就该服务于可用性与扩展性，而不是绑定 IP。
