AWS目标组（Target Group）异常：请求始终路由至同一目标实例

这种情况我之前在调试云负载均衡的时候碰到过好几次，别着急，咱们从几个常见的点排查：

• 会话粘滞（Session Stickiness）意外启用：尽管你以为用的是轮询算法，但如果开启了会话粘滞，负载均衡器会把来自同一个客户端的请求持续转发到同一个后端实例。很多时候是配置时误操作开启，或者之前测试粘滞功能后没关闭，导致看起来所有流量都走一个实例。
• TCP连接复用导致的流量绑定：浏览器、curl等客户端默认会复用TCP连接，一旦和负载均衡器建立了长连接，负载均衡器会在这个连接生命周期内把所有请求都发给同一个实例。这种情况下，你用同一个客户端测试就会一直命中同一个实例。
• 配置未实际生效：你修改了负载均衡算法或参数，但云平台的配置可能没同步，或者有缓存，导致轮询逻辑没真正启用。
• 健康检查的隐性问题：虽然你看到两个实例都显示健康，但可能健康检查的阈值、响应时间配置有问题，导致负载均衡器实际上只把流量分配给了其中一个（不过这种情况你注销第一个实例后才切换的现象不太典型，但也值得排查）。

• 检查并调整会话粘滞配置：
  进入你的负载均衡器或目标组配置页面，找到「会话粘滞」（部分平台叫Sticky Sessions）选项。如果不需要会话保持，直接关闭；如果业务需要，把粘滞超时时间设置得短一些（比如30秒），避免长时间绑定同一个实例。
• 用不同方式测试流量分配：
  • 用多个浏览器、隐身窗口或者不同设备访问负载均衡器，看是否会分发到不同实例。
  • 用curl命令强制关闭连接复用，模拟每次请求都建立新连接：

    curl -H "Connection: close" http://你的负载均衡器地址
    

    多执行几次这个命令，查看返回的实例标识（比如在后端实例的响应里加个实例ID标记），确认是否轮询到两个实例。
• 验证配置是否生效：
  确认你修改的负载均衡算法已经保存并同步，部分云平台需要手动触发配置更新，或者等待1-2分钟让配置生效。可以尝试重新关联目标组，或者重启负载均衡器（如果业务允许的话）。
• 查看负载均衡器访问日志：
  开启负载均衡器的访问日志功能，日志里会记录每个请求转发到的后端实例ID。通过分析日志，你能直观看到流量是否真的只流向一个实例，也能排查出是客户端问题还是负载均衡器配置问题。
• 重新确认健康检查配置：
  检查目标组的健康检查路径、端口、预期响应码是否正确，确保两个实例都能稳定返回健康状态。查看负载均衡器的健康检查日志，确认两个实例都被标记为「健康」且在流量池内。

内容的提问来源于stack exchange，提问作者pvpkiran