ELB 健康检查一直不健康：按监听器、后端端口与安全组三层定位的 5 步

一、背景与问题

一台跑 Java 业务的 ECS 刚加进弹性负载均衡 ELB 的后端服务器组，服务本身在服务器上用 curl 访问本地端口能返回 200，控制台上后端服务器的健康检查状态却一直是“不健康”，流量始终分发不进来。重启服务、重新添加后端服务器都没用，业务看起来没有问题，负载均衡就是不转发。

这种情况最容易误判成“ELB 出问题了”。实际上健康检查是 ELB 主动从网络侧向后端服务器发起的一次探测，它失败只说明一件事：按健康检查配置的那条路径、那个端口、那个协议，后端没有按预期响应。定位时不要先调负载均衡的权重或流量策略，先把探测本身复现出来，再一层一层往下查。本文的做法就是按监听器配置、后端端口、网络与安全组这个顺序，把每一步的验证命令和判断标准写清楚。

二、前提条件

1. 已有一台弹性负载均衡 ELB、一个监听器和一个后端服务器组，后端是一台或多台 ECS。
2. 知道后端服务的监听端口和健康检查路径，例如 8080 端口的 /health 接口。
3. 能登录后端 ECS，有一台同 VPC 的机器可用于内网验证。
4. 健康检查的协议、端口、路径、期望状态码以控制台后端服务器组里的配置为准，不要凭记忆猜。
5. 操作前先记下当前配置：监听器协议与端口、后端端口、健康检查间隔与超时时间，改完才好回退。

三、分步操作

第 1 步：先在后端服务器本机复现健康检查

健康检查本质上就是一次 HTTP 或 TCP 探测。先在后端服务器本机用同样的路径访问一次：

curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8080/health
ss -tlnp | grep 8080
systemctl status myapp --no-pager | head -n 20

如果本机访问都不通，问题在服务本身：服务没有启动、监听地址只绑了 127.0.0.1、端口被其他进程占用，或者应用启动失败。先看服务日志，把本机 curl 恢复到期望状态码再往下走。如果是 TCP 健康检查，改用 telnet 或 nc 测试端口是否能建立连接。

第 2 步：核对监听器、后端端口与健康检查配置是否一致

在控制台打开弹性负载均衡 ELB，找到负载均衡器、监听器和后端服务器组，逐项核对：监听器协议与端口、后端服务器组里添加的后端端口、健康检查协议、健康检查端口、检查路径、期望返回码。常见错配有三种：服务监听 8080，后端端口却填了 80；健康检查路径填了根路径 /，应用根路径却返回 302 或 404；期望返回 200，应用实际返回 301。

发现错配就按服务真实情况改配置，改完保存，等一个完整的健康检查周期再看状态，不要连续改多个地方，否则不知道是哪一处修好的。

第 3 步：从同 VPC 的另一台机器模拟 ELB 探测

本机通不代表网络侧通。从同一 VPC 的另一台 ECS 发起同样的请求，模拟 ELB 的探测：

curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" http://192.168.1.10:8080/health

把上面地址里的内网 IP 和端口换成自己的后端服务器内网 IP 与后端端口。如果本机通、同 VPC 不通，问题在网络层，继续第 4 步；如果同 VPC 也通，但控制台仍显示不健康，回到第 2 步核对检查路径与期望状态码，或者看第 5 步的检查参数。

第 4 步：检查后端安全组与实例内防火墙

后端 ECS 的安全组要放行健康检查的探测来源和业务端口。只放行了自己的办公 IP、没有放行 ELB 健康检查的探测来源，是最常见的拦截点。先在控制台核对后端 ECS 绑定的安全组入方向规则，再看实例内的 firewalld 或 iptables 有没有再拦一层：

sudo firewall-cmd --list-all
sudo iptables -L -n | grep 8080

改完安全组后不要立刻下结论，等健康检查连续几次成功再判定。改安全组时只放行必要的端口和来源网段，改完顺手记下改了哪条规则，方便后续审计。

第 5 步：看健康检查参数与服务启动时间

健康检查间隔、超时时间、健康阈值和不健康阈值决定了判定的快慢。服务启动慢、首次检查在应用还没有就绪时就开始，连续失败会直接判不健康。做法是：确认应用完全启动、接口能稳定返回后再把服务器加入后端组；间隔与超时按业务实际情况放宽一点，例如接口本身需要两三秒才能返回，就不要把超时设得太短。改完参数后观察至少两个检查周期，状态稳定变健康才算通过。

四、验证方法

1. 控制台后端服务器状态由“不健康”变为“健康”，且连续两个检查周期保持不变。
2. 在后端本机和同 VPC 机器上 curl 健康检查地址都返回期望状态码，耗时稳定，没有偶发超时。
3. 通过 ELB 的地址访问业务，请求能落到后端服务器，应用日志里出现对应的访问记录。
4. 停掉一台后端服务做对照：健康检查应先变不健康、流量不再分发，恢复服务后重新变健康，流量恢复。

五、常见坑

1. 健康检查路径返回 302 或 401 就以为服务坏了：先看期望状态码和路径是不是应用真实的健康检查接口，必要时单独做一个只返回 200 的 /health 接口。
2. 只放行了客户端 IP，没放行 ELB 探测来源：业务能直接访问后端，不代表健康检查能进来，这是两条不同的访问路径。
3. 服务只监听了 127.0.0.1：本机 curl 能通，网络侧永远不通，改成监听 0.0.0.0 或内网地址。
4. 服务刚启动就加入后端组：应用还没就绪，检查连续失败，先等启动完成再加入。
5. 改了后端端口却没改健康检查端口：两个端口要一起核对，特别是有多个监听器共用一个后端组的时候。
6. 把健康检查当成业务监控：它只判断后端能不能接流量，接口慢、业务报错但仍返回 200 时，它发现不了，要另外做业务监控和告警。

六、小结清单

• 先本机 curl 加 ss 复现探测，再到同 VPC 机器上模拟 ELB 探测。
• 核对监听器端口、后端端口、健康检查协议、路径与期望状态码是否一致。
• 核对后端安全组与实例内防火墙，放行探测来源与业务端口。
• 核对检查间隔、超时与阈值，服务启动完成后再加入后端组。
• 验证标准是控制台状态变健康并保持两个周期，ELB 地址能正常访问业务。