Nginx负载均衡核心在于算法选型：轮询适合无状态服务，权重适配硬件差异，ip_hash解决session粘滞；三者需依业务约束匹配，非简单配置upstream即可。
Nginx负载均衡不是配个upstream就完事，关键在算法选型——选错会导致会话丢失、缓存失效、性能瓶颈甚至雪崩。轮询适合无状态服务，权重适合硬件差异大的集群，ip_hash则专治session粘滞问题。三者不是互斥关系，而是要按业务真实约束来匹配。
轮询算法：简单公平，但只适合“均质”后端
轮询是Nginx默认策略，请求按顺序逐一分发到每个server，自动跳过max_fails超限且处于fail_timeout内的宕机节点。它不看CPU、不看连接数、不看响应时间，只讲“轮到谁就是谁”。
- 适用场景：API网关、静态资源服务、短平快的无状态微服务（如鉴权校验、日志上报）
- 配置要点：无需额外指令，但建议显式加
max_fails=3 fail_timeout=30s提升容错能力 - 风险提示：若某台后端因慢SQL或GC卡顿，轮询仍会持续转发请求，可能加剧故障；此时需配合健康检查或切换为least_conn
权重算法：让强机器多扛活，但不能掩盖架构缺陷
weight不是调参玩具，而是对物理现实的妥协表达。比如一台16核64G服务器设weight=4，另一台8核32G设weight=2，Nginx会在一轮5次请求中分给前者4次、后者1次（非严格比例，受内部调度影响）。
- 可与
ip_hash共存（1.3.1+版本），实现“同IP优先固定+按能力扩容” - 不可与
backup混用；权重值建议控制在1–10之间，避免过大导致小权重节点长期饥饿 - 注意：权重只影响新连接分配，不改变已有长连接的归属，也不解决单点过载问题
ip_hash算法：会话稳定的刚需解法，但有隐藏代价
ip_hash通过对客户端IPv4地址前3段（或完整IPv6）哈希，确保同一IP始终落到同一台后端。这是解决传统Session未共享时“登录后跳转登出”问题最轻量的方案。
- 必须放在
upstream块顶部，且不能和hash $request_uri等其他hash策略并存 - 缺点明显：NAT环境（如企业出口、4G/5G基站）下大量用户共享IP，易造成单台后端被挤爆；IPv6地址变动频繁也会破坏稳定性
- 替代思路：改用
hash $cookie_jsessionid或接入Redis集中式Session，比依赖IP更可控
进阶提醒：别只盯着这三种，动态策略才是破局点
真实生产环境很少只靠静态算法。当出现接口响应毛刺、突发流量或灰度发布时，轮询/权重/ip_hash都显得被动。
-
least_conn适合长连接密集型服务（如WebSocket、gRPC流式接口） -
least_time first_byte（Nginx Plus或开源版1.19.10+）能真正按实时性能调度，但需开启keepalive和准确的健康探测 - URL哈希（
hash $request_uri consistent）对CDN回源或静态资源缓存命中率提升显著，但要注意带参URL的标准化处理
