AWS部署应用遇10分钟Nginx 499超时，求排查方向

HTTP 499是Nginx特有的状态码，代表客户端主动关闭了连接，结合你描述的10分钟准时触发的现象，以下是几个核心排查方向：

Nginx未配置的关键超时参数 #

你仅设置了proxy_read_timeout 20m，但还有几个默认值为10分钟（600秒）的参数可能触发问题：

• proxy_send_timeout：默认600秒，控制Nginx向后端服务发送请求数据的超时时间。如果后端服务长时间未接收完请求内容，Nginx会主动断开连接，间接导致客户端触发499。
• client_body_timeout：默认600秒，客户端上传请求体的超时时间，若你的POST请求体较大或传输缓慢，可能触发此超时。
• client_header_timeout：默认600秒，接收客户端请求头的超时时间，虽概率较低，但建议统一调整为与其他超时一致的时长。

建议在Nginx配置中补充这些参数，例如：

proxy_read_timeout          20m;
proxy_send_timeout          20m;
client_body_timeout         20m;
client_header_timeout       20m;

Kubernetes Pod探针配置 #

你的Nginx和后端服务都运行在K8s Pod中，Pod的**存活探针（livenessProbe）或就绪探针（readinessProbe）**可能因配置不当导致10分钟后重启Pod：

• 如果探针的periodSeconds（检测周期）设为60秒，failureThreshold（失败阈值）设为10次，刚好会在10分钟后判定Pod不健康并重启，直接切断正在处理的长请求，引发499错误。
• 检查探针配置是否允许服务在长进程期间无法响应探针，可调整timeoutSeconds、failureThreshold，或改用更适合长任务的探针方式（如文件探针）。

EC2实例TCP层超时 #

AWS EC2底层网络或实例本身的TCP配置可能导致连接断开：

• 检查EC2实例的TCP keepalive参数，通过sysctl net.ipv4.tcp_keepalive_time查看，若该值被改为600秒（10分钟），会导致空闲连接被主动回收。
• 另外，若使用了NAT网关，其默认空闲超时为350秒，但如果是自定义配置的话也可能设为600秒，需确认。

应用服务器自身超时 #

后端服务的应用服务器可能存在默认10分钟的请求处理超时：

• 比如Gunicorn的timeout参数、uWSGI的harakiri参数、Tomcat的connectionTimeout参数等，若这些参数被设为600秒，会主动终止长请求，导致连接断开。
• 即使SQL Alchemy超时已调整，应用服务器的全局请求超时仍可能限制整个请求的时长。

再次确认ALB的Idle Timeout #

尽管你提到已调整ALB超时，但仍需再次核对：AWS ALB默认Idle Timeout为60秒，可调整至最长4000秒（约66分钟）。若ALB的Idle Timeout被误设为600秒，当长进程10分钟内无数据返回时，ALB会主动断开连接，客户端收到断开信号后关闭连接，最终在Nginx日志中呈现499。

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