nodeport本身支持tcp长连接且无需额外配置，但生产中易因中间链路空闲超时（如conntrack、ipvs、云slb或防火墙）导致失败；需两端协同调keepalive间隔小于最小超时阈值，并抓包定位主动断连方。
NodePort 本身不区分 HTTP、gRPC 或自定义 TCP 长连接，只要底层 kube-proxy（iptables 或 IPVS 模式）能正常转发 TCP 流量，Go 的长连接就能走通。但生产中暴露 Go 长连接服务（如 gRPC、WebSocket、自定义 TCP 协议）时，默认配置下极易因连接空闲超时或连接复用中断而失败，这不是 NodePort 本身的问题，而是网络链路中多个组件对“长连接”的容忍度不一致导致的。
NodePort 转发是否支持 TCP 长连接
支持，且无需额外配置。kube-proxy 的 iptables/IPVS 规则对所有 TCP 连接一视同仁，只要目标 Pod 的 targetPort 正常监听、Service 的 selector 匹配成功、Endpoints 有值，连接就能建立并维持——前提是中间链路不主动断开。
常见误区是认为 NodePort “只适合 HTTP”，其实它只是开放节点端口 + 做 DNAT，和协议无关。你可以用 telnet <node-ip><nodeport></nodeport></node-ip> 或 nc -v <node-ip><nodeport></nodeport></node-ip> 直接测试 TCP 连通性，绕过应用层验证底层链路是否通畅。
kube-proxy 默认模式下长连接保活失效的原因
问题通常出在 kube-proxy 的连接跟踪（conntrack）行为上，尤其在高并发或连接长时间空闲时：
- iptables 模式依赖内核 conntrack 表，默认
net.netfilter.nf_conntrack_tcp_timeout_established值为 432000 秒（5 天），看似足够，但某些发行版或云厂商内核会调低该值（如 CentOS 7 默认仅 5 分钟）； - IPVS 模式虽更高效，但若未启用
--ipvs-scheduler=rr或未配置sysctl -w net.ipv4.vs.conn_reuse_mode=1，也可能在连接复用时误判为 stale connection； - 集群节点若启用了 firewalld 或 ufw，其默认规则可能对无数据流动的连接执行 early drop。
验证方式：在节点上运行 conntrack -L | grep <nodeport></nodeport>，观察 ESTABLISHED 状态连接是否存在、超时时间是否异常短。
ZenHeart zenlink 与 zenlink-mcp 为 OpenClaw，涵盖安装、MCP 注册、钩子接线、入站轮询及升级维护。
Go 客户端与服务端需协同调整的参数
仅调服务端或仅调客户端都不够，必须两端配合。关键点不是“加 KeepAlive”，而是让 KeepAlive 间隔 小于所有中间环节的空闲超时阈值（通常取最小值的 1/3）：
- Go 服务端（
net/http.Server或grpc.Server）：设置KeepAlive: 30 * time.Second，ReadTimeout/WriteTimeout设为 0 或远大于业务预期； - Go 客户端（
http.Client或grpc.Dial）：启用KeepAlive并设为 20s，同时配置MaxIdleConnsPerHost: 1000和IdleConnTimeout: 90 * time.Second； - 若用自定义 TCP listener，务必在
Accept()后对每个conn显式调用SetKeepAlive(true)和SetKeepAlivePeriod(20 * time.Second)。
注意：net.Dialer.KeepAlive 控制的是连接池中空闲连接的探测，而 conn.SetKeepAlivePeriod 控制的是已建立连接的保活包发送频率，两者作用层级不同，不能互相替代。
云环境或防火墙设备带来的隐性截断
即使集群内部一切正常，外部访问仍可能失败——因为云厂商 SLB、NAT 网关、企业防火墙普遍默认 5–15 分钟空闲连接自动回收：
- AWS EC2 安全组本身不限制连接时长，但若前端挂了 ALB/NLB，NLB 的空闲超时默认 3500 秒（约 58 分钟），ALB 则是 60 秒（HTTP）或 4000 秒（TCP）；
- 阿里云 SLB 的 TCP 监听默认空闲超时为 900 秒（15 分钟），必须手动调大；
- 本地办公网出口防火墙常设 300 秒超时，此时无论服务端怎么调 KeepAlive，客户端只要 5 分钟没发数据，连接就被干掉。
这类问题无法通过 kubectl 或节点日志发现，唯一可靠办法是：在客户端抓包（tcpdump -i any port <nodeport></nodeport>），看 FIN/RST 是否由远端（非你的节点）发出。如果是，就说明是中间设备强制断连，只能协调网络侧调整策略。
真正卡住人的地方往往不在 Kubernetes 配置里，而在你没权限改、甚至不知道它存在的那层 NAT 或防火墙。调试长连接，先确认“谁在主动断开”，再决定调哪边。
