企业官网建设流程全解析

摘要：给一个 Java 单体 + ALB（应用型负载均衡）+ 双 ECS 的架构做运维这两年，ALB 相关的深夜故障一共处理了 5 次，每次的坑都藏在控制台里最不起眼的配置项里。这篇把这 5 个坑完整拆解：健康检查把应用打成 CPU 风暴、会话保持配了却"时灵时不灵"、WebSocket 连接 60 秒必断、转发规则优先级引发的 404 迷案、以及监听器超时导致的"大文件上传永远失败"。每个坑都给出：故障现象、排查过程、控制台里的正确配置。
关键词：ALB、负载均衡、阿里云、健康检查、WebSocket、故障排查

适合人群：把服务挂在 ALB 后面的运维/后端工程师

坑一：健康检查的"误杀"与"漏杀"

现象：发布后偶发整站 502，但后端 ECS 上应用进程活得好好的；另一个极端是应用已经半死（DB 连接池耗尽），ALB 却继续把流量打进来。

排查：502 那次是发布窗口——新包还没启动完成，旧进程已 kill，健康检查失败，ALB 把节点摘除。问题是健康检查间隔 10 秒 + 失败 3 次才摘除，摘除是动态的，但"新应用 30 秒才起来"的窗口里，健康检查探测到的是连接拒绝，节点反复进出后端池，502 是这 30 秒里正常用户的体验。

更隐蔽的是"漏杀"：默认健康检查用 TCP 探测（或对/的 HTTP 探测），应用进程活着但内部已不可用时（DB 连不上、线程池满），TCP 照样通——ALB 认为节点健康，流量持续进入，所有请求 500。

正确配置：

1. 探测路径用轻量级的专用健康端点（Spring Boot 的/actuator/health</