线路与协议:选型技术参考

六种协议的设计取舍

这六种协议在客户端里通常是并列的选项。它们不是新旧替代关系,而是针对不同约束做出的不同取舍:有的把开销压到最低,有的把兼容性做到最好,有的专门为丢包环境设计。理解取舍,比记住「哪个更强」有用得多。

Shadowsocks:轻量与直接

Shadowsocks 的设计目标很单一:用尽量少的开销把 TCP 与 UDP 流量加密转发出去。它用预共享密钥派生会话密钥,对每个数据包做 AEAD 加密,不内置复杂的认证握手,也没有服务端用户体系。结果是首包开销小、服务端资源占用低,适合单人或少量设备使用。代价是它不自带伪装层:流量形态就是一段加密的 TCP 流,和普通 TLS 网页流量不同。需要额外一层 TLS 时,通常由客户端插件或外层转发来做。

VMess:带用户体系的封装

VMess 在协议头里带了用户标识与时间戳,服务端据此判断请求是否合法、属于哪个用户。这让它天然适合多用户与多设备场景:同一个入口可以按用户分流、分别计量。代价是头部比 Shadowsocks 大一些,而且对时间敏感——客户端与服务端的时间偏差超过允许范围时会直接连不上,表现为「节点测试超时」但网络本身正常。遇到这种提示,先把设备时间设为自动同步,再重试。

Trojan:走标准 TLS 的那一类

Trojan 把认证信息放在 TLS 握手之后的应用数据里,端口通常用 443,握手过程与访问一个 HTTPS 站点没有区别。它的优势是兼容性好:中间设备看到的就是一条标准的 TLS 连接。代价是必须维护证书与域名,证书过期或被替换会直接导致连接失败;TLS 握手本身也带来一次往返的开销,首包延迟比纯 TCP 的 Shadowsocks 略高。

VLESS:把加密交给 TLS

VLESS 去掉了协议自带的加密层,只保留轻量的头部与认证,加密完全交给外层 TLS 或 REALITY。好处是服务端 CPU 开销更小、头部更短,在高吞吐场景下更容易跑满带宽;坏处是它必须搭配一个可靠的外层,单独使用没有意义。对普通用户来说,VLESS 与 Trojan 的体感差异通常小于线路差异,不必为此反复切换。

Hysteria2:为丢包环境设计

Hysteria2 基于 QUIC,跑在 UDP 上,自带拥塞控制与带宽协商。它的强项是高丢包、长距离链路:TCP 在这种链路上会因为丢包反复缩小拥塞窗口,Hysteria2 则可以在用户态用更适合的算法维持吞吐。代价有三点:UDP 在部分网络里会被限速甚至丢弃;移动网络切换时连接需要重建;UDP 类流量对 MTU 更敏感,分片配置不对会表现为「能连上但大文件传不动」。

TUIC:QUIC 上的多路复用

TUIC 同样基于 QUIC,重点在多路复用与连接迁移:一条 QUIC 连接里可以并行跑多个请求,单个请求丢包不会阻塞其他请求;从 Wi-Fi 切到蜂窝网络时,QUIC 的连接标识可以让会话延续,不必重新握手。它的适用场景与 Hysteria2 接近,差异更多体现在客户端的拥塞控制实现上。同样受 UDP 可用性约束,网络不放行 UDP 时两者都用不了。

如果只记一条:TCP 类协议决定「稳不稳」的下限由线路给出,UDP 类协议决定「丢包时还能不能跑」。选协议之前先看线路,顺序反了会在错误的维度上反复试——把一条晚高峰拥塞的直连线路,从 Trojan 换到 VLESS 再换到 Hysteria2,体感通常不会有本质变化。

连接建立速度与资源占用

打开一个网页慢,多数人第一反应是带宽不够。实际更常见的原因是往返次数:每次新建连接都要走一遍握手,握手需要往返,往返时间由物理距离和路径质量决定。带宽决定「传得多快」,往返决定「多久开始传」。

一次完整的 TCP 加 TLS 连接大致是这样:先解析域名(可能一次往返),TCP 三次握手(一次往返),TLS 1.3 握手(一次往返,会话复用时可以省掉),然后是协议自身的认证,最后才是 HTTP 请求。也就是说,冷启动一个域名至少要好几个往返;页面里引用了几个不同域名,就要重复几遍。这就是为什么「带宽很大但首屏很慢」的情况并不少见。

QUIC 把传输握手与 TLS 握手合并,首次连接一次往返,会话恢复可以做到 0 次往返就带上数据。这是 UDP 类协议在「打开网页的第一下」感觉更快的主要原因,和带宽无关。代价是 UDP 一旦被网络限制,这条路径直接不可用,没有降级空间。

资源占用分两端看。客户端侧,加解密是主要 CPU 开销:AES 系列在支持硬件加速的处理器上开销很低,在部分移动端处理器上 ChaCha20 更省。服务端侧,主要开销是并发连接数乘以每连接的内存,以及 UDP 类协议需要维护的会话表。多路复用能减少连接数,但也意味着单条连接上要维护更多状态,内存换往返。

一个容易被忽略的点:客户端里的「延迟测试」测的是到入口的一次探测往返,不是到落地的往返,也不是网页加载时间。入口近、落地远的时候,测试数字很好看,实际打开网页仍然慢。判断真实体感要看完整加载与视频缓冲,而不是那一个数字。

移动端电量与流量开销

手机上的耗电来自三处:无线电台被反复唤醒、加解密占用 CPU、断线重连。三者和协议、线路都有关,但权重不同。多数人以为是「加密太耗电」,实际最常见的耗电源是心跳与重连。

先看心跳。为了不让网络地址转换表项过期,客户端会定期发一个小包保活。间隔太短,无线电台频繁从空闲态唤醒,耗电明显;间隔太长,连接被中间设备回收,下次用的时候要重连,重连又触发一次完整握手。合适的间隔取决于所在网络的表项超时时间,家用宽带、公司网络、运营商网络各不相同,客户端通常给一个保守默认值,并提供可调项。拿不准就先用默认值,只在明显异常时再调。

再看重连。移动网络下最贵的操作就是重连:从 Wi-Fi 切到蜂窝、进出电梯、地铁隧道,都会触发。TCP 类协议在网络切换后必须重新握手;QUIC 类协议可以靠连接标识迁移会话,但前提是新路径可达、且中间设备没有拦截 UDP。所以「移动端用 UDP 类更省电」这个说法只在一定条件下成立:切换频繁且 UDP 可用时成立,反之重连更多、更费电。

系统后台限制也要算进去。iOS 与 Android 都会在息屏一段时间后挂起后台应用,客户端被挂起后连接自然断开。这不是协议问题,任何协议都一样。需要长期在线的场景,应该用系统的按需连接类功能,让系统在网络变化时唤醒客户端,而不是让客户端自己一直跑着等。

流量开销方面,协议头本身占比很小,真正影响流量的是重传与心跳。丢包严重的线路上,重传会把实际消耗推高到远超预期;心跳包虽然小,一天几百次也是量。流量包按用量计费时这两项值得注意:VPNWu 的流量包用完为止、永久不过期,月订阅的流量按开通日每月重置,两种计费方式下都建议在客户端里看一眼实际用量,和自己估计的对一对。

怎么自查。用系统自带的电池用量统计,对比「连接状态下待机一段时间」与「未连接状态下待机同样时间」的耗电差异;再看客户端的连接日志,统计这段时间里重连了几次。如果重连次数多,换线路类型通常比换协议更有效——先把路径稳定下来,再谈封装方式。

线路拓扑:直连、中转与专线

线路是这一页里对体感影响最大、却最少被讨论的部分。协议决定封装方式,线路决定数据实际走哪条路。同一条家用宽带,接上不同线路,晚高峰的体验可以差出一个量级,而客户端的协议选项一个都没变。

直连

直连指入口与落地在同一处,数据从用户侧直接到达落地机房。路径最短,理论上延迟最低。它的短板是质量完全取决于这段公共链路的状况:晚高峰拥塞时,直连线路和普通国际访问一起排队,抖动会明显变大。直连适合对延迟敏感、但对晚高峰稳定性要求不高的场景,比如白天办公、临时查资料。

中转

中转在用户与落地之间加一个入口节点:用户先连到离自己近的入口,入口再通过服务商自己的链路把流量送到落地。多了一跳,理论上多几毫秒,但去程那一段被换成了质量更可控的链路,晚高峰的抖动通常比直连小。中转型线路之间的差异主要在中转节点的带宽与调度策略上,选的时候看的是运营方的容量,不是节点数量。

专线

专线指入口到落地之间走点到点的专有通道,不与公网流量共享拥塞。它的特征是延迟稳定、抖动小、丢包率低,代价是成本高,通常只放在热门落地上。对视频会议、实时协作、长时间稳定连接这类场景,专线的价值不在峰值带宽,而在于「晚高峰也不掉」。如果只是偶尔看视频,专线带来的提升不一定能被感知到。

选线的顺序建议是:先定落地地区(内容与服务在哪),再定线路类型(是否需要在晚高峰保持稳定),最后才是协议。反过来先挑协议,很容易在一条本来就拥塞的线路上反复换封装,花时间但没效果。线路页上每条线路带一个类型标签,标签描述的就是上面三类之一;看到「中转」不要理解成「多绕一圈所以更慢」,它优化的是去程那一段。

丢包与晚高峰拥塞的成因

丢包不是一种故障,而是一种常态。链路上任何一段的队列满了,后来的包就会被丢掉;无线环境里干扰也会造成丢包。问题不在于有没有丢包,而在于丢包发生在哪一段、持续多久、以及协议怎么应对。

常见的来源有四类。本地无线:Wi-Fi 干扰、距离远、信道拥挤,表现是所有线路都慢,换线路无效。家庭宽带上行:上传跑满时下行也会被影响,因为确认包发不出去,表现是下载时卡顿。国际链路峰值:晚间跨境方向流量集中,公共链路排队,表现是固定时段变慢、其他时段正常。落地机房出口:落地侧带宽被占满,表现是某一条线路慢,换同地区的其他线路正常。

TCP 对丢包的反应很剧烈:检测到丢包就把拥塞窗口减半,然后慢慢加回来。短连接受影响最大——一个网页的十几个请求都挤在一条连接上,一次丢包就让整条连接一起等重传。QUIC 把这个问题按流拆开:一条流丢包,其他流照常推进,所以 UDP 类协议在丢包环境下的体感通常更平滑。

晚高峰的形态不是「完全不能用」,而是延迟上升、抖动变大、视频自动降码率。这个时段最有效的做法是换线路类型(直连换中转或专线),而不是换协议。因为瓶颈在路径的拥塞,不在封装;换协议只是换了一种排队方式,队列本身没变短。

分层排查的顺序

从近到远:先看本地网关是否稳定,再看入口是否可达,最后看落地。三段里哪一段开始出现持续丢包,问题就在那一段之后。命令行的 mtr 能把每一跳的丢包列出来,连续跑几十次比跑一次有意义得多。

# 1. 先确认本地网关稳定(把示例地址换成自己路由器的地址)
ping -c 20 192.168.1.1

# 2. 再看跨境路径每一跳的丢包与延迟,连续采样 50 次
mtr -rwzc 50 example.com

# 3. 换一条线路重复上面两步,对比同一时段的差异

采样方法也要统一:同一时段、同一目标、至少三轮,每轮 50 次;记录平均值、最大值与丢包率。只看一次结果容易被瞬时抖动误导。也不要拿不同时段的两条线路直接对比——晚高峰与凌晨之间的差异,可能比两条线路之间的差异还大。

按使用场景选协议

前面几章拆开讲,这一章合起来用。选型的顺序是:场景 → 线路类型 → 协议 → 客户端设置。顺序颠倒会把简单问题复杂化,比如先认定要用某个协议,再去找一条能跑它的线路,最后发现线路本身在晚高峰就撑不住。

网页与办公

网页浏览的特征是短连接多:一个页面要开十几个连接,每个都要握手。这时候首包延迟比带宽重要,线路的往返时间比峰值速率重要。协议层面选头部开销小的(Trojan、VLESS),体感差异主要来自线路。如果办公系统里有大量小文件上传下载,再看一眼上行——上行拥塞会连带影响下行。

视频会议与实时语音

会议流量是双向的、持续的,对抖动比对带宽敏感。抖动大的时候声音会断续、画面会卡住再追上。UDP 类协议在丢包时的平滑性更好,配合专线或质量较好的中转线路,是这一类场景的首选。如果所在网络不放行 UDP,退回 TCP 类协议也能用,只是丢包时更容易出现整段卡顿。

AI 工具的长连接

这类工具多数用流式响应:一次请求保持几十秒到几分钟,中间持续返回数据。连接一断,回答就中断,重来一次的成本很高。所以稳定性优先于峰值速度:选 TCP 类协议、选中转线路,比选一个「测试数字更小」的 UDP 组合更实用。同理,这类场景不适合频繁切换节点。

大文件与备份

下载与备份看的是持续吞吐。协议头开销在这个场景里几乎可以忽略,决定速度的是线路带宽与两端 CPU。VLESS 因为把加密交给 TLS、协议层开销小,在高吞吐下更容易跑满。同时要看清流量口径:月订阅的流量按开通日每月重置,流量包用完为止、永久不过期,不固定时间的备份任务用流量包更合适。

常见误区有三条。第一,新协议不一定更快:协议只决定封装,瓶颈通常在路径。第二,一个数字不能代表全部:客户端延迟是到入口的探测值。第三,不同时段不可比:晚高峰与凌晨的差异可能大于两条线路之间的差异。把这三条记住,能省下大量反复试错的时间。

自查与验证:连上之后

连上不等于走对。出口在哪个国家、域名解析有没有走隧道、大包能不能通过,这三件事都要单独确认。它们对应三种完全不同的现象,混在一起排查会绕远路。

出口地址与归属地

最简单的验证是看出口地址。连上之后打开本站的网络检测页,页面会显示当前出口与归属地;断开再查一次,两次结果不同才说明流量确实走了线路。如果两次一样,说明客户端没有接管全局流量,或者当前应用命中了直连规则。这一步做完,再谈速度才有意义。

域名解析与分流规则

解析是否走在隧道里,决定了「解析结果」和「实际出口」是否一致。分流规则里如果只代理了部分域名,解析可能仍然走本地,表现为部分站点打不开、部分正常。排查方法很简单:临时切到全局模式再试,如果问题消失,就是分流规则的问题,回去检查规则列表即可,不必改协议。

MTU 与分片

UDP 类协议对 MTU 更敏感。典型表现是:网页能打开、聊天正常,但视频卡住、大文件传不动、某些应用一直转圈。原因是大包在路径上被丢弃,而小包正常。处理办法是在客户端里调低 MTU 或开启分片,具体项名各客户端不同,通常在协议设置里。调完要重新测一次大文件,别只看网页能不能开。

# 查当前出口地址(把示例域名换成任意回显地址的服务)
curl -s https://example.com/ip

# 看路径 MTU:先按 1500 试,失败再逐级下调
ping -c 3 -M do -s 1472 example.com

一份可以照着填的记录表

排查最怕的是凭印象。把下面几项记下来,连着记三天,问题基本就自己浮出来了。

排查顺序总结成一句:先确认出口对不对(是不是走了线路),再确认稳定性(同一时段多次采样),最后才调协议。顺序反了,会把线路问题当成协议问题,越调越乱。如果三条都不对,先回教程页按主线把导入流程重做一遍;仍然不对,带着记录表里的数据联系支持,比只说「连不上」有用得多。

术语速查与常见问题

这一章是给回头查阅用的。术语按出现频率排序,后面的问答覆盖最常被问到的五个问题,答案尽量给判断依据而不是结论。

RTT往返时间

一个包从发出去到收到回应的时间。多数交互式体验由它决定,而不是由带宽决定。

JITTER抖动

多次往返时间之间的波动幅度。会议与语音对抖动最敏感,对峰值带宽反而不敏感。

LOSS丢包率

一段时间内被丢弃的包占发出包的比例。短连接对丢包更敏感,因为一次丢包就要等一轮重传。

MUX多路复用

一条连接里并行跑多个请求。减少握手次数,代价是要维护更多连接状态。

0-RTT零往返恢复

会话恢复时省掉握手的往返,首个请求随恢复包一起发出。前提是之前建立过会话。

MTU最大传输单元

单次能传输的最大包大小。UDP 类协议对它有额外要求,配置不对会表现为大包传不动。

QUIC

基于 UDP 的传输协议,把传输握手与 TLS 合并,支持按流重传与连接迁移。

AEAD认证加密

带关联数据的认证加密,同时保证机密性与完整性,是现代协议的基本构件。

CC拥塞控制

发送端根据丢包与延迟调整发送速率的算法。TCP 与 QUIC 的实现策略不同,弱网表现也不同。

EDGE入口与落地

入口是用户连上的第一台服务器,落地是最终访问外部服务的出口。两者的距离决定了延迟的下限。

常见问题

相关页面:第一次配置看教程页;按地区与线路类型挑线路看线路页;套餐与流量包的具体价格看套餐页;想自己复现测速流程,可以看加速器速度实测方法;完全从零开始,看海外加速器新手完整指南。