我在应用程序负载均衡器的日志中看到了大量460状态代码。我没有在时间，服务器或请求网址上看到这些代码的任何模式。根据{{3}}，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 -
答案 0 :(得分：8)
为应用程序负载均衡器更新状态代码460的文档。
当负载均衡器收到来自的请求时，会发生此错误 客户端，但客户端关闭了与负载均衡器的连接 在空闲超时时间结束之前。
检查客户端超时时间是否大于空闲时间 负载均衡器的超时时间。确保您的目标提供 在客户端超时期限过去之前对客户端的响应，或 增加客户端超时时间以匹配负载均衡器空闲 超时，如果客户端支持此功能。
您可以在此处阅读完整文档： http://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html#http-460-issues
答案 1 :(得分：4)
这个序列可能有一个线索：
0.000 -1 -1 460 -
字段是request_processing_time，target_processing_time，response_processing_time，elb_status_code，target_status_code
target_processing_time和response_processing_time字段为-1表示根据http://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html
将调度请求发送到目标主机时出现问题检查目标是否收到请求，ALB和目标之间可能存在某些配置或网络问题。 ALB在将请求发送到目标时将AL-Q-Amzn-Trace-Id插入到请求中，可能会在NGINX后端上记录这些，并查看是否收到了失败的特定请求。
我一直在处理类似的问题，它似乎与我们的主机因我们的Windows主机上的TCP卸载而丢弃TCP数据包有关。