AWS ALB健康检查返回302失败，HTTPS访问异常求助

我之前也碰到过几乎一模一样的场景，咱们一步步拆解问题根源，逐个解决：

1. 先搞定健康检查302失败的核心问题 #

ALB默认会把302判定为不健康响应，所以实例会被踢出流量池，这也是你无法通过ELB域名访问的直接原因之一。大概率是你的实例7070端口的服务，对ALB的健康检查请求返回了重定向：

• 先登录到实例本地，用curl http://localhost:7070测试默认健康检查路径，看看是不是真的返回302。如果是的话，说明服务本身对根路径有重定向规则（比如强制跳转到HTTPS地址、带www的域名）。
• 解决办法：
  • 最稳妥的方式：在服务里新增一个专门的健康检查端点（比如/health），让它固定返回200状态码，然后把ALB目标组的健康检查路径改成/health。
  • 临时应急：修改ALB健康检查的成功状态码，把302加进去（不过不推荐长期这么做，毕竟302不是标准的健康响应）。
  • 服务端调整：如果能修改服务逻辑，让它对来自ALB的请求（可以通过源IP或专属头部判断）返回200而非重定向。

2. 解决HTTPS访问被跳转到HTTP的问题 #

当你用https://elb-dns-name访问时，ALB会把HTTPS请求转换成HTTP请求转发到实例的7070端口。但你的服务可能配置了「强制HTTPS」的重定向规则——它只看到当前请求是HTTP的，就直接把用户跳转到HTTP版本的ELB域名，这就导致了跳转异常。

核心解决思路是让服务识别原始请求的协议：ALB会在转发请求时自动添加X-Forwarded-Proto: https头部，你需要让服务信任这个头部，并根据它来调整重定向逻辑：

• 举个Nginx的配置例子，你可以把原有强制HTTPS的规则改成：

  if ($http_x_forwarded_proto != 'https') {
      return 301 https://$host$request_uri;
  }
  

  这样服务就会根据ALB传来的真实协议判断，而不是只看本地收到的HTTP请求。
• 如果是其他服务框架（比如Spring Boot、Node.js），也都有对应的配置项来开启对X-Forwarded-Proto头部的支持，本质都是让服务基于原始请求协议做判断。

3. 最后做几个验证检查 #

• 确认ALB监听器：HTTPS（443端口）确实关联到了你的目标组，目标组的协议是HTTP、端口是7070。
• 安全组校验：ALB的安全组允许外部访问443；实例的安全组允许ALB的安全组（或ALB的IP范围）访问7070端口。
• 等健康检查恢复正常后，再测试https://elb-dns-name，应该就不会再跳转到HTTP了。

内容的提问来源于stack exchange，提问作者Ashok Reddy