代理协议里的"传输方式"是决定流量长什么样的关键，gRPC 是近几年热度上升最快的一个。直接上对比，不绕弯子。
一句话：gRPC 是什么#
gRPC 是 Google 开源的高性能远程调用框架，基于 HTTP/2。代理协议借用它做传输层，相当于把代理流量装进"正规"的 gRPC 调用里。审查者看到的是一堆 HTTP/2 的数据流，很难一眼看出这是代理。
横评：四种主流传输方式对比#
| 传输方式 | 原理简述 | 优点 | 缺点 | 适合场景 |
|---|---|---|---|---|
| TCP（裸） | 直连，无伪装 | 延迟最低、配置最简单 | 特征明显，审查严的地区秒封 | 宽松地区、内网穿透 |
| WebSocket | 伪装成网页实时通信 | 兼容性无敌，可套 CDN | 单连接效率一般，高并发吃力 | 新手默认选择、套 CDN 隐藏 |
| gRPC | 基于 HTTP/2 的多路复用 | 多路复用、抗干扰强、特征正规 | 配置稍复杂，部分老旧客户端不支持 | 高延迟线路、多设备共享 |
| HTTP/2 | 复用 HTTP/2 连接 | 和 gRPC 类似，生态成熟 | 实际部署中逐渐被 gRPC 替代 | 备选方案 |
gRPC 的核心优势：多路复用#
这是 gRPC 最值得说的点。传统 WebSocket 下，每个代理连接相对独立；而 gRPC 基于 HTTP/2 的多路复用，多个数据流共享一条连接，好处有三：连接建立开销小（握手一次管所有）、弱网下表现更稳（丢包不影响整条连接）、流量特征更像正常应用（本来就是正规协议的行为）。
实际体验上，高延迟线路（比如跨太平洋）用 gRPC，页面加载的"跟手感"会比 WebSocket 好一截。这也是游戏加速场景有人推荐它的原因，不过游戏到底该用代理还是加速器，是另一个话题：这篇讲透了。
gRPC 的短板#
两点。第一，不是所有客户端都支持，老旧客户端和部分精简版 App 可能没有 gRPC 选项，选之前先确认客户端支持列表；第二，配置门槛略高，服务端要配 serviceName 等参数，抄错一个字母就连不上，新手建议直接用机场给的现成 gRPC 节点，别自己折腾服务端。
gRPC + TLS + REALITY：2025 年的热门组合#
单独聊 gRPC 是不够的，2025 年实战中最常见的形态是组合技：VLESS 打底，gRPC 做传输，TLS 做加密，外面再套一层 REALITY 做伪装。这一套的思路是层层设防——REALITY 负责"看起来像正常网站"，TLS 负责加密，gRPC 负责高效传输。
和纯 WebSocket 组合比，这套的优势在高延迟线路上最明显；劣势是配置复杂度上了一个台阶，serviceName、authority 这些参数抄错一个就全军覆没。新手建议：直接用机场提供的现成 gRPC 节点，别自己从零配服务端。
服务端配置的三个注意点#
如果你是自己搭（参考自建还是买机场的决策建议），配 gRPC 时注意：
- serviceName 别用默认值：默认的 serviceName 是公开的秘密，审查者照着特征库一查一个准，改成随机的字符串。
- 和网站共存：gRPC 服务最好和一个正常网站跑在同一端口，流量混在一起，真假难辨。
- 客户端版本要跟上：gRPC 支持是这两年才普及的，老版本客户端可能没有这个选项，升级到 2025 年的版本再玩。
该怎么选：三句话#
- 新手、求稳：WebSocket，兼容性之王，跟着VLESS 详解里的经典搭配走就行。
- 线路延迟高、经常多设备同时用：试试 gRPC，多路复用的优势能感知到。
- 审查严格地区：gRPC + TLS 是 2025 年的主流抗封锁组合之一，和 REALITY 搭配使用效果更好。
普通人怎么验证 gRPC 是不是适合自己#
别光看理论，实测三步走。第一步，找机场要一个 gRPC 节点（很多机场的订阅里直接带，留意节点名里的 grpc 字样）；第二步，在你常用的高延迟场景下用几天——比如晚高峰看视频、多设备同时在线；第三步，对比之前用的 WebSocket 节点，主观感受有没有"更跟手"。有提升就留着，没感觉就换回去。传输方式没有鄙视链，只有合不合适，实测是唯一的裁判。
一句话：gRPC 不是"更高级"的传输，而是"更适合特定场景"的传输。选传输和选鞋一样，合脚比贵重要。下次看到机场节点列表里出现 gRPC 选项，你就知道它是什么、适合谁、该怎么用了——这就是懂原理的底气，比盲目跟风换协议靠谱得多，也比出了问题只会重装强得多。
