AWS EKS环境下NGINX Ingress结合JETTY 9.4的3GB大文件下载异常问题

结合你已经验证过的现象（kubectl port-forward直连后端正常、小文件下载无异常、nginx侧无明显error日志、后端Jetty报对端连接重置），以下是跳过已覆盖配置环节的落地排查点：

核心现象对齐 #

• 已排除Jetty服务本身的逻辑问题：直连后端的链路完全正常，说明文件输出的代码逻辑无异常
• 已排除应用层报文大小限制：你已经将客户端请求体、代理请求体、临时文件大小限制全部设为0，且小文件传输完全正常
• 初步定位中断路径：后端收到的连接重置，是nginx侧或EKS底层网络设备主动发起的静默断开，这类断开大多不会在nginx的error日志中留下明确记录

具体排查方向 #

1. 核对Ingress到后端的代理超时配置 #

很多场景下容易只配置客户端到Ingress的超时，忽略Ingress到上游Jetty的链路超时：

• 重点检查两个注解的实际生效值（避免被Ingress全局配置覆盖）：
  • nginx.ingress.kubernetes.io/proxy-read-timeout：默认值60s，指nginx等待后端返回数据的最长间隔，如果长传输过程中两次数据块返回的间隔超过这个值，nginx会主动断开和后端的连接
  • nginx.ingress.kubernetes.io/proxy-send-timeout：默认值60s，指nginx向后端发送请求的最长间隔，大文件流传输过程中如果发包间隔超时，同样会触发主动断连
• 验证方案：临时将这两个参数调整为1800s（覆盖3GB文件在常规公网带宽下的最长传输时长），排除超时触发的断连

2. 排查EKS侧负载均衡的空闲超时规则 #

这是绝大多数长连接大文件传输中断的核心诱因：

• 官方Helm部署的Ingress默认关联AWS网络负载均衡（NLB），NLB本身有默认的TCP空闲连接超时为350s，这个规则只统计两个TCP报文之间的发送间隔，不跟踪整个连接的总存活时长
• 匹配你的故障现象：如果大文件下载过程中出现短暂网络抖动、Jetty输出文件块的间隔超过350s，NLB会直接静默回收TCP连接。此时nginx侧因为没有收到明确的连接断开报文，不会输出error级别的异常日志，而后端Jetty在持续往这个连接里写数据时，就会触发“连接被对端重置”的报错
• 验证方案：在AWS控制台找到Ingress对应的NLB实例，将空闲连接超时调整为1800s，和nginx的代理超时配置对齐后重新测试

3. 排查节点侧连接追踪表溢出问题 #

EKS默认的节点内核参数可能存在连接追踪表容量不足的问题：

• 当长连接大流量传输时，如果net.netfilter.nf_conntrack_max参数值过小，连接追踪表溢出时，内核会静默丢弃现有连接、触发TCP重置，整个过程不会在应用层日志中留下明确错误
• 排查动作：
  • 查看Ingress节点和Jetty节点的系统日志（dmesg），确认是否存在nf_conntrack: table full, dropping packet的告警
  • 核对集群网络策略配置，确认是否存在针对长连接的主动回收规则

4. 核对TLS层的会话超时配置 #

由于你的Ingress配置了TLS终结，容易忽略TLS会话的超时规则：

• nginx.ingress.kubernetes.io/ssl-session-timeout默认值为5分钟，超时后nginx会主动断开TLS连接，这个过程默认只会输出info级别日志，不会触发error告警
• 验证方案：临时将该参数调整为1800s，交叉排除TLS层的主动断连

快速复现定位技巧 #

用限速命令故意拉长传输时长，覆盖所有默认超时阈值，快速复现问题：

执行curl -o test-3g.bin https://my.website.com/test-3g-file --limit-rate 1M，将下载速度限制在1MB/s，此时3GB文件需要约50分钟才能传输完成，远超过所有组件的默认超时阈值。一旦出现中断，立刻在Ingress节点上抓取和后端Jetty Pod之间的TCP流量包，确认RST重置包是由哪一端、哪一层网络设备发出，即可100%锁定问题节点

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