ALB健康检查正常但业务打不开？从探测请求差异排查
ALB显示健康而业务打不开，先比较健康检查实际探测的请求与用户失败请求是否相同，重点看方法、端口、Host、路径和成功状态码。健康检查只证明所配置探测条件得到预期响应，不能覆盖登录、数据库查询或完整下单过程。
假设场景：一个站点通过ALB提供HTTPS服务，后端同时托管多个站点；用户访问登录页失败，控制台健康状态却正常。以下按证据拆解排查方向，不代表发生过的客户故障，也没有故障恢复耗时或性能测试数据。
先把两种请求放到同一张表
由维护人员记录失败请求的时间、域名、路径、方法和状态码，再查看服务器组实际健康检查设置。不能只看实例首页的一项绿色状态。监听的健康状态还会聚合它关联的服务器组，因此也要定位具体服务器组及后端节点，而不是根据一个总状态猜测所有节点一致。
| 比较项 | 健康检查可能使用 | 业务请求可能使用 | 差异影响 |
|---|---|---|---|
| 方法 | 默认HEAD | GET或POST | 应用未实现同样的路由 |
| 域名 | 默认后端内网IP | 站点域名 | 命中不同虚拟主机 |
| 路径 | 默认根路径 | 登录或接口路径 | 首页正常不代表接口正常 |
| 返回码 | 默认接受2xx和3xx | 需要完整业务响应 | 跳转成功不等于完成登录 |
| 端口 | 后端端口或指定端口 | 监听转发的目标端口 | 可能探测了另一个服务 |
先记录实际配置，再提出原因。假设场景中的Host差异只是待验证线索，不能看到多站点就直接认定它是根因。
场景分支一：探测落到了默认站点
官方说明，HTTP或HTTPS健康检查域名默认使用后端服务器内网IP。如果后端按域名选择虚拟主机，探测可能进入默认站点；它返回正常页面，但用户域名对应的应用可能故障。此时“探测成功”与“业务失败”可以同时发生。
确认方法是比对健康检查日志中的Host、路径与业务日志，并检查实际落到的虚拟主机。维护人员可在隔离环境复现相同请求条件；没有日志证据时，不要同时改多个监听和源站配置。若需要调整探测域名，应与后端服务配置一同核对，并在单个测试服务器组验证。
- 先检查失败是否只发生于某个域名或路径。
- 对照后端访问日志确认请求落点。
- 明确专用探测端点属于哪个应用和端口。
- 调整前记录旧设置，异常时可以回退。
场景分支二：跳转或方法让结果失真
ALB的HTTP及HTTPS健康检查默认使用HEAD，官方要求后端支持该方法，否则可改用GET。某些框架对HEAD与GET的处理不一致，或登录页会统一返回跳转；应检查实际响应，不能把浏览器手工打开首页当作等价验证。
默认健康状态码包含2xx和3xx，因此跳向登录页的响应可能符合健康条件。这里不能进一步推断ALB已经完成跳转后的业务验证。对该假设场景，更合适的做法是建立明确用途的专用探测路径，让它返回预期状态，并确认该状态表达的是进程存活还是应用就绪。
不要为了让状态变绿，把所有4xx、5xx加入健康码。官方提醒这可能妨碍故障节点被及时剔除；优先修复后端响应和探测条件。
静态探测页可以帮助识别Web服务是否响应，但不能单独证明数据库可查询。若团队希望检查关键依赖，应明确就绪语义和依赖故障处理，避免把复杂业务请求直接当作频繁探测接口。
场景分支三：节点状态与流量行为不同步
ALB要求连续成功达到健康阈值后才将节点判为正常，连续失败也需满足不健康阈值。状态变化不是一次响应即生效；探测间隔、超时、阈值和实际网络情况都会影响观察结果。本文不把某个简单乘法当作准确摘除耗时，也不据此承诺业务切换在固定秒数内完成。
还要注意两个边界：官方文档说明，权重为零的后端不参与健康检查；如果同一服务器组只有不健康后端，ALB仍会尝试按调度算法把请求发往这些服务器。因此“全不健康”不能被理解为平台必定停止所有转发，故障期间仍需查看实际访问日志及业务错误。
故障记录卡：时间范围、服务器组、节点与权重、探测协议及方法、Host、路径、端口、成功码、阈值、业务错误、日志证据。按节点形成记录，能避免在共享监听里混淆不同服务。
把恢复验收分成探测与业务两部分
修复后，先确认目标后端在设定条件下连续通过探测，再用测试账号验证此前失败的业务路径。若业务涉及写入，使用受控测试数据并清理，不在生产服务上执行破坏性演练。还应观察其他域名和节点，避免修好一个虚拟主机却影响同机服务。
需要选择产品层次时，可阅读应用与网络负载均衡的协议差异；已经规划多个可用区时，可参考多可用区负载均衡思路，具体探测行为以本次ALB官方说明为准。不要把本文的ALB默认值照搬到其他负载均衡产品。
参考资料（查阅日期：2026年10月15日）：
- 阿里云官方文档：ALB健康检查的方法、域名、路径、默认成功状态码、权重为零与全部不健康时的行为。
常见问题
HTTP健康检查正常是否表示数据库正常？
只有探测端点确实检查了数据库，并且语义设计正确，才可能反映相应依赖状态。仅返回静态页面时，只能证明该探测路径能响应。
出现301或302就一定会被判为健康吗？
要看实际配置的健康状态码。官方默认包含3xx，但用户可调整；应查看当前服务器组设置，而不是仅凭默认值判断。
为什么全部后端不健康仍然有访问日志？
官方说明，当服务器组只含不健康后端时，ALB仍会尝试向它们转发请求。应结合实际业务日志和节点状态排查，不能认为不健康等于绝不转发。
总结
下一步从一个失败请求开始，填写探测与业务请求对照表，定位域名、方法、端口和路径的具体差异。修复后分别验收健康检查与原故障业务路径，并保存观察记录；两项都符合预期，才算本次故障处理完成。