Nginx 的反向代理和负载均衡怎么工作？轮询与一致性哈希怎么选？

知识点详解：请求从代理进入后端，哪些决定需要说清楚

反向代理先改变了访问入口

假设三个应用实例只在内部网络运行，外部用户统一访问一个域名。Nginx 接收请求，再转发给上游，客户端不必知道每台应用的地址。

它可以在入口处理 TLS、路由、请求限制等，但每项功能都要具体配置。负载均衡只负责选择一个后端，不意味着它自动有业务鉴权或完整故障恢复。

反向代理也不同于代表客户端访问任意网站的正向代理。我们这里管理的是后端服务的入口。

分配策略针对的是不同信号

轮询按请求分配，权重反映不同实例的预期容量。最少连接关注活跃连接数量，但连接少也不必然意味着 CPU 空闲，所以仍要测实际负载。

哈希按指定 key 尽量保持映射。一致性哈希在节点变化时减少需要重新映射的 key，常用于缓存局部性；ip_hash 与配置 hash ... consistent 不是同一个指令和完整保证。

同一用户的 IP 可能变化，许多人也可能共享出口 IP。后端故障后映射还会改变，因此不要把内存 Session 的正确性完全押在 IP 粘性上。

路径和头部是常见的实际配置坑

假设外部访问 /api/users，后端希望收到 /users。是否替换路径前缀，要看 location 与 proxy_pass 是否携带 URI，以及是否使用变量或 rewrite 等配置，不能只背「末尾有斜杠就怎样」脱离上下文。

代理头也一样。后端要识别原始协议、主机与用户地址，需要建立可信代理边界；不能把用户自己传来的任意转发头都当作真实来源。

验收时把后端实际收到的路径、参数和头记录下来，覆盖普通请求与重定向。这样比盯着入口返回 200 更能发现转发错误。

超时与重试要围绕执行结果设计

连接失败、读取超时与业务返回错误不是一回事。读取超时可能发生在后端已经完成写入之后，只是响应没有及时送回。

因此写操作需要幂等键或明确的结果查询等保护。Nginx 的重试条件要按方法、错误和是否已经发送响应检查，不能把所有失败都转给另一台。

另外，开源 Nginx 的被动失败检测与主动健康检查不是一个能力范围。某项功能是否可用，要核对版本与发行产品。测试慢上游、不可达上游和长连接，观察失败摘除、恢复与请求结果。

本题机制参考：Nginx Load Balancing、Nginx Proxy Module、Nginx Upstream Module。

面试官继续追问

最少连接一定优于轮询吗？

不一定。连接数只是一个信号，任务工作量、长连接和实例差异都影响结果。

一致性哈希能保证用户永远落在同一台吗？

不能。节点或 key 变化会改变部分映射，故障也需要转移。它减少迁移，不等于永久绑定。

502 和 504 能说明业务一定没执行吗？

不能。它们反映代理链路的问题，仍需结合请求 ID 和后端状态判断结果。

面试速记卡

• 反向代理管理后端入口；负载均衡选择上游。
• 轮询、权重、最少连接、哈希各看不同信号。
• 粘性与缓存局部性，不等于状态正确性。
• 验证实际 URI、可信头与超时规则。
• 写操作失败重试要防重复结果。