12

我在我的应用程序负载均衡器的日志中看到大量的460状态代码。我在这些代码上看不到任何关于时间、服务器或请求 URL 的模式。根据this forum post，460意味着：

在前端或后端连接上的空闲超时开始之前，客户端已关闭与 ALB 的连接。

我可以看到请求发送到后端服务器，后端处理请求没有问题，而且速度非常快。为什么会发生这些错误？此 ALB 使用 6-8 台后端服务器处理大量流量。

示例 ALB 日志：

https 2017-01-30T22:46:27.451363Z app/LOAD-BALANCER/bbab458ad0b80d X.X.X.X:55999 10.5.X.X:80 0.000 -1 -1 460 - 132 0 "GET https://www.website.com:443/app/page HTTP/1.1" "-" ECDHE-RSA-AES128-SHA TLSv1 arn:aws:elasticloadbalancing:us-west-2:743462462234:targetgroup/TARGET-GROUP/e6120e5adr245b79107e "Root=1-588fc23e-77aea5adf4534af3de09659d13a08"

来自后端的 NGINX 日志示例：

X.X.X.X 1485807955.048 www.website.com /app/page - GET 200 - 0.056 24 text/html; charset=UTF-8 -

4

2 回答 2

23

状态代码 460 的文档已针对 Application Load Balancer 进行了更新。

当负载均衡器收到来自客户端的请求，但客户端在空闲超时时间过去之前关闭了与负载均衡器的连接时，会发生此错误。

检查客户端超时时间是否大于负载均衡器的空闲超时时间。确保您的目标在客户端超时期限过去之前向客户端提供响应，或者增加客户端超时期限以匹配负载均衡器空闲超时（如果客户端支持）。

您可以在此处阅读完整文档：http: //docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html#http-460-issues

于 2017-05-02T11:24:53.997 回答
8

在这个序列中可能有一个线索：

0.000 -1 -1 460 -

字段为 request_processing_time、target_processing_time、response_processing_time、elb_status_code、target_status_code

根据 http://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs，target_processing_time 和 response_processing_time 字段为 -1 表明将请求分派到目标主机时出现问题。 html

检查您的目标是否收到请求，ALB 和目标之间可能存在一些配置或网络问题。ALB 在将请求发送到目标时将跟踪标头 X-Amzn-Trace-Id 插入到请求中，也许将它们记录在 NGINX 后端并查看您是否收到失败的特定请求。

我一直在处理类似的问题，它似乎与我们的主机由于我们的 Windows 主机上的 TCP 卸载而丢弃 TCP 数据包有关。

于 2017-03-29T08:47:00.693 回答