Node应用部署至EKS后出现间歇性WebSocket 1006连接错误求助

网络层问题排查 #

• 抓包分析TCP连接状态：在Pod里用tcpdump抓取和提供商WebSocket端点的通信包，看连接断开时是哪一方发了FIN/RST包，有没有丢包情况。对比本地抓包结果，定位网络路径差异。
• 检查中间网络组件超时：如果EKS用了NAT网关，AWS NAT的TCP超时默认是350秒，确认你的Ping间隔是否短于该值，且和提供商的空闲超时设置匹配。另外排查集群是否走了企业代理，代理有没有独立的超时规则。
• 验证安全组/IP白名单：确认EKS集群的出口IP（NAT网关IP或Pod直接出口IP）在提供商的白名单内，同时检查安全组、网络ACL有没有间歇性阻断出站流量的规则。

WebSocket交互机制验证 #

• 确认Ping/Pong实际生效：在代码里添加日志，记录每次Ping发送时间、Pong接收时间，检查是否存在Ping发出后无Pong响应的情况，或者Ping间隔是否严格符合提供商要求（比如对方要求20秒一次，你设成了40秒）。注意部分客户端库的自动Ping需要显式开启，比如ws库的pingInterval参数是否正确配置。
• 询问提供商限制：向对方确认是否对单IP的并发连接数、连接时长有阈值，EKS集群多个Pod共享出口IP，可能触发限流。如果提供商能提供日志，查看是否有针对你集群IP的断开记录。

EKS集群与Pod配置检查 #

• 排查Pod资源问题：通过kubectl top pod查看Pod的CPU/内存使用情况，有没有OOMKill或资源不足导致进程卡顿的情况，kubectl describe pod里的事件能帮你确认这类问题。
• 检查网络策略：确认有没有集群网络策略限制了Pod到外部WebSocket端点的流量，或者策略规则存在间歇性生效的问题。
• 查看集群网络组件状态：检查kube-proxy、CNI插件的日志（比如kubectl logs -n kube-system <kube-proxy-pod>），有没有网络组件异常波动导致连接断连。

代码与依赖排查 #

• 对齐环境依赖：对比本地和EKS的Node版本、WebSocket客户端库版本（比如ws的版本），排查是否存在版本差异导致的兼容性问题。
• 检查代码异常处理：确认有没有未捕获的异常导致进程重启？添加全局异常捕获日志，排查进程是否存在意外退出的情况。
• 换客户端库测试：比如把ws换成原生WebSocket API或者socket.io-client（如果提供商支持），排除库本身的问题。

极简测试验证 #

• 用wscat做测试：在EKS里跑一个alpine Pod，安装wscat后直接连接提供商的WebSocket端点，观察是否同样出现1006断连。如果测试Pod也断，说明是网络或提供商侧问题；如果正常，就是你应用代码的问题。
• 换Node节点调度：把Pod调度到不同的Node上，排查是不是特定节点的网络存在问题。

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