我在应用程序负载平衡器的日志中看到了大量460状态代码。 这些代码在时间，服务器或请求URL方面没有出现任何模式。 根据这个论坛post ，460意味着：
在前端或后端连接join空闲超时之前，客户端已closures与ALB的连接。
我可以看到将请求发送到后端服务器，后端处理请求没有问题，并且很快。 为什么这些错误发生？ 这个ALB用6-8个后台服务器进行大量的stream量。
示例ALB日志：
https 2017-01-30T22:46:27.451363Z app/LOAD-BALANCER/bbab458ad0b80d XXXX:55999 10.5.XX: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日志：
XXXX 1485807955.048 www.website.com /app/page - GET 200 - 0.056 24 text/html; charset=UTF-8 -
应用程序负载平衡器更新状态代码460的文档。
当负载均衡器收到来自客户端的请求时，会发生此错误，但客户端在空闲超时期限过去之前关闭了与负载平衡器的连接。
检查客户端超时时间是否大于负载均衡器的空闲超时时间。 确保您的目标在客户端超时期限结束之前向客户端提供响应，或者如果客户端支持，则增加客户端超时期限以匹配负载均衡器空闲超时。
您可以在这里阅读完整的文档： http : //docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html#http-460-issues
这个序列中可能有一个线索：
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在将请求发送到目标时将一个跟踪标头X-Amzn-Trace-Id插入到请求中，或许将这些标记记录到NGINX后端，看看是否得到了特定的失败请求。
我一直在处理类似的问题，这似乎与我们的主机丢弃由于我们的Windows主机的TCP卸载TCP数据包。