Kube-Proxy的IPVS模式不处理TCP Keepalive，仅做四层转发；当Nginx网关、Pod应用与内核层Keepalive超时未对齐，空闲连接被单方关闭，导致“连接重置”或“504 Gateway Timeout”。
这个问题核心在于：Kube-Proxy 的 IPVS 模式本身不处理 TCP Keepalive，它只做四层转发；而上游网关（如 Nginx）和下游 Pod 中的应用服务（如 Spring Boot、PHP-FPM、Node.js）各自维护独立的 TCP 连接生命周期。当三者 Keepalive 超时时间未对齐，空闲连接可能被某一方单方面关闭，导致后续请求复用该连接时出现“连接被对端重置”或“504 Gateway Timeout”——尤其在长连接、低频调用或跨 AZ 场景下高发。
确认是否为 Keepalive 不对齐引发
先验证问题本质，避免误调：
- 在出问题的 Pod 内执行
ss -tni | grep ESTAB，观察连接的retrans、rto和keepalive字段，看是否有大量连接卡在 FIN-WAIT 或 CLOSE-WAIT 状态 - 抓包比对：在 Node 上对 Service ClusterIP（如
10.233.64.1:443）抓包，同时在目标 Pod 内对容器端口（如8080）抓包，检查 FIN/RST 是否由 Nginx 或 Pod 应用主动发出，而非 IPVS - 临时将 kube-proxy 切回 iptables 模式（
kubectl edit cm -n kube-system kube-proxy→ 修改mode: iptables→kubectl rollout restart ds -n kube-system kube-proxy），若 504 显著减少，基本可锁定为 IPVS 下连接管理差异所致
统一各层 Keepalive 时间窗口
关键不是“设大”，而是“错开且覆盖”：让最短的一方晚于最长的一方关闭连接，留出安全缓冲。
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
-
Nginx 网关侧：在 upstream 块中显式配置 keepalive，并匹配后端健康检查间隔
upstream mysvc {<br> server 10.233.64.1:80;<br> keepalive 32;<br>}<br>server {<br> location / {<br> proxy_pass http://mysvc;<br> proxy_http_version 1.1;<br> proxy_set_header Connection '';<br> # 关键：让 Nginx 主动探测连接有效性<br> proxy_socket_keepalive on;<br> # TCP 层 keepalive 参数（Linux 内核级）<br> proxy_set_header X-Real-IP $remote_addr;<br> }<br>} -
Pod 应用侧：以常见运行时为例
• Java（Spring Boot）：在application.yml中设置server.tomcat.connection-timeout=120000，并启用 keepalive：server.tomcat.keep-alive-timeout=180000
• Node.js（Express + http.Server）：server.keepAliveTimeout = 180_000; server.headersTimeout = 240_000;
• Golang HTTP Server：srv := &http.Server{ReadTimeout: 240 * time.Second, WriteTimeout: 240 * time.Second, IdleTimeout: 300 * time.Second} -
Node 内核层（全局兜底）：修改所有 Worker 节点的 sysctl
net.ipv4.tcp_keepalive_time = 600<br>net.ipv4.tcp_keepalive_intvl = 60<br>net.ipv4.tcp_keepalive_probes = 5
即：空闲 10 分钟后开始探测，每 60 秒发一次，连续 5 次无响应才断连 → 总超时约 11 分钟，大于应用层 3–4 分钟设定
规避 IPVS 连接状态盲区
IPVS 不跟踪连接状态，无法感知后端主动断连。需靠外部机制补足：
- 在 Service 上启用
externalTrafficPolicy: Local（仅限 NodePort/LoadBalancer 类型），减少跨节点转发跳数，缩短路径中潜在的连接中断点 - 为关键 Service 配置合理的 readinessProbe，例如：
readinessProbe:<br> httpGet:<br> path: /healthz<br> port: 8080<br> initialDelaySeconds: 10<br> periodSeconds: 5<br> timeoutSeconds: 3<br> failureThreshold: 2
确保连接池中只保留真正可响应的后端实例 - 若使用 Nginx Ingress Controller，升级至 v1.9+，启用
use-forwarded-headers: "true"和proxy-real-ip-cidr，避免因 X-Forwarded-For 导致连接复用异常
补充建议：监控与告警
光调参不够，要可观测：
- 采集指标：
nginx_ingress_controller_requests_total{status=~"504"}、container_network_receive_errors_total、kube_pod_container_status_restarts_total - 日志中增加连接上下文：Nginx 开启
$upstream_connect_time $upstream_header_time $upstream_response_time，对比三者差值突增即为连接复用失败信号 - 对 Service ClusterIP 执行周期性探测：
curl -I http://10.233.64.1/healthz --connect-timeout 5 --max-time 10，失败时触发自动滚动重启对应 Deployment
