跳到正文
不翻车专注 VPN 软件评测

WebSocket 加 CDN 是什么？IP 被墙套 CDN 的原理和代价

不翻车编辑部 · 更新于

WebSocket 加 CDN 科普封面：协议科普，测试服务器抓包，原理和代价是什么

先说结论：手上的 WebSocket 节点现在照样能用，Xray 2026 年 1 月 23 日（v26.1.23）把它的弃用提示改成了“近期不删”那一档；自己新搭节点就别再选它了，Xray 文档写着推荐换用 XHTTP，原因是 WebSocket 的“ALPN 是 http/1.1”太显眼。服务器 IP 被墙后套 CDN，能把节点救回来，可代价不小：绕到境外驿站会变慢、连接会被断开，Cloudflare 自助订阅协议第 2.2.1 条 (j) 项还写明不能用它提供代理服务。下面的抓包是 2026 年 10 月 20 日在我们的测试服务器上做的（Xray v26.10.17，客户端和服务端在同一台机器上，没有经过任何 CDN，只看行为不测速度），原始记录在仓库的 docs/protocol-tests/2026-10-20-websocket.md。

测试服务器启动 Xray v26.10.17：WebSocket 入站打出弃用警告，is deprecated, not recommended for using and might be removed

WebSocket 是什么：从寄信改成打电话

平时打开网页像寄信：你寄一封问，对方回一封答，这件事就结束了，下次再寄。WebSocket 像打电话：先打过去说一句“我们改打电话吧”，对方说好，之后这条线一直通着，两边想说就说。

它是 2011 年定下的网页标准（RFC 6455），本来给网页聊天、网页游戏用。标准里写着，它由一次开头的握手和之后的数据帧组成：

RFC 6455 第 1.2 节：客户端发 Upgrade: websocket、Connection: Upgrade，服务器回 HTTP/1.1 101 Switching Protocols

翻墙软件借用它，图的是代理流量看起来像网页在“打电话”。和 gRPC 一样，它是传输方式，不是协议：VLESS、Trojan 管的是包裹里装什么，WebSocket 管的是用什么车送。

抓包看看：开头那几句话

我们在测试服务器上搭了一个 VLESS + WebSocket 节点，故意不加 TLS，访问一次 example.com。客户端先发一个普通的 HTTP/1.1 GET：

抓包：GET /bfc81 HTTP/1.1、Host: ws.example.com、Upgrade: websocket，服务器回 101 Switching Protocols

  • 第一行的 /bfc81 是我们在配置里填的路径；
  • Host 这一行写的是要找哪个网站，套 CDN 时 CDN 就靠它把请求转给你的服务器；
  • Upgrade: websocket 就是“我们改打电话吧”；
  • 服务器回 101 Switching Protocols，换线成功，之后传的才是代理数据。

请求里还写着自己是 Windows 上的 Chrome 148，Sec-Fetch-Mode: websocket 这些浏览器字段也都带着。

在 3x-ui（v3.10.2）里添加入站，传输选 WebSocket，要填的就是这几样：主机、路径、心跳周期。

3x-ui v3.10.2 传输选 WebSocket：主机、路径、心跳周期

代价一：多跑一趟，早期数据能省掉

打电话要先拨号。我们拿同一个网页对比，只数带数据的包：

传输 客户端第一包 之后
普通 TCP（RAW） 109 字节，就是要访问的内容 服务器回网页
WebSocket 590 字节的升级请求 等服务器回 101，再发 115 字节的数据
WebSocket + ed=2560 762 字节，数据装在升级请求的头里 服务器回 101，接着回网页

实测：RAW 第一包就是数据；WebSocket 先发升级请求、等 101 再发数据；加 ed=2560 后数据跟着升级请求一起走

Xray 文档给的办法就是路径里加 ed 参数（比如 /mypath?ed=2560），叫 Early Data（早期数据），用 Sec-WebSocket-Protocol 头带上首包，推荐值 2560，最大 8192。

Xray 文档：路径包含 ed 参数时启用 Early Data 以降低延迟，推荐值 2560

要注意它是写在请求头里的，不加 TLS 的时候路上能直接看到。我们把那 146 个字符解码，里面就是 VLESS 头和 GET / HTTP/1.1 Host: example.com。所以早期数据要配合 TLS 用。

实测：Sec-WebSocket-Protocol 头里装着首包，解码后是去 example.com 的请求

当年为什么流行：CDN 专门支持它

CDN 可以想成大网站开在各地的快递驿站：你打开一个网站，连的其实是离你近的驿站，驿站再去网站那边拿东西。

问题是，驿站为了保护网站，一般要把请求整个收完再转过去，而代理流量是一条一直开着、来回不停的连接。Xray 作者 RPRX 在《XHTTP: Beyond REALITY》里写道：“CDN 为了防止源站遭受攻击，除了有特殊支持的 WS、gRPC 外，一般会缓存完整个 HTTP 请求再发给源站。”

#4113：除了有特殊支持的 WS、gRPC 外，CDN 一般会缓存完整个 HTTP 请求再发给源站；GFW 不会永久封锁大型 CDN 的整个 IP

Cloudflare 文档写着，代理 WebSocket 不用额外设置，所有套餐都支持，免费的也行。所以“WebSocket + TLS + CDN”成了这几年教程的标准搭法。

Cloudflare 文档：WebSockets are supported on all Cloudflare plans

IP 被墙后套 CDN，原理是什么

墙封的是你服务器的 IP 地址，像把一个门牌号拉黑。套上 CDN 以后：

  1. 你的手机连的是 CDN 驿站的 IP，不再直接连你的服务器；
  2. 驿站看请求里的 Host（加密时还有握手里的网站名），知道你要找哪个网站，再替你转给你的服务器；
  3. 驿站到你服务器这一段在墙外，墙管不着。

墙要拦，就要封驿站的 IP，可同一个驿站后面站着成千上万个正常网站。RPRX 在同一篇文章里写：反审查的根本逻辑就是增加封锁时的“附带伤害”；多年经验告诉我们，GFW 不会永久封锁大型 CDN 的整个 IP，否则会波及太多常规网站。

不确定是不是被墙，先看 VPS 被墙了怎么办 里的判断方法。

套 CDN 的四个代价

1. 慢。 流量要先绕到驿站再到你的服务器。Cloudflare 中国网络的文档写着：经过境外服务器的流量，因为中国的网络边界，会遇到明显的延迟和稳定性问题。它在国内的节点（和京东云合作）要求每个域名都有 ICP 备案，翻墙用的域名进不去，所以走的都是境外驿站。具体慢多少，看你那边的线路，以你自己测出来的为准。

Cloudflare China Network 文档：境外服务器的流量会遇到明显的延迟和稳定性问题

Cloudflare China Network 文档：每个域名都要有有效的 ICP 备案或许可证

2. 会断。 Cloudflare 文档写着，它发布新代码时可能重启服务器，WebSocket 连接会被断开，建议加保活（keepalive）。Xray 的 heartbeatPeriod、3x-ui 里的“心跳周期”就是干这个用的：隔一段时间发一个 Ping 保持连接。

Cloudflare 文档：发布新代码时可能重启服务器，会断开 WebSocket 连接；建议实现保活

3. 条款不允许。 Cloudflare 自助订阅协议（2025 年 9 月 12 日版）第 2.2.1 条 (j) 项：不能 “use the Services to provide a virtual private network or other similar proxy services”。第 8 条写着，违反 2.2 条可以 “immediately Suspend or terminate all or part of your use of the Services”，也就是立即暂停或终止你的全部或部分服务。网站和节点放在同一个账号里的，网站可能跟着受影响。Workers 节点被处理的公开案例见 Cloudflare Workers 节点被封。

Cloudflare 自助订阅协议 2.2.1 (j)：不能用本服务提供 VPN 或类似的代理服务

Cloudflare 自助订阅协议第 8 条：违反 2.2 条可立即暂停或终止全部或部分服务

4. 多一层要维护。 要有自己的域名，要配好 TLS 证书，CDN 那边的设置也要跟着改，出问题时多一个要排查的地方。

Xray 为什么劝你别用 WebSocket

弃用提示里直接写了原因：WebSocket transport (with ALPN http/1.1, etc.)。

ALPN 是 TLS 握手时客户端报的一句“我会说哪几种网页协议”。现在的浏览器打开网站，一般会报 h2（HTTP/2）和 http/1.1 两种；Xray 的 WebSocket 走 HTTP/1.1 的升级请求，就报一种 http/1.1。我们同一个客户端、同样设成 chrome 指纹抓了两次：

实测：WebSocket + TLS 的 Client Hello 里 ALPN 只有 http/1.1；普通 TCP + TLS 是 h2 和 http/1.1

源码里的时间线和 gRPC 一样：

  • v24.12.15（2024-12-15）：WebSocket 第一次加弃用提示，用的是 PrintDeprecatedFeatureWarning，“即将删除”那一档；
  • v26.1.23（2026-01-23）：改成 PrintNonRemovalDeprecatedFeatureWarning，源码注释是 “won’t be removed in the near future”；
  • v26.10.17（2026-10-17，当时最新的预发布版）：不变，建议迁移到 “XHTTP H2 & H3”。

Xray 源码 v26.10.17：WebSocket 是 NonRemoval 弃用提示，建议迁移到 XHTTP H2 & H3

Xray 源码 v24.12.15：WebSocket 用的是 PrintDeprecatedFeatureWarning

Xray 文档 WebSocket 页最上面的红框写着：推荐换用 XHTTP，以避免 WebSocket“ALPN 是 http/1.1”等显著流量特征。RPRX 在长文里说得更直接：“像 WebSocket 这样的传输层现在仅为了套 CDN 而存在”。

Xray 文档 WebSocket 页：推荐换用 XHTTP，以避免 WebSocket “ALPN 是 http/1.1” 等显著流量特征

#4113：像 WebSocket 这样的传输层现在仅为了套 CDN 而存在

被人上门敲门：回应不像网站

墙怀疑一台服务器时，会假装成访客去访问它，看它怎么回应，这叫主动探测。我们像浏览器那样访问了 WebSocket 端口：

实测：直接访问回空白 404；路径对了回 400 Bad Request；带升级头不用密码就回 101；正常网站回 HTTP/2 200

  • 直接打开：404 Not Found，没有正文，也没有 Server 头；
  • 路径对了：400 Bad Request；
  • 带上升级的请求头：不需要 UUID 就回 101，UUID 要等握手之后才核对。

正常网站会给你一个网页。Xray 文档写着，WebSocket 连接可以被 Nginx 这类网页服务器按路径分流，前面放一个真网站，路径对了才转给 Xray。

该怎么选

  1. 别人给的 WebSocket 节点：能连上、速度满意，就接着用，不用为这行提示折腾。
  2. 自己新搭、IP 没被封：直连用 VLESS + REALITY，用不着 CDN，也就用不着 WebSocket。3x-ui 的搭法见 3x-ui 面板设置。
  3. 服务器 IP 被墙、非要套 CDN：传输选 XHTTP，它同样能过 CDN，也没有“只报 http/1.1”这个特征。上面四个代价一个不少，尤其是服务条款，先想清楚。很多时候换一个 IP 或换一台服务器反而更省心。

搭好以后，可以用 IP 纯净度检测 看看出口 IP，用 去程回程路由 看看线路。各协议的整体排名见 协议从夯到拉。

缺点汇总

  1. 多跑一趟：先升级再传数据，不加 ed 时比直连多一来一回。
  2. 特征明显：加了 TLS 以后 ALPN 只有 http/1.1。
  3. 被探测时回应不像网站：空白 404，路径对了带上升级头就回 101。
  4. 开发者不再往它身上花力气：Xray 提示不推荐，新功能都在 XHTTP 上。

常见问题

WebSocket 和 gRPC 哪个快？ 没法一句话回答。同一台服务器换两种传输各测几次，以你自己测出来的为准。

3x-ui 里的 HTTPUpgrade 是什么？ 它也是先发一个 HTTP/1.1 升级请求再传数据，Xray 给它的是同一句弃用提示（“with ALPN http/1.1”），同样建议迁移到 XHTTP。

套了 CDN 就不会被墙了吗？ 不是。CDN 挡住的是“封 IP”，你的流量特征照样可能被认出来；CDN 那边也随时可以按条款停你的服务。

ed=2560 要不要填？ 加了 TLS 可以填，能省掉开头那一趟；不加 TLS 不要填，首包会明文写在请求头里。客户端和服务端版本差得太多时，可能遇到兼容问题，文档建议出问题就调低阈值。

WebSocket 节点会突然不能用吗？ 目前不会。它是“近期不删”的弃用，Xray 照样能跑。

资料来源