WebSocket 长连接总是中途掉线？先弄清是谁把连接掐断的

WebSocket 中途断开，最常见的原因是代理链路上的某一环把"看似闲置"的长连接回收了。第一步：在客户端固定使用单个稳定节点、关闭自动测速切换，再观察断开是否复现。

故障表现

• 网页可以正常打开和刷新，但在线协作文档、网页版聊天、AI 对话这类页面用着用着提示"连接已断开""正在重新连接"。
• 实时行情、日志推送等界面数据突然停止更新，手动刷新后又恢复。
• 断开时间似乎有规律，比如每隔几分钟一次。
• 普通浏览、下载等短连接业务几乎不受影响。

这类问题的共同点是：一次性的请求都正常，需要"挂着不动"的连接才出事。原因在于两者的工作方式完全不同——打开一个网页是一连串短请求的组合，每个请求几秒内完成、断了浏览器会自动重发；而 WebSocket、SSE 这类长连接要求链路上每一环在几分钟甚至更久的时间里持续维持同一条通道，任何一环中断，页面就会掉线。

最常见原因（按概率排序）

1. 节点或中转服务器回收空闲连接。 短请求用完即走，代理服务器无须长期维护；长连接则要持续占用资源。不少机场的网关或中转机会对一段时间没有数据往来的连接做超时清理，长连接因此被动断开。

2. 客户端切换节点或重载配置。 开启自动测速、故障转移或负载均衡策略时，客户端切换节点会重建全部连接；修改规则、更新订阅同样会触发。网页浏览对此几乎无感，长连接则直接中断。

3. 中间设备的会话老化。 家用路由器、公司防火墙、运营商 NAT（移动网络的 CGNAT 尤其明显）都维护着连接状态表，闲置会话到期即被清除。长连接若缺少足够频繁的心跳数据，就可能被这些设备静默丢弃。

4. 负载均衡导致出口 IP 变化。 一些节点背后是多台落地机轮换，断线重连后出口 IP 与上一次不同。普通浏览影响不大，但依赖会话状态的服务（多数 AI 工具属于这类，参见 AI 工具使用指南）可能把 IP 变化视为异常并切断会话。

5. 传输方式与中间层不适配。 WS 伪装流量经过 CDN 转发时，还要受 CDN 自身空闲超时的约束；基于 UDP 的 QUIC、Hysteria2 等协议在部分网络下会被 QoS 限制，表现同样是连接时断时续。

快速判断方法

1. 看断开有没有固定周期。 每 60 秒或每 5 分钟准时断一次，往往指向某处的固定超时值，而非随机波动。
2. 换网络对比。 用手机热点跑同样的页面，若不再断开，问题多半出在原网络的中间设备上。
3. 固定单一节点复测。 关闭自动切换后仍断，可排除客户端切换因素；不断了，说明是策略组切换造成的。
4. 确认出口 IP 是否漂移。 断开前后分别查询出口 IP，若发生变化，优先怀疑多出口负载均衡。

分平台解决步骤

Windows

在 Clash Verge 等客户端中，把策略组从"自动选择"改为手动固定节点，关闭 URL 测速自动切换；使用规则模式而非全局模式，减少无关流量挤占连接。设置方法可参考 Clash Verge 使用教程。

Android

除固定节点外，还要把代理 App 加入电池优化白名单，避免系统在息屏后限制其后台网络，操作见 Clash Meta for Android 教程。部分国产定制系统的"智能省电"需要单独放行。

iPhone

Shadowrocket 用户建议保持单节点运行，避免频繁切换配置导致 VPN 隧道反复重建；具体设置参考 Shadowrocket 配置教程。长任务进行中尽量不要在 Wi-Fi 与蜂窝之间切换。

如何判断是不是机场线路的问题

用同一台设备、同一网络环境做交叉验证：换到另一条线路或另一家服务商后长连接立刻稳定，多半就是原线路的问题。可以进一步向客服确认两点——该节点是否为多出口负载均衡、空闲连接的超时时间是多久。对长连接要求高的场景（AI 对话、远程开发等），优先考虑单一出口、会话保持较好的线路，IEPL/IPLC 专线在这方面通常表现更稳，可参考专线协议介绍与 AI 场景机场选择建议。

FAQ

问：为什么网页都能打开，偏偏长任务会断？ 答：网页由大量短请求组成，单个请求几秒内完成，失败了浏览器会自动重试；长连接要求链路上每一环持续维持同一条通道，任何一环回收连接都会表现为掉线。

问：心跳包能解决问题吗？ 答：应用层心跳能让中间设备认为连接仍在活跃，降低被回收的概率，但心跳由网站或应用自身实现，用户端能做的主要是选择超时宽松的线路和稳定的节点。

问：断开后客户端显示节点仍然"可用"，正常吗？ 答：正常。节点延迟测试只验证能否新建连接，并不代表已有的长连接没被中断，两者是不同维度的指标。

问：换成专线就不会断了吗？ 答：不能这样保证。专线减少了公网中转的不确定性，会话稳定性通常更好，但客户端策略、本地路由器的超时设置同样可能导致断开，仍需逐层排查。