协议与线路选型参考

六种协议的设计取舍

代理协议要解决的问题可以拆成三件:把流量封装进一条能够通行的连接、在两端之间完成加密与完整性校验、让链路上的中间设备无法从字节层面判断内容。六种主流协议在这三件事上的取舍各不相同,取舍的结果直接体现在握手轮次、CPU 占用、抗丢包能力和移动端电量上。本章按设计取向逐个说明,不做排名,因为脱离链路谈优劣没有意义。

Shadowsocks:最薄的一层封装

Shadowsocks 的设计目标很克制:用一条加密的 TCP 或 UDP 连接把流量送到出口,不额外叠加伪装层。加密使用 AEAD 套件,常见的是 AES-128-GCM、AES-256-GCM 与 ChaCha20-Poly1305,这类模式把加密与完整性校验合并成一步,省掉了先加密再单独计算校验的往返。因为没有内置 TLS,它的握手成本在六种协议里属于最低的一档,对延迟敏感的场景能直接受益。代价是流量特征完全取决于外层怎么包装:裸跑时它就是一段高熵字节的 TCP 流,链路上任何做深度包检测的设备都可能对它产生兴趣。实际部署里通常会把 Shadowsocks 放进 TLS 隧道,或者与其它传输层组合使用。

VMess:带身份与时间校验的封装

VMess 在协议头部携带用户标识与时间戳,服务端用这两项做身份校验。这也带来一个容易踩的坑:客户端与节点的时间必须大致同步,偏差过大时握手会被直接拒绝,表现是配置逐项核对都对、就是连不上。VMess 的头部经历过多个版本,AEAD 版本把头部也纳入完整性保护,避免头部字段被中途篡改。它的开销略高于 Shadowsocks,换来的是更明确的多用户模型与更细的头部字段,适合在一个节点上区分多个订阅者。

Trojan:把流量放进标准 TLS

Trojan 的思路是把代理流量放进一条标准 TLS 连接:先完成一次看起来完全正常的 TLS 握手,服务端在握手完成后才校验密码。对链路上的中间设备来说,它看到的是一次普通的 HTTPS 会话,目标域名、证书链、握手顺序都与常规访问一致。密码不匹配时,服务端可以把这条连接转发给一个真实的 Web 服务,让探测方拿到一份正常的网页响应。兼容性好是它的优势,代价是多了一层 TLS,握手多一个往返,CPU 也要多做一次对称加解密。

VLESS:去掉重复的一层

VLESS 的取向是只做该做的事:协议本身不加密,把加密完全交给外层 TLS,从而避免在 TLS 里再套一层加密的重复开销。配合 XTLS 系列的流控,内层与外层的加密可以不再重复执行,CPU 占用明显下降。VLESS 是无状态的,服务端不需要为每个用户维护会话表,节点横向扩容更容易。它适合已经有稳定 TLS 通道、又希望把吞吐与 CPU 效率拉满的场景;反过来说,如果外层 TLS 配置不当,VLESS 本身没有额外的兜底加密。

Hysteria2:在 QUIC 上换一种拥塞控制

Hysteria2 跑在 QUIC 之上,也就是走 UDP。它最实际的差异在拥塞控制:可以选用 BBR 一类的算法,在丢包率较高的链路上仍然维持较高吞吐,而不是像传统 TCP 拥塞控制那样一遇丢包就大幅缩小窗口。代价同样明确:UDP 流量在部分网络里会被限速或降级处理;QUIC 在用户态实现,每个数据包都要经过一次用户态拷贝与定时器处理,CPU 占用高于内核 TCP;移动端长时间使用,电量消耗也会更高。

TUIC:QUIC 上的多路复用与 0-RTT

TUIC 同样基于 QUIC,重点放在多路复用与快速恢复:一条 QUIC 连接上可以并行承载多条逻辑流,已经建立过会话的客户端再次连接时可以走 0-RTT,省掉一个往返。它的取舍与 Hysteria2 接近,即 UDP 链路是否可用直接决定体验上限。在 UDP 通畅的网络里,TUIC 的首包时间表现很亮眼;在 UDP 被限速的网络里,它反而不如一条稳定的 TCP 线路。

结论很朴素:链路质量好、追求低开销,Shadowsocks 与 VLESS 更合适;需要兼容性与伪装, Trojan 更稳;链路丢包严重,Hysteria2 与 TUIC 的拥塞控制能救回吞吐;移动端长时间挂机,内核态的 TCP 系协议在电量上更友好。VPNLW 的 230+ 线路按地区标注了可用协议,导入订阅后客户端会按线路下发对应的协议组合,不需要手工拼装配置。

从点击到首包:握手都发生了什么

用户感知到的快慢由两个不同的量决定:首包时间,也就是点开一个链接到收到第一个字节的间隔;以及持续吞吐,也就是开始传输之后的速度。首包时间由往返次数决定,吞吐由带宽与拥塞控制决定。两者经常被混为一谈,排错时也就容易走错方向——明明只是握手慢,却一直在换大带宽线路。

一次请求经过了几次往返

把一次网页请求拆开,大致经过下面几步。第一步是名称解析,如果本地缓存里没有记录,需要一次或多次往返去问 DNS;在代理模式下,解析可能交给远端完成,本地到节点这一段就多了一次协商。第二步是到节点的传输握手,TCP 需要一个往返。第三步是 TLS 握手,TLS 1.3 在完整握手时是一个往返,会话恢复时可以做到 0-RTT。第四步是代理协议自身的协商:VLESS 与 Trojan 基本没有额外往返,VMess 需要校验标识与时间,QUIC 系协议是一个往返或 0-RTT。第五步是节点到目标站点,这一段取决于落地机房到目标的物理距离与路由质量。第六步才是数据回传。

把这几段加起来就能解释一个常见现象:第一次打开某个网站明显慢,第二次就快了。原因不是线路变好了,而是连接池与 TLS 会话票据被复用,后面几次省掉了握手。

0-RTT 省下的是什么,代价在哪里

TLS 1.3 的会话恢复允许客户端在第一个飞行包里就带上应用数据,这就是 0-RTT。QUIC 沿用了这套机制。省下的是一个完整往返,在跨洋链路上相当于把首包时间砍掉一截。代价是重放风险:链路上的攻击者可以截获并重放这段 0-RTT 数据,所以协议规范建议只对幂等请求使用。客户端是否真的启用 0-RTT,取决于实现与本地缓存状态,不能把它当成必然发生的事。在排查"为什么有时快有时慢"时,这一条值得记住。

连接复用与队头阻塞

多路复用把多条请求塞进一条连接,省掉重复握手。在 TCP 上,一条连接内的数据严格有序,前面一个包丢了,后面所有流都要等它重传,这就是队头阻塞。QUIC 在传输层就把流拆开,一条流丢包不影响其它流,代价是每条流都要单独维护状态,内存与调度开销更高。选择是否开启多路复用要看场景:请求密集、连接数受限时,复用的收益明显;单条大流量传输时,不开复用反而更稳,因为不必和别的流抢同一个窗口。

怎么自己量首包时间

浏览器开发者工具的网络面板能直接看到每个请求的排队、DNS、连接、TLS 与首字节各阶段耗时。命令行可以用 curl 的分阶段计时:

curl -o /dev/null -s -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer}\n' https://example.com/

把这条命令在连接建立前后各跑一次,差值就是握手成本。示例域名只用于演示写法,不要把真实的订阅地址贴进任何在线工具或公开截图。

理解这张表之后,很多"线路慢"的判断会变得精确:如果只有第一次慢,问题在握手与解析;如果每次打开都慢,问题在往返次数;如果首包快但传输慢,问题在带宽与拥塞控制。三种情况的处理方式完全不同。

CPU、内存与移动端电量

协议选型在桌面端主要影响速度,在移动端还会影响续航。电量不是一个抽象指标,它由 CPU 唤醒次数、射频模块工作时间、内存分配与回收频率共同决定。同一份订阅,在笔记本上差别看不出来,在手机上可能是一小时与三小时的差别。

加密套件的硬件加速

AES-GCM 在支持 AES-NI 的 x86 处理器与带 ARMv8 加密扩展的移动芯片上是硬件指令,单字节成本极低。ChaCha20-Poly1305 是纯软件实现更快的方案,在没有硬件加速的老设备上反而占优。多数客户端会根据 CPU 能力自动选择,少数需要手动指定。把一台老安卓设备的加密套件从 AES 改成 ChaCha20,有时能明显降低发热与掉电速度,这是一个成本很低但常被忽略的调整。

用户态与内核态的差别

TCP 由操作系统内核处理,数据包从网卡到应用只经过必要的拷贝。QUIC 在用户态实现,每个包都要经过一次系统调用、一次用户态拷贝、一次定时器检查。桌面处理器上这点开销可以忽略,移动处理器上它会直接转化成电量与发热。这也是为什么 Hysteria2 与 TUIC 在手机上长时间使用时,续航表现通常不如 TCP 系协议。不是说 QUIC 系协议不好,而是它的优势在丢包链路上,代价在电量上,需要按场景权衡。

心跳与保活

NAT 设备会回收空闲映射,客户端因此需要周期性发送心跳来维持通道。心跳间隔越短,断线概率越低,但射频模块被唤醒的次数也越多。移动端的合理做法是把心跳间隔调长,配合系统级的网络保活;桌面端则可以保持较短间隔,换取更快的恢复速度。如果发现"锁屏一会儿回来就要重连",先看心跳间隔,而不是急着换节点。

后台保活与省电策略

iOS 对后台网络权限限制严格,应用进入后台一段时间后会被挂起,代理随之断开。Android 的省电策略会限制后台应用的网络访问,常见表现是锁屏几分钟后消息收不到。解决办法是把客户端加入系统的省电白名单,并允许其后台运行。这一步不是可选项,而是移动端长期使用的前提。具体操作步骤在安卓相关的教程文章里有逐屏说明。

分应用代理是最直接的电量优化

只让需要的应用走代理,能同时减少三件事:总流量、加解密次数、射频模块的工作时间。系统更新、应用商店下载、局域网备份这类流量完全没必要经过境外节点。多数客户端支持按应用勾选,配置一次即可长期生效。对于流量额度有限的套餐,这一项还能顺带省下可观的流量。

把这几项调好之后,移动端的体验改善往往比换一条线路更明显。线路决定上限,配置决定实际消耗。

直连、中转与专线

一条线路可以拆成三段:用户到入口的接入段、入口到落地的跨境段、落地到目标的落地段。三段里只有跨境段是服务商能主动优化的部分,线路类型的差别也主要落在这一段。理解这一点,就能理解为什么同一个城市的两条线路延迟差不多,晚高峰表现却完全不同。

直连:路径最短,质量最不可控

直连指节点机房直接位于境外,用户流量经国际出口直达机房。优点是路径短、没有额外跳数,链路质量好的时候延迟最低。缺点同样明显:跨境段与所有使用同一出口的用户共享,晚高峰的拥塞无法回避。直连线路适合作为备用,或者在对延迟极敏感、且能接受波动的场景里使用。把直连当成唯一选择,等于把体验押在别人家的出口带宽上。

中转:把不可控的一段换成可控的一段

中转在离用户更近的位置设入口,例如香港或日本,用户先连到入口,再由入口沿优化过的路径转发到落地。中转的价值不在于缩短物理距离,而在于把与所有人一起挤国际出口的情形,换成走一条经过调度的骨干路径。入口节点还能做统一调度:某条落地线路拥塞时,把流量切到另一条。代价是多了一跳,基础延迟会比直连略高,但抖动通常更小,晚高峰的落差也更平缓。

专线:用成本换确定性

IEPL 一类的专线由运营商提供,带宽与路径有明确的服务等级约定,不与公网流量抢同一队列。它的表现是延迟稳定、丢包低、晚高峰不明显。成本是三者里最高的,所以通常只在部分线路上提供。判断一条线路是不是专线,可以看命名标注,也可以用路由追踪观察跨境段的跳数与经过的网络。跳数少、路径稳定、跨境段集中在少数几个网络里,通常是优化过的路径。

延迟与抖动是两个不同的指标

平均延迟低不代表体验好。视频会议怕的是抖动,也就是延迟的波动;大文件传输怕的是丢包,因为丢包会触发拥塞控制降窗。专线在这两个指标上的优势,比它在平均延迟上的优势更明显。很多用户反馈"换了专线之后数值没降多少,但会议不卡了",说的就是抖动。

选择建议很直接:日常浏览与视频用中转即可;会议、实时协作、对断流零容忍的场景用专线;直连留给备用与轻量场景。VPNLW 的线路清单按地区标注了线路类型,可以在节点页按地区筛选后逐条对照。

延迟、丢包与晚高峰

这一章解释三件出现频率最高的事:为什么延迟会变高、为什么会丢包、为什么晚上特别慢。理解成因之后,大部分"是不是线路坏了"的疑问可以自己判断,不必每次都提交工单。

延迟由四部分组成

第一是传播延迟,信号在介质中传播的时间,由物理距离决定,无法优化。第二是传输延迟,把数据推上链路的时间,由带宽与包大小决定。第三是排队延迟,数据在路由器队列里等待的时间,拥塞时会急剧上升。第四是处理延迟,设备转发、加解密、协议栈处理的时间。四者里只有排队延迟与处理延迟有优化空间。物理距离决定的下限无法突破,这也是为什么绕路有时反而更快:绕开拥塞节点的路径,总时间可能短于直线路径。

丢包从哪里来

丢包的常见来源有四类。一是队列溢出,链路上某一跳的缓冲被占满,后来的包直接被丢弃。二是无线干扰,Wi-Fi 与移动网络在高干扰环境下会出现随机丢包。三是设备限速与策略,部分网络会对特定类型的流量做限速,超出部分被丢弃。四是 MTU 不匹配,包在转发时被分片,分片丢失会导致整包重传。四类来源的处理方式不同:队列溢出要换线路,无线干扰要换接入方式,限速要换端口或协议,MTU 问题要调整客户端的 MTU 设置。

拥塞控制决定了丢包的代价

传统 TCP 拥塞控制把丢包当作拥塞信号,一旦检测到丢包就大幅缩小拥塞窗口,吞吐随之塌陷。BBR 换了一个思路:持续估计链路的带宽与最小往返时间,按估计值发送,丢包不再必然导致降速。这就是 Hysteria2 在丢包链路上表现更好的根本原因。不是它更快,而是它对丢包的反应不同。理解了这一点,就不会再纠结"为什么同一个节点,换协议之后速度差这么多"。

晚高峰为什么慢

国际出口的带宽是共享资源。晚间是使用高峰,出口链路被占满,队列变长,排队延迟上升,队列溢出后开始丢包。表现是延迟从平时的水平抬升、丢包率上升、吞吐下降,而且同一时段内波动很大。专线与优化中转的价值在这个时段最明显:它们不与该出口的公网流量抢同一队列。如果只在晚上慢、白天正常,基本可以判定是共享出口的拥塞,而不是本地网络或客户端的问题。

自测的局限

ping 用的是 ICMP,和 TCP 走的不一定是同一条队列,ping 值低不代表代理快。测速工具测的是瞬时吞吐,连续采样才能看出稳定性。合理的观察方法是同一时段多次采样,看抖动与丢包率,而不是盯住单次峰值。测速节点本身的带宽也可能是瓶颈,选一个离落地位置更近的测速目标,结果才有参考价值。

把这五种情况记住,大多数问题在提交工单之前就能定位到具体一层。

按场景选协议

选型有一个固定的决策顺序:先看线路,再看协议,最后调客户端参数。线路决定物理上限,协议决定在同一条线路上的效率,客户端参数决定细节体验。顺序反了,就会陷入反复换协议却不见改善的循环——因为瓶颈根本不在协议上。

决策顺序

第一步问场景是否对抖动敏感:会议、实时协作、游戏属于这一类,优先专线。第二步看链路的丢包情况:如果长期存在随机丢包,QUIC 系协议的拥塞控制能救回吞吐。第三步看设备类型与电量约束:手机长时间挂机优先 TCP 系。第四步看是否需要 UDP 转发:部分应用依赖 UDP,需要客户端与线路同时支持。

4K 流媒体

4K 串流对持续带宽的要求明显高于 1080p,码率通常在两位数 Mbps,而且要求稳定——缓冲区一旦被抽干就会转圈。选型的重点是持续吞吐与线路稳定性,而不是峰值。TCP 系协议配合中转或专线线路,通常比在 UDP 上追求峰值更稳。如果所在网络对 UDP 限速,QUIC 系协议反而会拖后腿。区域片库与出口地区的关系,在流媒体专题文章里有更具体的对照。

视频会议

会议对延迟与抖动敏感,对带宽要求不高。首选专线或优化中转,协议用 TCP 系即可。会议期间不要切换节点,切换会造成几秒的中断,而在会议里几秒足以打断一段发言。如果会议软件本身走 UDP,需要确认客户端没有把 UDP 流量丢弃,否则会出现能听到声音、看不到共享屏幕的情况。

大文件与备份

高带宽、高延迟的链路上,拥塞控制的影响被放大。BBR 一类的算法能把管道填满,Hysteria2 在这类场景里优势明显。需要注意的是流量消耗:一次完整备份可能用掉大半个月的套餐额度,流量包更适合这种突发用量,用完为止、永久不过期,不必为了一个月的峰值去升级月订阅。

移动端长时间挂机

电量优先。选 TCP 系协议,心跳间隔调长,开启分应用代理。不要在手机上长时间跑 QUIC 系协议做大流量下载,发热与耗电都会明显上升。如果只是收消息、看网页,这类轻量使用对协议几乎无感,选最省电的组合即可。

AI 工具与长连接

AI 工具的响应是流式的,一次对话可能维持几十秒的长连接。这类场景对带宽要求不高,对稳定性要求高——连接中断会让整段回答作废。选稳定线路加 TCP 系协议,比追求低延迟更实际。如果经常遇到回答中途停止,先排查线路抖动,而不是换协议。相关的排查思路在帮助中心有更细的条目。

实时对战游戏

物理距离是硬约束,协议能做的优化有限。需要 UDP 转发,并且线路的抖动要小。跨洲对战的延迟下限由光速决定,任何协议都无法突破。把预期放对位置,比反复换节点更有用。

套餐与场景的匹配也值得说一句:月订阅 ¥9.9 含 60GB,适合轻量浏览与消息类使用;¥18 含 250GB,覆盖日常流媒体与办公;¥28 含 500GB,适合重度观看与多设备同时使用。流量按开通日每月重置,中途升级差价折算成剩余天数。突发的大用量用流量包更划算,¥158 对应 300GB、¥358 对应 1000GB、¥658 对应 3000GB,用完为止、永久不过期。

平台支持与订阅导入

协议与线路选定之后,最后一公里在客户端。同一份订阅在不同平台上的表现可能不一样,差别主要来自内核对协议的支持范围、后台保活策略,以及代理的接管方式。理解这三处差异,能省掉大量"同一个节点在电脑上好好的、在手机上不行"的困惑。

五个平台的差异

Windows 有系统代理与 TUN 两种模式,系统代理只对遵守系统设置的应用生效,TUN 则能接管不遵守系统代理的程序。macOS 的权限模型更严格,首次启用 TUN 需要授权并安装网络扩展。iOS 的后台限制最严,需要按指引添加配置,分应用代理的能力有限。Android 支持分应用代理,但省电策略需要手动放行。Linux 既有命令行客户端也有图形客户端,适合把代理做在路由层,让整个局域网共用一条出口。

订阅导入的四步

第一步,登录用户面板,进入订阅页。第二步,复制订阅链接。第三步,在客户端选择从剪贴板导入,或直接粘贴链接。第四步,首次导入后手动更新一次,确认节点列表刷新。四步都完成后,选一条线路连接,再用任意一个查询出口地址的页面确认出口地区与所选线路一致。

https://example.com/sub?token=YOUR_TOKEN

上面是格式示意,真实链接在登录后的面板里获取。订阅链接等同于凭据,拿到它的人可以使用你的流量额度,不要贴到公开论坛或截图里。如果怀疑链接外泄,在面板里重置订阅即可让旧链接失效。

更新订阅的时机

节点调整、协议变更、套餐续费之后,都需要在客户端手动更新一次订阅。部分客户端支持定时自动更新,间隔建议设在数小时级别,过于频繁的拉取没有意义,也会让节点列表在切换时短暂不可用。

不限台数与带宽分摊

VPNLW 的订阅不限台数,同一账号可以在 Windows、macOS、iOS、Android、Linux 上同时使用。需要注意的是一条线路的带宽是共享的,同一时间多台设备跑大流量,单台设备的可用带宽会下降。家庭场景下把下载任务安排在非高峰时段,体验会更好。这也是为什么"设备数不限"与"带宽无限"是两件事,前者是授权,后者是物理资源。

客户端的获取入口在用户面板内,登录后按平台下载即可。订阅与客户端都放在面板里,不在营销页提供静态安装包,这样版本与账号状态能保持一致。

分层排错与验证

排错最忌一上来就换节点。连接是分层建立的,任何一层出问题表现都像连不上,逐层排除比反复试错快得多。本章给出一套可以照着做的流程,以及每一步的验证命令。

六层模型

第一层是接入层:设备是否联网、Wi-Fi 是否正常、是否被强制门户拦截。第二层是名称解析:域名能否解析到正确地址,是否被本地 DNS 劫持。第三层是传输握手:能否与节点建立 TCP 或 UDP 连接。第四层是协议协商:身份校验是否通过,时间是否同步。第五层是分流规则:这条流量是否被规则放行。第六层是应用层:目标服务本身是否可用。

每层怎么验证

接入层用 ping 网关确认本地链路。名称解析用 nslookup 指定一个公共解析器对照。传输握手用 curl 的详细输出看连接是否建立、TLS 是否完成。协议协商看客户端日志里的握手结果,失败通常会有明确的错误码。分流规则用全局模式对照。应用层换一个目标站点对照,排除目标服务自身故障。

ping -c 4 192.168.1.1
nslookup example.com 1.1.1.1
curl -v --max-time 10 https://example.com/
traceroute example.com

这四条命令覆盖了前三层。示例地址是通用写法,把网关换成自己网络的实际地址即可。

分流规则导致的假故障

规则模式下,部分域名走直连、部分走代理。如果某个应用打不开而其它应用正常,先切到全局模式对照:全局正常说明是规则问题,全局同样异常说明是线路或协议问题。这个对照能把排查范围一次缩小一半,是最省时间的一步。规则问题通常来自自定义规则写错、域名后缀匹配过宽,或者规则集没有更新。

时间同步为什么重要

VMess 一类的协议会用时间戳做校验,系统时间偏差过大时握手会被拒绝。表现是配置没错、节点在线、就是连不上。检查一下设备的自动时间同步是否开启,长时间休眠的笔记本与老设备最容易出现这个问题。

什么时候需要提交工单

逐层验证之后仍然无法定位,再提交工单。工单里写清:平台与客户端、使用的线路、出现问题的时间段、已经做过的验证步骤与结果。信息完整的工单处理速度明显更快,因为不需要来回确认基础信息。如果问题只在特定时段出现,标注具体时间点,便于对照线路侧的记录。

术语与参数速查

这一章把前面用到的术语集中列出,并附上服务本身的参数,方便查阅。术语按拼音与字母混排,不做严格分类。

术语表

套餐与流量包

服务参数

覆盖:120+ 国家 / 230+ 线路。设备:不限台数。支持平台:Windows / macOS / iOS / Android / Linux。支付方式:支付宝 / 微信 / USDT。退款:7 天无理由退款。注册:无需邮箱地址,用户名加密码即可注册。加密采用军工级加密。

继续阅读

想按步骤完成第一次配置,看快速上手教程;想比较档位与流量包,看套餐与价格;想按地区挑线路,看全球线路清单;常见问题集中在帮助中心。三篇延伸文章可以接着读:新手名词速查、区域片库与 4K 带宽实测对比、安卓后台保活与分应用代理。