客户端收到 HTTP 101 状态码，只能说明 WebSocket 握手已建立；连接之后是否稳定，还取决于 CDN 是否支持协议升级、空闲超时和回源转发。配置前先核对这些能力，才能让cdn加速对WebSocket长连接的支持与配置真正适用于实时消息、在线协作或状态推送等场景。
先确认 CDN 能否代理长连接
WebSocket 通常先通过 HTTP 握手建立连接，再以双向通信方式持续传输数据。客户端使用 wss 时，链路还涉及 TLS 加密。CDN 需要能够转发握手中的协议升级信息，并在握手成功后保持连接，而不是按普通网页请求处理。
不同 CDN 的支持范围可能不同：有的需要在控制台单独开启 WebSocket，有的仅支持指定业务类型、端口或套餐。还应确认连接空闲超时、单连接最长存活时间、回源协议及可用区域。产品说明未写清时，应向服务商核实，不要仅凭普通 HTTP 加速已启用就推断长连接也可用。
配置时抓住四个关键点
握手与转发规则
为实时接口准备独立域名或路径，例如消息接口使用专门的子域名。确认 CDN 会保留并正确转发 Upgrade、Connection 等握手头，以及 Host、查询参数和必要的鉴权信息。后端必须能对有效握手返回 101；否则应从应用日志和 CDN 回源日志分别检查。
缓存、TLS 与回源
WebSocket 握手及后续连接不应被当作普通静态文件缓存。为接口路径设置绕过缓存或明确的动态转发规则，避免缓存规则、重定向或访问控制误拦截握手。使用 wss 时，检查客户端到 CDN 的证书配置；CDN 到源站是否加密，则按服务商能力和安全要求选择，并确认源站接受相应协议与端口。
超时、心跳和后端状态
长连接常因空闲超时被中间层关闭。先查清 CDN 与源站各自的超时限制，再把应用的心跳间隔设得短于较短的空闲限制，并预留网络抖动余量。心跳不宜过密，否则大量客户端会增加无效流量与服务端负担。
连接建立后通常固定落在某个后端实例上；若后端有多台机器，跨连接共享的会话状态应放在可共同访问的存储或服务中。即使使用负载均衡保持连接，也不能假定客户端重连后仍会回到原实例。
按步骤上线并验证
- 核对能力：确认 CDN 支持 WebSocket、目标端口和业务域名，并记录连接超时及回源限制。
- 配置规则：为接口设置动态转发，检查握手头、查询参数、鉴权信息和 TLS；静态资源缓存规则不要覆盖该路径。
- 小范围连通：用测试客户端连接 CDN 域名，确认握手返回 101，双向发送消息均可收到，并检查浏览器开发者工具或客户端日志。
- 观察稳定性：在预期网络环境下观察连接保持、心跳和断线重连；对比经 CDN 与直连源站的表现，查看边缘日志、源站日志及错误状态。
- 逐步放量：确认并发连接、文件描述符、带宽和后端处理能力足够后再扩大流量。上线期间监控连接数、握手失败率、断线频率和消息延迟。
故障表现与排查方向
- 握手不是 101：检查路径、鉴权、请求头转发、源站响应，以及 CDN 是否启用了协议升级。
- 总在相近时间断开：排查 CDN、负载均衡和源站的空闲或最长连接时限；若只有静默连接中断，调整心跳与超时配置。
- 经过 CDN 才失败：检查缓存、重定向、WAF 规则、回源端口和 TLS 配置，并用日志确定请求停在哪一层。
- 重连后状态丢失：检查应用是否把必要状态仅保存在单台实例内；断线重连本身应视为正常情况，客户端需有退避重试和状态恢复机制。
因此，cdn加速对WebSocket长连接的支持与配置不是单开一个开关，还要同时验证协议升级、超时、缓存、回源和应用容错。先用小流量确认完整链路，再按监控结果调整参数，通常比一次性扩大连接规模更稳妥。
常见问题
所有 CDN 都支持 WebSocket 吗？
不一定。功能、端口、区域和超时限制因服务商及产品而异，应查看当前产品文档或确认服务商答复。
WebSocket 一定要使用独立域名吗？
不一定。独立域名便于隔离缓存和安全规则；使用同一域名下的独立路径也可行，前提是路由配置不会与普通网页请求冲突。
连接频繁断开，应该先调大超时吗？
先确认实际断开时长和发生位置，再检查 CDN、负载均衡与源站的限制。若受控于平台上限，单改应用参数无效；同时应设置心跳与自动重连。