ELB 后端服务器健康检查异常排查：从检查参数到安全组的七步清单

负载均衡（ELB）上线后，最常见的问题之一就是后端服务器组里的实例显示“异常”，请求被转发到少数几台机器，甚至全部 502/503。本文记录一套我自己常用的排查顺序，从健康检查配置一路查到安全组和应用本身，每一步都可以直接在命令行验证。

一、先弄清楚健康检查在做什么

ELB 的健康检查由负载均衡器从自己的后端子网地址主动发起探测，常见有 TCP、HTTP、HTTPS 几种。探测连续失败达到“最大重试次数”后，实例会被标记为异常并摘除；连续成功达到阈值后才会恢复。排查前先在控制台记下四个参数：检查协议、检查端口、检查路径（HTTP 时）、超时时间与间隔。很多问题只是这四个参数和应用实际行为对不上。

二、确认应用本身能正常响应

先登录后端服务器，在本机验证应用是否真的在监听、能否返回预期状态码：

ss -lntp | grep 8080
curl -i -m 3 http://127.0.0.1:8080/healthz

需要关注三点：一是监听地址是不是 127.0.0.1，如果应用只绑定了回环地址，外部探测一定失败，要改成 0.0.0.0 或内网地址；二是返回码，HTTP 检查只接受配置的期望状态码，例如应用对未登录请求返回 401，就会被判定失败；三是响应耗时，如果 /healthz 里顺带查了数据库，数据库抖动时整个后端都会被摘除，建议健康检查接口只检查进程自身是否可服务。

三、检查安全组和网络 ACL

应用正常但探测仍失败，下一个怀疑对象就是网络策略。要点是：入方向规则必须放通来自负载均衡器所在子网（或其后端地址段）的检查端口，而不仅仅是业务端口。如果健康检查端口与业务端口不同，这一点极易遗漏。同时检查子网绑定的网络 ACL，ACL 是无状态的，入出两个方向都要放行。

可以在后端服务器上抓包，直接判断探测包是否到达：

tcpdump -nn -i eth0 port 8080 and not host 127.0.0.1

如果看到 SYN 进来但没有 SYN-ACK 出去，说明本机防火墙（iptables、firewalld）或应用未监听；如果压根没有包，问题在安全组、ACL 或路由上。

四、系统层面的常见坑

• 本机防火墙：firewalld 默认只放行 22 等少数端口，业务端口要显式 add。
• 半连接队列：高并发时 somaxconn 与应用 backlog 过小，探测包被丢弃，表现为间歇性异常。可用 ss -lnt 查看 Recv-Q 是否长期堆积。
• 文件句柄：句柄耗尽时新连接无法建立，ulimit -n 与 /proc/PID/limits 能快速确认。

五、调整健康检查参数的原则

参数不是越严越好。间隔过短、超时过小，会在应用做 GC 或短暂抖动时造成误摘除；间隔过长、重试次数过多，则故障实例迟迟不被摘除，用户会持续看到错误。我的经验值是：间隔 5 秒、超时 3 秒、不健康阈值 3 次、健康阈值 2 次，这样故障约 15 秒内被摘除，恢复约 10 秒内回归。滚动发布场景下，还要保证应用启动完成前健康检查接口不返回成功，避免流量提前打到未就绪的实例。

六、一份可复用的排查清单

1. 控制台记下检查协议、端口、路径、超时、间隔。
2. 在后端本机 curl 检查接口，确认状态码和耗时。
3. 确认监听地址不是 127.0.0.1。
4. 核对安全组入方向是否放通检查端口，检查 ACL 双向规则。
5. 用 tcpdump 判断探测包是否到达、是否有应答。
6. 检查本机防火墙、backlog 与文件句柄限制。
7. 最后再微调健康检查阈值，并在变更后观察一个完整的探测周期。

总结

ELB 后端“异常”绝大多数不是平台问题，而是检查参数、监听地址、安全组、应用响应这四处中的一处没对上。按“应用自身 → 网络策略 → 系统限制 → 参数调优”的顺序逐层缩小范围，通常十分钟内就能定位。把健康检查接口做得轻量、只反映自身可服务状态，是长期稳定运行最值得做的一件事。