AWS ECS关联ALB健康检查正常但其他端点返回503错误问题咨询

安全阿岳

2026-9-2

故障现象

为AWS ECS配置Application Load Balancer后，健康检查端点可正常返回200响应，访问其余任意业务端点时ALB返回如下固定响应：

<html>
<head>
    <title>503 Service Temporarily Unavailable</title>
</head>
<body>
    <center>
        <h1>503 Service Temporarily Unavailable</h1>
    </center>
</body>
</html>

该响应为ALB原生返回的错误页，代表ALB无法将请求转发至可用后端目标，健康检查正常场景下的常见诱因与排查方向如下：

端口/协议映射配置错误
健康检查支持单独配置检查端口、协议、路径，与业务转发的默认配置互不影响。优先核对三项配置一致性：
- ECS任务定义中容器的端口映射，确认业务应用实际监听的端口和映射到主机/ENI的端口一致
- 目标组配置的默认转发端口、转发协议，和容器暴露的业务端口、应用监听协议（HTTP/HTTPS）一致，避免出现健康检查配了HTTP 10000端口（健康检查接口专用）、业务转发误配成HTTP 8080但容器未监听8080的情况
网络访问规则拦截业务流量
安全组、网络ACL规则如果只放通了健康检查端口的访问，未放通业务转发端口的ALB访问权限，就会出现健康检查可达、业务流量被拦截的情况：
- 检查EC2实例/Fargate任务ENI绑定的安全组入站规则，确认ALB关联的安全组被允许访问所有业务转发端口
- 检查ALB、ECS任务所在子网的网络ACL规则，确认对应端口的入站、临时端口段出站规则未被拦截
目标组配置与ECS启动类型不匹配
Fargate启动类型的ECS任务必须关联ip类型的目标组，EC2启动类型如果使用instance类型目标组需要确保实例端口映射正确。如果目标组类型选错，健康检查可能因配置的静态地址临时连通，但业务转发时ALB无法正确路由到目标资源就会返回503。同时检查目标组下所有注册目标的状态，确认没有处于draining、initial状态的目标，避免出现健康检查端口正常、业务端口异常导致部分目标被判定为业务不可用的情况。
监听器转发规则配置错误
检查ALB的监听器规则：如果除了默认转发规则之外，配置了更高优先级的规则匹配所有路径，转发到了没有可用目标的空目标组，就会出现健康检查（走默认规则/专门的健康检查规则）正常，业务请求被高优先级规则转发到异常目标组返回503的情况。
快速定位方法
在ALB同子网的跳板机上直接访问ECS任务的私有IP+业务端口，绕过ALB验证业务端点可用性：
- 直连不通：问题出在容器应用端口监听配置、任务/实例安全组规则
- 直连正常：问题出在ALB目标组配置、监听器转发规则、ALB到目标组的网络策略
  也可以通过响应头判断故障层级：ALB直接返回的503会携带X-Amzn-Trace-Id头，且为固定的默认503页面，说明请求未到达后端；如果返回内容是应用自定义错误页，说明请求已到达后端，故障为应用侧路由、Host校验、鉴权逻辑拦截（多数Web框架默认不对健康检查路径做Host、鉴权校验，其余路径会触发校验逻辑）。

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