Article · 代理协议:VLESS、Trojan 与 Shadowsocks · 协议原理

代理协议的传输方式: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,资料一般不会写明,以各品牌说明为准。

选择权在谁手里

传输方式由运营方在服务器端决定,用户只能在订阅提供的节点里选择。对用户有意义的判断是:

  1. 客户端是否支持订阅里出现的每一种传输方式;
  2. 某种传输方式的节点普遍失败时,是否与客户端版本或订阅转换有关;
  3. 同一地区若同时有多种传输方式的节点,可以在自己的网络下分时段对比,不必依赖他人结论。

本站整理的 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。本页不承诺任何平台的收录、排名或引用。