Kubernetes环境下Node.js长HTTP GET连接异常断开问题排查

这绝对是Kubernetes集群（或云厂商配套的网络组件）的空闲连接超时机制在搞鬼！我之前在GKE和EKS上都碰到过几乎一模一样的场景，给你拆解清楚原因、curl能正常工作的秘密，还有可行的解决办法：

一、为什么Kubernetes会断开你的连接？ #

不管是GCP GKE还是AWS EKS，它们的核心网络组件（kube-proxy、云厂商提供的负载均衡器）都默认带有空闲连接超时设置：

• GCP的负载均衡器默认超时是30分钟，AWS NLB默认35分钟、ALB默认60秒（没错，ALB更短）。
• 当你的请求长时间没有数据交互（外部服务处理30分钟才返回，期间完全没有字节传输），这些中间层会判定连接已“空闲”，主动发送TCP RST包断开连接。
• 你的Node.js应用因为没配置TCP层面的心跳探测，无法感知连接已失效：没设timeout就会无限等待，设了timeout则会触发ESOCKETTIMEDOUT（本质是连接已经断了，应用还在等数据）。

而本地机器、NAT后的Linux虚拟机能正常运行，是因为它们直接和外部服务建立连接，绕过了K8s的Service/Ingress转发层，自然不会触发这些超时限制。

二、为什么curl在Kubernetes上能正常工作？ #

curl和Node.js的HTTP库在TCP keepalive行为上有本质区别：

• curl默认会自动发送TCP keepalive探测包，默认间隔大概60秒（不同系统可能略有差异）。这些探测包会让中间的网络层认为连接一直处于活跃状态，不会触发空闲超时。
• 你在Node.js里设置的keepAlive: true和forever: true，只是启用了连接复用（即同一连接可以发起多个请求），但并没有配置TCP层面的心跳探测——Node.js的http.Agent默认不会主动发送keepalive包，需要显式配置参数。

三、解决办法 #

1. 给Node.js配置TCP keepalive心跳 #

这是最直接且不需要修改K8s集群配置的方案，不管用request、axios还是node-fetch，都要显式开启TCP keepalive并设置小于云厂商超时的探测间隔（比如25分钟，或者更保守的30秒）。

以你的request代码为例，修改Agent配置：

var http = require("http");
var request = require('request');

// 配置带TCP keepalive的Agent
var agent = new http.Agent({
  keepAlive: true,
  keepAliveMsecs: 30000, // 每30秒发送一次keepalive探测包
  maxSockets: 1 // 单连接即可，避免多连接干扰
});

var options = {
 url: "my-external-service",
 gzip: true,
 forever: true,
 agent: agent
};

request.get(options, (error, response, body) => {
 console.log('error:', error);
 console.log('statusCode:', response && response.statusCode);
 console.log('body:', body);
});

如果用axios，配置方式类似：

const axios = require('axios');
const http = require('http');
const https = require('https');

const httpAgent = new http.Agent({
  keepAlive: true,
  keepAliveMsecs: 30000,
});
const httpsAgent = new https.Agent({
  keepAlive: true,
  keepAliveMsecs: 30000,
});

axios.get('my-external-service', {
  httpAgent,
  httpsAgent,
  timeout: 2400000 // 设置比外部服务处理时间更长的超时，比如40分钟
})
.then(res => {
  console.log('statusCode:', res.status);
  console.log('body:', res.data);
})
.catch(err => console.error('error:', err));

2. 调整Kubernetes/云厂商LB的超时设置 #

如果有权限修改集群配置，可以直接延长空闲超时时间：

• GCP GKE：通过BackendConfig配置Ingress后端超时（最大支持24小时）：

  apiVersion: cloud.google.com/v1
  kind: BackendConfig
  metadata:
    name: long-request-timeout
  spec:
    timeoutSec: 21600 # 6小时，按需调整
  ---
  # 在你的Service中关联这个BackendConfig
  apiVersion: v1
  kind: Service
  metadata:
    name: your-nodejs-service
    annotations:
      cloud.google.com/backend-config: '{"default": "long-request-timeout"}'
  spec:
    # 你的Service原有配置（端口、选择器等）
  

• AWS EKS：修改ALB/NLB的空闲超时（ALB最大4000秒，NLB最大3600秒），通过Ingress annotation配置：

  apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    name: your-ingress
    annotations:
      alb.ingress.kubernetes.io/connection-idle-timeout: '3600' # 1小时，ALB最大4000秒
  spec:
    # 你的Ingress原有配置
  

3. 让外部服务定期发送心跳（可选） #

如果能修改外部服务的代码，让它在处理请求的过程中定期发送一些占位字节（比如空格、换行符），可以让连接保持活跃，避免中间层判定为空闲。不过这个方案需要外部服务配合，适用性有限。

四、验证方法 #

你可以在Kubernetes Pod里用tcpdump抓包，确认连接是否被中间层断开：

# 在Pod内执行，抓取和外部服务的通信包
tcpdump -i any host my-external-service -w long-request-capture.pcap

之后把抓包文件导出到本地，用Wireshark分析，如果看到来自K8s节点或云LB的TCP RST包，就能坐实是空闲超时导致的断开。

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