本文揭示alb出现“奇数次请求502、偶数次请求200”现象的根本原因——通常是目标组中存在一个不可用的ec2实例，而alb采用轮询策略导致请求交替打到健康与不健康节点。
本文揭示alb出现“奇数次请求502、偶数次请求200”现象的根本原因——通常是目标组中存在一个不可用的ec2实例，而alb采用轮询策略导致请求交替打到健康与不健康节点。
这种“一失败一成功”的规律性502错误，几乎可以断定是目标组（Target Group）中存在部分不健康实例，而非应用层配置（如Spring Boot的keep-alive参数）或SSL/TLS握手问题。AWS Application Load Balancer默认使用轮询（Round Robin）算法分发请求；当目标组包含2个EC2实例，而其中1个实际未就绪（例如：服务未启动、端口未监听、健康检查失败但未被及时剔除），请求就会交替命中健康节点（返回200）和异常节点（返回502 Bad Gateway）。
✅ 快速验证步骤
首先绕过ALB，直接测试每个EC2实例的后端服务可用性：
# 替换为你的EC2私有IP和端口（如8080） curl -v https://<ec2-private-ip>:8080/actuator/health # 或若仅HTTP（无SSL终止在EC2）： curl -v http://<ec2-private-ip>:8080/actuator/health</ec2-private-ip></ec2-private-ip>
⚠️ 注意：确保安全组（Security Group）允许你测试源IP访问该端口（临时开放或使用同一VPC内跳板机测试）。
- 若某台实例返回
Connection refused、超时或非200响应（如404/500），说明该节点未正确运行Spring Boot服务； - 若返回
{"status":"UP"}，则服务正常；否则需检查：- Spring Boot是否真正启动（
sudo systemctl status myapp或ps aux | grep java）； - 应用是否绑定到
0.0.0.0:8080（而非127.0.0.1:8080）； - EC2实例的防火墙（如
ufw）是否拦截了入站流量。
- Spring Boot是否真正启动（
? 检查ALB健康检查配置（关键！）
登录AWS控制台 → EC2 → Target Groups → 选择对应目标组 → 查看 Health checks 标签页：
| 配置项 | 推荐值 | 说明 |
|---|---|---|
| Protocol | HTTP（非HTTPS） | ALB健康检查通常走HTTP，避免证书/SSL复杂性；除非EC2上明确配置了HTTPS健康端点 |
| Port |
traffic-port 或指定端口（如8080） |
确保与Spring Boot实际监听端口一致 |
| Path |
/actuator/health（需Spring Boot Actuator启用） |
返回JSON且状态码为200才判定健康 |
| Success codes | 200 |
严格校验，避免返回3xx/4xx被误判 |
| Healthy threshold / Unhealthy threshold |
3 / 3（默认） |
避免因短暂抖动误判，但需确保检查间隔合理（如30秒） |
? 提示：若未启用Actuator，可临时添加一个轻量健康端点（如
@GetMapping("/health") public Map），并确保health() { return Map.of("status", "UP"); } server.port=8080且server.address=0.0.0.0。
?️ 常见修复措施
-
立即移除不健康实例：在Target Group中将异常EC2状态设为
draining或直接注销，观察502是否消失； - 自动化恢复：配合Auto Scaling Group + 用户数据脚本，确保实例启动时自动拉起Spring Boot服务；
-
日志定位：检查ALB访问日志（需启用）及EC2系统日志（
/var/log/cloud-init-output.log,journalctl -u myapp）； -
避免“伪健康”：切勿将健康检查路径设为
/（可能返回200 HTML但业务未就绪），优先使用/actuator/health。
✅ 总结
该问题本质是基础设施层面的实例可用性问题，而非前端HTTPS配置或Spring Boot连接超时参数所致。优化server.tomcat.keep-alive-timeout无法解决根本原因——因为502由ALB在建立到后端连接失败时直接返回，甚至未到达Spring Boot容器。务必遵循“先隔离、再验证、后修复”原则：跳过ALB直连各节点 → 定位故障实例 → 校准健康检查 → 清理或修复目标组成员。稳定的目标组是ALB零中断转发的前提。
