AWS EKS集群API超60秒返回499错误的解决方法问询

我在运行带有LoadBalancer和Ingress Controller的AWS EKS集群，调用集群内NodeJs服务Pod的API时，耗时低于60秒能正常返回数据，超过60秒就返回499错误。我已经将Service、Ingress的keepalive-timeout及LoadBalancer超时设置为600秒，相关配置如下：

LoadBalancer 配置 #

{
    "LoadBalancerAttributes": {
        "CrossZoneLoadBalancing": {
            "Enabled": false
        },
        "AccessLog": {
            "Enabled": false
        },
        "ConnectionDraining": {
            "Enabled": true,
            "Timeout": 600
        },
        "ConnectionSettings": {
            "IdleTimeout": 600
        },
        "AdditionalAttributes": [
            {
                "Key": "elb.http.desyncmitigationmode",
                "Value": "defensive"
            }
        ]
    }
}

Ingress Controller 配置 #

worker_shutdown_timeout 240s ;
        keepalive_timeout  75s;
        client_header_timeout           600s;
        client_body_timeout             600s;
        ssl_session_timeout 10m;
                keepalive_timeout  60s;
                        proxy_connect_timeout                   600s;
                        proxy_send_timeout                      600s;
                        proxy_read_timeout                      600s;
                        proxy_next_upstream                     error timeout;
                        proxy_next_upstream_timeout             0;
                        proxy_connect_timeout                   600s;
                        proxy_send_timeout                      600s;
                        proxy_read_timeout                      600s;
                        proxy_next_upstream                     error timeout;
                        proxy_next_upstream_timeout             0;
                        proxy_connect_timeout                   600s;
                        proxy_send_timeout                      600s;
                        proxy_read_timeout                      600s;
                        proxy_next_upstream                     error timeout;
                        proxy_next_upstream_timeout             600;
                        proxy_connect_timeout                   600s;
                        proxy_send_timeout                      600s;
                        proxy_read_timeout                      600s;
                        proxy_next_upstream                     error timeout;
                        proxy_next_upstream_timeout             0;
                        proxy_connect_timeout                   600s;
                        proxy_send_timeout                      600s;
                        proxy_read_timeout                      600s;
                        proxy_next_upstream                     error timeout;
                        proxy_next_upstream_timeout             0;
                        proxy_connect_timeout                   600s;
                        proxy_send_timeout                      600s;
                        proxy_read_timeout                      600s;
                        proxy_next_upstream                     error timeout;
                        proxy_next_upstream_timeout             0;
                        proxy_connect_timeout                   600s;
                        proxy_send_timeout                      600s;
                        proxy_read_timeout                      600s;
                        proxy_next_upstream                     error timeout;
                        proxy_next_upstream_timeout             0;
                        proxy_connect_timeout                   600s;
                        proxy_send_timeout                      600s;
                        proxy_read_timeout                      600s;
                        proxy_next_upstream                     error timeout;
                        proxy_next_upstream_timeout             600;
                        proxy_connect_timeout                   600s;
                        proxy_send_timeout                      600s;
                        proxy_read_timeout                      600s;
                        proxy_next_upstream                     error timeout;
                        proxy_next_upstream_timeout             0;
                        proxy_connect_timeout                   600s;
                        proxy_send_timeout                      600s;
                        proxy_read_timeout                      600s;
                        proxy_next_upstream                     error timeout;
                        proxy_next_upstream_timeout             0;
                        proxy_connect_timeout                   600s;
                        proxy_send_timeout                      600s;
                        proxy_read_timeout                      600s;
                        proxy_next_upstream                     error timeout;
                        proxy_next_upstream_timeout             0;
                        proxy_connect_timeout                   600s;
                        proxy_send_timeout                      600s;
                        proxy_read_timeout                      600s;
                        proxy_next_upstream                     error timeout;
                        proxy_next_upstream_timeout             0;
                keepalive_timeout 0;

我注意到Ingress中有3个keepalive_timeout，但仅能修改顶部的配置。请问如何让API调用支持超过1分钟的等待时长？

1. 调整Ingress Controller顶部的keepalive_timeout #

将顶部的keepalive_timeout 75s;修改为keepalive_timeout 600s;。这个参数控制客户端与Ingress Controller之间的连接空闲超时，当前75s的设置会提前断开超过1分钟的连接，直接触发499错误，必须和LoadBalancer的IdleTimeout保持一致。

2. 检查Node.js服务端超时配置 #

确保Node.js服务本身没有设置短于600s的响应限制：

• 若使用Express框架，设置server.timeout = 600000;（600秒）
• 确认业务逻辑不会在处理过程中主动断开连接

3. 确认Ingress配置优先级 #

虽然你无法修改下方嵌套块的keepalive_timeout，但全局层级的配置会作为默认值生效，只要嵌套块没有强制覆盖（从当前配置看，下方的60s和0属于局部配置，但如果是针对特定location的，需要确保你的API路由对应的location没有继承这些短超时）。

4. 检查客户端超时设置 #

调用API的客户端（浏览器、HTTP客户端库等）可能自带超时限制，需要将这些值也调整为600s以上，避免客户端主动断开连接导致499错误。

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