WebSocket 是什么？WS 在代理协议中的作用
WebSocket（简称 WS）是一种”传输方式 / 承载载体”，不是代理协议——它负责把 VMess、VLESS 这类代理协议的流量，装进一条像访问普通网站的连接里运出去。
快速结论
- WS 工作在
TCP之上、HTTP层，属于”怎么运流量”的传输层面； - 它本身不做代理、也不提供加密，真正的代理逻辑由
VMess/VLESS负责； - 用 WS 的主要目的：让流量能穿过 CDN 与反向代理，伪装成正常网页请求；
- 常见组合是
VLESS + WS + TLS，订阅里的ws只是一个传输字段，客户端会自动处理。
如果你还分不清”协议”和”传输”的区别，先读什么是代理协议会更顺。
WebSocket 到底是什么
WebSocket 最初是给网页做实时通信用的技术，比如网页聊天、行情推送。它的建立方式很特别：先发一个普通的 HTTP 请求，带上一个”请把这条连接升级为 WebSocket”的头（Upgrade: websocket），服务器同意后，这条连接就从一问一答的 HTTP，变成一条可以双向持续收发数据的”全双工”通道。
关键点有两个：
- WS 建立在
TCP之上，握手阶段”长得就像”一次正常的网页访问； - 升级完成后，双方可以随时互发数据，不必每次重新请求——这正好适合代理这种需要持续双向传输的场景。
想深入 TCP、UDP、QUIC 这些底层承载的差别，可以看TCP、UDP 与 QUIC。
在代理里，WS 扮演什么角色
这里是最容易搞混的地方。代理协议（如 VMess、VLESS）负责”内容”——怎么加密、怎么和服务器握手、怎么标识用户；WebSocket 负责”外壳”——把这些内容包装成一条 HTTP/WebSocket 连接运出去。
打个比方：VLESS 是要寄的信，WebSocket 是信封。信封决定了这封信在路上”看起来像什么”，但信封不会改写信的内容。所以你会看到”VLESS over WS”这样的说法——VLESS 跑在 WS 里，WS 只是承载它的管道。
也正因如此，WS 从不单独出现。它总是和某个代理协议搭配，订阅里也写成 vmess + ws 或 vless + ws + tls 这样的组合字段。
为什么要套一层 WebSocket
直接用裸 TCP 传代理流量当然也行，但套上 WS 有一个不可替代的好处：它能穿过 CDN 和反向代理。
CDN（如 Cloudflare）本质上是一堆分布在全球的 HTTP 服务器，它只认识 HTTP/HTTPS 流量。WebSocket 的握手就是标准 HTTP，升级后又能长时间保持连接，所以代理流量套上 WS 之后，CDN 会把它当成普通的网站长连接乖乖转发。这正是 CDN 中转得以实现的技术前提。
配合 CDN 之后，你的真实服务器 IP 被藏在 CDN 背后，外界只看到 CDN 的 IP，抗封锁和隐藏源站的能力都大幅提升。
WS 与 TLS 的组合
WebSocket 本身不加密。为了既加密又伪装，实战里几乎总是叠加 TLS：
TLS负责加密，让中间人看不到传输内容；WS负责封装，让这条连接从外部看就是一次 HTTPS 网页访问；- 两者相加，代理流量就与海量正常 HTTPS 网站流量混在一起，难以被单独挑出来。
TLS 具体做了什么、为什么它是伪装的基础，见 TLS 加密与伪装。
订阅里的 WS 长什么样
机场把 WS 节点写进订阅时，除了协议和地址，还会带上两个 WS 专属参数：path（路径）和 Host（主机名）。它们的作用是让这条连接更像访问某个具体网页——path 相当于”访问网站的哪个页面”（例如 /download），Host 则告诉 CDN 和服务器”我要访问哪个域名”。服务端只有在 path 与 Host 都对得上时，才会把连接交给代理程序处理，其余请求一律当成普通网页，这进一步增强了伪装效果。
对普通用户来说，这些参数不需要理解也不需要改动：导入订阅后客户端会原样带上，你要做的只是选节点、连接。真正值得留意的是，当机场提示”某节点走 Cloudflare”时，它多半就是 VLESS/VMess + WS + TLS + CDN 的组合——遇到大范围封锁时，这类节点往往比裸奔的直连节点更扛得住。
优点与代价
| 维度 | WebSocket 的表现 |
|---|---|
| 伪装性 | 好，握手像普通网页，可套 CDN |
| CDN 兼容性 | 极好，基于 HTTP/1.1，几乎所有 CDN 都支持 |
| 传输效率 | 一般，每条连接独立，无多路复用 |
| 额外开销 | 略高，多了 HTTP 头与升级握手 |
| 配置难度 | 低，主流客户端与机场都支持 |
简单说：WS 用一点点效率开销，换来了极好的伪装和 CDN 兼容性。对绝大多数机场用户来说，这笔交易很划算。
和 gRPC 的区别
你可能在订阅里同时见过 ws 和 grpc。它们的定位完全一样——都是承载 VMess/VLESS 的传输方式，都能配合 CDN——区别在底层：WS 基于 HTTP/1.1，gRPC 基于 HTTP/2，后者支持多路复用，在某些网络下连接更稳、复用更好。两者详细的取舍见 gRPC 与 WebSocket 的区别。
常见误区
- “WS 是一种协议，可以代替 VMess”——错。WS 不做代理，必须承载某个代理协议才有意义。
- “看到 ws 要手动去开一个开关”——不用。它是机场写好的节点字段，客户端自动处理。
- “用了 WS 就一定更快”——不一定。WS 的价值在伪装和过 CDN，不在提速；纯速度更多取决于线路质量。
下一步
想搞清楚同样用于承载、但基于 HTTP/2 的另一种传输，读 gRPC 是什么；想知道 WS 最常见的用途——把流量藏到 Cloudflare 背后，读 CDN 中转是什么。