如何对 Application Load Balancer HTTP 502 错误进行故障排除？

上次更新日期：2022 年 5 月 17 日

HTTP 502：错误的网关错误有多种可能的原因，可能源于您的目标，也可能源于 Application Load Balancer。您可以使用 Amazon CloudWatch 指标和访问日志来确定错误的来源和成因。

在开始对 Application Load Balancer 中的错误进行故障排除之前，请确保启用访问日志记录。要了解访问日志中每个字段的含义，请参阅访问日志条目。

如果目标是 AWS Lambda 函数，请参阅“解决方法”部分中的当目标是 Lambda 函数时对 HTTP 502 错误进行故障排除。

使用 CloudWatch 指标

如果数据点显示在 HTTPCode_ELB_502_Count 指标下，则您的负载均衡器是 HTTP 502 错误的来源。如果它们出现在 HTTP_Target_5XX_Count 指标下，则您的目标是错误来源。

使用访问日志

如果 elb_status_code 为 “502”，且 target_status_code 为 “-”，则您的负载均衡器是 HTTP 502 错误的来源。如果 elb_status_code 是 “502”，且target_status_code 是 “502”，则您的目标是错误的来源。

注意：依据 elb_status_code = "502" 和 target_status_code 筛选访问日志，以帮助您确定成因。然后，完成特定于您的使用案例的步骤。

尝试建立连接时，负载均衡器收到了来自目标的 TCP RST

在建立连接时接收到来自目标的 TCP RST 意味着负载均衡器不能与目标建立 TCP 三次握手。因此，负载均衡器无法将用户请求转发到目标。

• 检查 TargetConnectionErrorCount 指标是否有数据点。该指标表示负载均衡器和目标之间未成功建立的连接数。
• 检查访问日志中的 request_processing_time、target_processing_time 和 response_processing_time 字段是否均设置为值 -1。此值表示负载均衡器无法将请求分发到目标，因为它需要成功的连接。

以下是访问日志条目的示例：

http 2022-04-15T16:52:50.757968Z app/my-loadbalancer/50dc6c495c0c9188 192.168.131.39:2817 10.0.0.1:80 -1 -1 -1 502 - 86 155 "GET http://example.com:80/ HTTP/1.1" 
"curl/7.51.0" - - arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-targets/73e2d6bc24d8a067" Root=1-58337262-36d228ad5d99923122bbe354"

注意：在前面的访问日志条目中，request_processing_time、target_processing_time 和 response_processing_time 都设置为 -1。

尝试建立连接时，负载均衡器收到了来自目标的意外响应，例如 "ICMP Destination unreachable (Host unreachable)"

• 检查访问日志中的 request_processing_time、target_processing_time 和 response_processing_time 字段是否都设置为值 -1。
• 检查是否允许从负载均衡器子网到目标端口上的目标的流量。

目标关闭连接并显示 TCP RST 或 TCP FIN，而负载均衡器对目标有未完成的请求

负载均衡器接收请求并将其转发到目标。目标接收请求并开始处理请求，但过早关闭与负载均衡器的连接。这种情况通常发生在当目标的保持连接超时的持续时间短于负载均衡器的空闲超时值时。确保保持连接超时的持续时间大于空闲超时值。

检查 request_processing_time、target_processing_time 和 response_processing_time 字段的值。

访问日志条目示例：

http 2022-04-15T16:52:50.757968Z app/my-loadbalancer/50dc6c495c0c9188 192.168.131.39:2817 10.0.0.1:80 0.001 4.205 -1 502 - 94 326 "GET http://example.com:80 HTTP/1.1" "curl/7.51.0" - - arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-targets/73e2d6bc24d8a067 "Root=1-58337262-36d228ad5d99923122bbe354"

注意：在前面的访问日志条目中，request_processing_time 为 0.001，target_processing_time 为 4.205，response_processing_time 为 -1。

目标响应格式错误或包含无效的 HTTP 标头

在问题发生的时间范围内对目标执行数据包捕获，以了解目标响应。

负载均衡器在连接到目标时遇到 SSL 握手错误或 SSL 握手超时（10 秒）

从负载均衡器到目标的 HTTPS 侦听器的 TCP 连接成功，但随后的 SSL 握手超时。因此，负载均衡器无法将请求转发到目标。

检查目标组是否正在使用 HTTPS 协议。如果没有使用，那么 SSL 握手超时不是错误的原因。如果目标组正在使用 HTTPS 协议，请尝试以下操作：

• 检查访问日志中的 request_processing_time、target_processing_time 和 response_processing_time 字段是否都设置为值 -1。
• 检查 TargetTLSNegotiationErrorCount 指标是否有数据点。
• 在问题发生的时间范围内对目标执行数据包捕获，以验证它是否与 SSL 握手有关。如果有关，则完成执行数据包捕获部分中的步骤。
• 检查密码或协议是否不匹配。

由已取消注册的目标处理的请求的取消注册延迟期已过

在您的 CloudTrail 事件中，检查问题发生期间是否有对于 DeregisterTargets 操作的 API 调用。如果在问题发生期间发生了对于 DeregisterTargets 的 API 调用，则错误是由过早取消注册的目标引起的。要解决此问题，请延长取消注册延迟期限，以便长时间的操作可以顺利完成。

注意：对于失败的 Lambda 函数的请求，负载均衡器会将特定于 Lambda 的错误原因代码存储在访问日志的 error_reason 字段中。

目标是 Lambda 函数，响应正文超过 1 MB

• 检查是否有 LambdaUserError 指标的数据点。
• 检查负载均衡器访问日志中的 error_reason 字段是否设置为 LambdaResponseTooLarge。

目标是一个 Lambda 函数，该函数在达到其配置的超时时间之前没有响应

• 检查 Lambda 函数的超时配置。
• 检查是否有 LambdaUserError 指标的数据点。
• 检查负载均衡器访问日志中的 error_reason 字段是否设置为 LambdaUnhandled。

目标是一个返回错误的 Lambda 函数，或者该函数被 Lambda 服务限制

请联系 AWS Support 以获取有关服务限制的指导。

对于 Linux，使用以下命令：

sudo tcpdump -i any -w filename.pcap

对于 Microsoft Windows，请下载并使用 Wireshark 应用程序（从 Wireshark 网站下载）。