代理协议的传输方式:TCP、WebSocket 与 gRPC 的取舍
传输方式决定代理协议的数据装在什么“容器”里发出:原始 TCP 结构最简单,WebSocket 能经过 HTTP 反向代理与 CDN,gRPC 基于 HTTP/2 可在一条连接里复用多路请求。本文解释三者的工作方式、各自需要的参数和适用条件,不做性能排名。
传输方式是“容器”,不是协议本身
传输方式决定代理协议的数据装在什么载体里发出。原始 TCP 直接传输,结构最简单;WebSocket 把数据装进一次升级后的 HTTP 连接,能经过常见的反向代理与 CDN;gRPC 基于 HTTP/2,可在一条连接里同时承载多路请求。三者没有统一的优劣,取舍取决于运营方要不要经过中间层、客户端支持哪些参数,以及对握手次数和复用的需求。
本文讲传输层概念,不做性能排名。所属二级专题见 代理协议二级专题,协议总览见 一级专题的协议章节。
一个节点的三层组合
理解传输方式,先把节点拆成三层:
| 层 | 例子 | 回答的问题 |
|---|---|---|
| 代理协议 | VLESS、Trojan、VMess、Shadowsocks | 你是谁、要去哪里 |
| 传输方式 | 原始 TCP、WebSocket、gRPC 等 | 数据装在什么载体里 |
| 安全层 | TLS、REALITY 或无 | 载体外面是否加密、外观像什么 |
同一个“VLESS 节点”,可能是 VLESS + 原始 TCP + REALITY,也可能是 VLESS + WebSocket + TLS。三层任何一层客户端不支持,节点就无法使用。Shadowsocks 一般不走这套组合,而是通过插件改变外观,原理见 Shadowsocks 与 AEAD 加密。
原始 TCP:最少的中间环节
原始 TCP 指代理协议的数据直接写进 TCP 连接,外面再套 TLS 或 REALITY。它的特点是:
- 封装最少。 除了安全层,没有额外的头部和握手。
- 支持流控。 VLESS 的 Vision 等流控模式通常只在原始 TCP 上生效。
- REALITY 的常见搭档。 REALITY 需要直接处理 TLS 握手,与原始 TCP 搭配最直接。
- 不能经过普通 HTTP 中间层。 数据不是 HTTP 格式,常规的网站反向代理和 CDN 无法转发它。
需要的参数最少,一般只有地址、端口、安全层相关参数,导入出错的概率也较低。
WebSocket:借一次 HTTP 升级
WebSocket 原本是网页实现实时通信的技术。连接以一次普通 HTTP 请求开始,请求里声明“升级到 WebSocket”,服务器同意后,这条连接就变成可双向传输任意数据的通道。代理协议借用的就是这条通道。
它的意义在于“像网页流量一样经过中间层”:因为开头是标准 HTTP 请求,常见的反向代理和许多 CDN 都能识别并转发。运营方因此可以把节点放在反向代理或 CDN 后面。
代价是参数和开销都多了一些:
- 路径:HTTP 请求的路径,服务器靠它区分不同服务;
- Host:HTTP 请求头里的域名,前置代理靠它分发;
- 额外握手:每条新连接都要先完成 HTTP 升级,部分实现提供“早期数据”选项把首段数据随请求一起发出,以减少等待。
路径或 Host 与服务器不一致,是 WebSocket 节点导入后连不上的常见原因。Host 与 SNI 的区别见 TLS、SNI 与证书校验的协议层原因。
gRPC:在 HTTP/2 上复用
gRPC 是一种基于 HTTP/2 的远程调用框架。代理协议使用它时,数据被装进 HTTP/2 的数据流中。HTTP/2 的特点是一条连接里可以同时开多条“流”,因此多路请求可以共享同一条 TCP 与 TLS 连接,减少重复握手。
它同样能经过支持 HTTP/2 和 gRPC 的反向代理与部分 CDN。需要的参数主要是服务名称,以及在 TLS 中声明 HTTP/2 的 ALPN。复用也有另一面:多路请求共用一条 TCP 连接时,这条连接上一旦丢包,所有流都要等重传,这就是常说的“队头阻塞”。丢包较多的环境下,这个影响可能比单独连接更明显。
三种方式的取舍对照
| 维度 | 原始 TCP | WebSocket | gRPC |
|---|---|---|---|
| 额外封装 | 最少 | HTTP 升级头 + 帧头 | HTTP/2 帧 |
| 能否经过 HTTP 反向代理或 CDN | 不能 | 多数能 | 需支持 HTTP/2 与 gRPC |
| 连接复用 | 每个请求一条连接 | 每个请求一条连接 | 多路复用一条连接 |
| 新连接的等待 | TCP + 安全层握手 | 再加 HTTP 升级 | 复用时可省去握手 |
| 关键参数 | 安全层参数 | 路径、Host | 服务名称、ALPN |
| 与 REALITY、流控的搭配 | 常见 | 一般不搭配 | 部分实现可搭配 REALITY |
此外,社区还有基于 HTTP 升级的简化方案、基于 HTTP 分段请求的新型传输等,命名在不同内核里不完全一致。遇到不认识的传输名称时,先确认客户端内核是否支持,再考虑其他原因。
经过 CDN 意味着什么
WebSocket 与 gRPC 常被提到“可以经过 CDN”,这句话需要放在链路里理解。经过 CDN 时,你的客户端先连到 CDN 的边缘节点,再由 CDN 把请求转给运营方的服务器。这样做可能带来几点变化:
- 入口地址变了。 你连接的是 CDN 的地址,而不是代理服务器本身,这影响的是接入段,而不是落地出口。
- 多了一段转发。 CDN 到服务器之间多出一跳,延迟和稳定性也要看这一段的情况。
- TLS 可能被拆成两段。 客户端与 CDN 之间一段,CDN 与服务器之间一段,代理协议本身的数据仍在内层。
这与专线并不是一回事:CDN 解决的是“能否经过 HTTP 中间层”,专线解决的是“跨境段走哪条路”。线路分段的概念见 专线类型:IEPL、IPLC 与中转。某个机场是否使用 CDN,资料一般不会写明,以各品牌说明为准。
选择权在谁手里
传输方式由运营方在服务器端决定,用户只能在订阅提供的节点里选择。对用户有意义的判断是:
- 客户端是否支持订阅里出现的每一种传输方式;
- 某种传输方式的节点普遍失败时,是否与客户端版本或订阅转换有关;
- 同一地区若同时有多种传输方式的节点,可以在自己的网络下分时段对比,不必依赖他人结论。
本站整理的 17 个品牌资料都没有写明传输方式,这一字段对所有品牌都属于待核实,只能在导入后从节点详情中看到。传输、复用、流控等术语可在 常用术语表 中查阅;按客户端条件选择协议的思路见 VLESS、Trojan、Shadowsocks 怎么选。
请遵守所在地法律法规与平台条款,本文不提供服务器部署或规避监管的方法。
常见问题
传输方式和代理协议是一回事吗?
不是。代理协议(如 VLESS、Trojan)规定怎样认证和寻址,传输方式规定这些数据装在什么载体里发出。同一种协议可以搭配不同传输方式,节点参数里通常分开显示。
WebSocket 节点为什么要填路径和 Host?
WebSocket 连接以一次 HTTP 请求开始,路径和 Host 写在这次请求里,服务器或前置的反向代理靠它们把连接分给正确的后端。两项与服务器设置不一致时,连接会被拒绝或转到别处。
哪种传输方式更快?
没有脱离环境的固定答案。额外封装会带来一定开销,但实际体验还受线路、拥堵、服务器负载与客户端实现影响。本站不对传输方式做性能排名,建议在自己的网络下用同一节点的不同组合分时段对比。
来源与更新
品牌字段来自本站品牌数据文件(整理自 2026-09-04 品牌清单,Vendor Data,官网待核实);测速截图为 2026-10-18 复核后发布的单次 Measured Data;AI 与流媒体均为 Not Tested。发布 2026-10-18,最近更新 2026-10-18。本页不承诺任何平台的收录、排名或引用。