线路与协议技术参考

01 · 分层

先把问题放回四层里

同样一句「线路不好用」,可能指向四个完全不同的位置。把它们分开,后面的判断才不会互相打架。本页是一份按选型顺序组织的技术参考:先看路径,再看协议,最后看设备和客户端。第一次使用建议先读教程页的主线步骤,把客户端装好、连上;遇到「为什么这样选」「为什么时快时慢」再回到这里查阅。

四层各自负责什么

物理与路由层决定数据从本地到出口经过哪些城市、哪些运营商、在哪个交换点互联。它决定延迟的下限,也决定晚高峰时哪一段最容易排队。换客户端、换协议都改不了这一层的路径。

传输层是 TCP 或 QUIC(UDP),以及它们背后的拥塞控制。它决定丢包之后怎么补、窗口怎么涨、多条请求怎么共享一条连接。体感上的「忽快忽慢」,很大一部分来自这一层。

代理协议层是 Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC 这些名字。它决定认证方式、外层是否套 TLS、是否多路复用、额外头部有多少。协议不改变物理路径,但会改变握手次数、重传策略和 CPU 开销。

客户端与设备层包括系统版本、权限、Wi-Fi 信号、路由器 NAT 表、省电策略、DNS 设置和 MTU。这一层最容易被忽略,因为换一台设备后,前面的配置看起来完全一样,表现却不同。

几个容易混淆的词

节点是一台可连接的服务器或入口;入口是客户端先连到的地址;出口是访问目标网站时对方看到的地址;落地是出口所在地区。线路是从入口到出口的路径组合,可能直连,也可能经过中转或专线。协议只描述客户端到入口这一段怎么通信,入口之后走什么路,由线路决定。

这张表只用于定位,不替代实际测试。每次只改一个变量,否则无法判断是哪一项起了作用。

02 · 协议

六种协议的设计取舍

协议不是品牌,也不是越新越好。它是一组关于认证、加密、传输与复用的约定。下面按设计取舍讲,不贴配置代码;具体客户端里的选项名称可能不同,但判断逻辑一致。

轻量转发型:Shadowsocks 与 VLESS

Shadowsocks 的核心是简单:用预共享密钥做 AEAD 加密,把 TCP 与 UDP 请求转发到出口。它没有内置的多路复用,也没有原生的 TLS 伪装,开销小、实现成熟,适合路由器、老设备或只需要稳定转发的场景。代价是外层特征不明显,需要额外的插件或中转来补足;UDP 转发是否可用,取决于服务端与客户端的具体实现。

VLESS 更像一个轻量的传输载体:本身不负责加密,把安全边界交给外层 TLS 或 REALITY;协议头小、状态少,配合 XTLS 一类流控可以减少重复加密。它的优势是高吞吐与低 CPU,适合长时间大流量;前提是外层配置正确。如果外层没有可靠的 TLS,VLESS 并不会自动提供加密。

TLS 伪装型:Trojan 与 VMess

Trojan 把认证放进 TLS 连接里,外部看起来就是一次普通的 HTTPS 访问。它的强度取决于证书、TLS 版本与服务器配置,而不是协议名字本身。适合有域名、有证书、需要与普通网站共用入口的场景;配置不当时,握手失败会比轻量协议更难排查。

VMess 使用用户 ID 与时间戳做认证,请求头里带较多字段,支持多路复用。它的兼容性好,旧客户端也能用;代价是头部开销与实现复杂度略高,对系统时间敏感。设备时间偏差较大时,可能出现「配置没错但就是连不上」的情况。

QUIC 型:Hysteria2 与 TUIC

Hysteria2 基于 QUIC(UDP),把拥塞控制做得更激进,在丢包较多、RTT 较高的链路上更容易把带宽跑起来。它支持连接迁移,手机从 Wi-Fi 切到蜂窝网络时,连接不必完全重建。代价是对 UDP 质量敏感:如果本地网络或运营商对 UDP 有限速或丢包,体验会明显下降;QUIC 在用户态处理,CPU 与电量开销通常高于轻量 TCP 协议。

TUIC 同样走 QUIC,强调 0-RTT、多路复用与连接迁移,适合频繁切换网络、需要快速恢复的场景。它相对较新,不同客户端的实现差异更大;遇到问题时,先确认客户端版本与 UDP 是否可达,再判断线路。

选择时的三个误区

只看协议名,不看外层。VLESS 没有 TLS 就没有加密;Trojan 的强度取决于证书与 TLS 配置;Shadowsocks 的插件决定了它在外网看起来像什么。协议名只是入口,安全边界在外层。

把多路复用当万能。多路复用减少握手,但一条 TCP 连接上的队头阻塞会影响所有流;QUIC 的多路复用没有 TCP 队头阻塞,却受 UDP 质量影响。交互式浏览与大文件下载,适合的连接策略并不相同。

忽略客户端实现。同一个协议在不同客户端上的拥塞控制、缓冲区、日志级别与电量策略都不同。遇到「同一线路,换客户端就正常」,问题往往在实现,不在协议本身。

03 · 握手

连接建立与首包时间

「打开网页要等几秒」和「下载大文件很慢」是两件事。前者多半卡在连接建立,后者才看吞吐。把首包时间拆开,能快速判断慢在哪一段。

一次访问要经过几次握手

客户端先做 DNS 解析,把域名换成 IP;然后与入口建立 TCP 连接,完成三次握手;如果外层是 TLS,再做 TLS 握手;接着是代理协议自己的认证与请求头;入口把请求转发到出口,出口再与目标网站做一次 DNS、TCP 与 TLS。用户看到的「首包」,是这些步骤叠加后的结果。

其中,本地 DNS 与到入口的 RTT 通常较短,入口到出口、出口到目标的路径更长。也就是说,首包慢不一定是你到入口慢,也可能是出口到目标那一段在排队。反过来,如果入口就在附近、出口也在目标附近,首包会明显更短。

连接复用与 0-RTT

浏览器和客户端都会复用连接:HTTP/2 在一条 TCP 上跑多条请求,HTTP/3 在一条 QUIC 连接上跑多条流,代理客户端也可能把多个请求复用到一条隧道。复用减少了握手次数,但把多个流绑在同一条连接上;一旦底层丢包,TCP 上的所有流都要等重传,QUIC 则只影响具体的那条流。

TLS 1.3 与 QUIC 支持会话恢复,第二次连接可以用 0-RTT 提前发送数据。它确实能减少一个往返,但不是无条件更快:服务端可能拒绝 0-RTT 数据,部分网络也会对重放保护更谨慎。把 0-RTT 当成「一定更快」,容易误判。

时间、DNS 与 MTU

时间同步影响 VMess 的时间戳认证,也影响 TLS 证书有效期判断。设备时间偏差较大时,表现为「配置正确但握手失败」。开启系统自动时间,是最省事的排查。

DNS 决定第一次解析要等多久,也决定解析到哪个入口。浏览器自己的 DoH 可能绕过系统 DNS,导致客户端与浏览器看到不同的地址;排查时先确认是谁在解析。

MTU 是封装后仍能通过的最大包长。代理会在原始数据外再加一层头部,如果路径 MTU 较小,大包可能被丢弃,表现为「小页面能开、大文件卡住」或「TLS 握手完成、数据不动」。这类问题常被误判成线路慢。

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

这条命令只测一个公开示例站,不包含任何账号信息。dns 是解析耗时,connect 是 TCP 握手,tls 是 TLS 握手,first 是首字节,total 是整体。多跑几次取中间值,比单次结果更有参考意义。

04 · 资源

资源占用与移动端电量

协议对比里常写「轻量」「高效」,但资源占用不是一个单一数字。它至少包括 CPU、内存、网络唤醒次数与电量策略。同一款协议,在桌面电脑和旧手机上的表现可能完全不同。

CPU 花在哪里

第一是加密。支持 AES 硬件指令的设备,跑 AES-GCM 的代价很低;没有硬件加速时,ChaCha20 一类流密码通常更省。第二是 TLS:握手、证书校验、记录层加解密都要算力。第三是 QUIC:它在用户态实现,包含拥塞控制、重传、流管理,CPU 开销通常高于内核里的 TCP。第四是多路复用与日志:连接越多、日志越详细,开销越大。

因此,「VLESS 比 Trojan 轻」只在特定外层与特定客户端上成立;「Hysteria2 在弱网更快」也不等于它在所有设备上都更省电。判断时要看完整链路,而不是只看协议名。

电量花在哪里

移动端电量主要不是被加密算力吃掉的,而是被无线模块的唤醒次数吃掉的。每一次心跳、每一次重连、每一次 DNS 查询,都会让蜂窝或 Wi-Fi 模块从低功耗状态醒来。心跳间隔太短,设备频繁醒来;间隔太长,又可能被 NAT 超时切断,下一次请求要重建连接。客户端的默认值通常是折中,不建议为了「保持在线」把心跳调到很激进。

网络切换也会耗电:手机从 Wi-Fi 走到蜂窝,再走回 Wi-Fi,TCP 连接可能中断,客户端要重连;QUIC 的连接迁移可以减少重建,但迁移本身也要处理加密状态与路径验证。省电策略、后台限制、低电量模式都会影响客户端能否在后台维持连接。

按设备与场景取舍

VPNVL 的月订阅不限台数,可以在多台设备上同时使用;但每台设备的电量与性能仍是独立问题,不能互相替代。

减少无谓消耗的几个习惯

第一,按需分流:只让需要的应用走代理,其余直连,减少不必要的加密与转发。第二,避免双重代理:代理套代理会让每个包多走一次加密与转发。第三,关闭详细日志:排错时再开,平时保持默认。第四,别把「始终开启」当成唯一目标:插电设备可以常开,电池设备更适合按需开启。第五,定期更新客户端:拥塞控制、重连策略与电量优化都在版本里迭代,但不要盲目追新,稳定版本优先。

05 · 拓扑

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

线路拓扑描述的是「从入口到出口怎么走」。它比协议名更直接地决定延迟、抖动与晚高峰表现。VPNVL 的节点页把线路标成直连、中转与 IEPL 专线三类,原因就在这里。

直连:路径最短,但依赖互联质量

直连是客户端直接连到出口节点,入口与出口是同一台服务器或同一个机房。它的优点是路径短、握手少、实现简单;缺点是中间段完全依赖本地运营商与目标机房之间的互联质量。互联好时,直连很干净;互联差或晚高峰排队时,直连也会抖。直连适合距离较近、目标网站与出口地区匹配的场景。

中转:多一跳,换更稳的中间段

中转是客户端先连到入口,入口再把流量转到中转节点,最后由中转节点到出口。它比直连多了一跳,理论上会增加一点延迟;但中转节点通常选在互联更好的位置,可以把「本地运营商到国际段」这一段换成质量更可控的路径。中转的价值不在最短,而在稳定:当直连在晚高峰抖动时,中转往往更平顺。

中转也有前提:入口要离用户近,中转段要有足够带宽,出口要符合目标网站的要求。任何一段拥塞,都会把优势抵消。所以「中转」不是一个固定品质,而是一套路径设计。

专线:固定通道,稳定优先

IEPL 专线是在入口与出口之间走一条相对固定的通道,不与其他普通流量争抢同一段公共互联。它的优势是抖动小、晚高峰更稳,适合长时间会议、跨境办公、对断线敏感的业务。代价是成本更高,而且它只覆盖「入口到出口」这一段:用户家里的 Wi-Fi、本地运营商、目标网站都不在专线范围内。

因此,专线不是魔法。如果本地宽带已经拥塞,或者 Wi-Fi 信号很差,专线也救不了最后一段。正确的预期是:专线把中间段的不可控性降下来,把问题收敛到本地与目标两侧,便于排查。

为什么同一线路在不同城市表现不同

因为「最后一公里」不同。不同运营商、不同小区、不同接入方式,到同一个入口的路径与互联质量都不同;同一座城市里,光纤与移动网络的表现也可能相反。节点页给出的是线路类型与覆盖地区,不是每个用户家里的保证值。选线时,先看入口是否离自己近,再看中间段是否稳,最后看出口是否符合目标网站的地区要求。

06 · 拥塞

丢包与晚高峰拥塞

延迟、抖动、丢包、吞吐是四个不同指标。延迟是数据走一趟要多久;抖动是延迟的波动;丢包是包没有到达;吞吐是单位时间能送多少。晚高峰最常见的不是「服务器坏了」,而是某一段链路排队,导致延迟上升、丢包增加、吞吐下降。

丢包为什么会拖慢一切

TCP 把丢包当成拥塞信号:一旦检测到丢包,就减小拥塞窗口,降低发送速度,然后慢慢再涨回去。链路 RTT 越长,恢复越慢;丢包越频繁,窗口越难涨起来。QUIC 也会重传,但它把每条流分开处理,一条流丢包不会让所有流一起等;不过在 UDP 被限速或丢包严重的网络里,QUIC 的优势也会被抵消。

所以,「1% 丢包」对不同业务的影响完全不同:实时语音可能只是偶尔卡顿,大文件下载却可能明显掉速,交互式网页则表现为「点一下等半天」。不要用一个 ping 结果概括全部体验。

晚高峰的常见成因

第一,国际段拥塞:晚高峰跨境流量集中,公共互联排队,延迟与丢包一起上升。第二,家庭上行被占满:家人看视频、上传备份、下载更新,都会让路由器队列变长。第三,Wi-Fi 干扰:邻居信道重叠、距离远、墙体阻挡,表现为丢包与抖动。第四,路由器 NAT 表或会话数吃紧:老设备在大量连接下会变慢。第五,MTU 不匹配:大包被丢,小包正常。第六,UDP 被限速:QUIC 类协议在部分网络里反而不如 TCP。

还有一种常被忽略的情况是缓冲区膨胀:路由器的缓冲区很大,排队时延迟升高,但包没有丢,测速看起来还行,体感却很卡。这类问题要靠路由器上的队列管理或限速来缓解,换协议帮助有限。

怎么判断是不是晚高峰拥塞

先记录时间:只在 19:00 到 23:00 变差,白天正常,更像共享链路拥塞;全天都差,更像本地网络、入口选择或设备问题。再换变量:同一时间换一条线路类型,如果中转或专线明显更稳,说明问题在中间段;如果所有线路都一样,优先查本地。然后换介质:有线对比 Wi-Fi,排除无线干扰。最后换协议:TCP 与 QUIC 各试一次,判断是不是 UDP 被限速。

排查时可以用系统自带的网络诊断、路由追踪工具观察路径是否变化,但不要把单次 ICMP 延迟当成结论:ICMP 可能被限速或走不同队列,只能作为参考。更重要的是「同一时间段、同一目标、不同线路」的对比。需要确认当前出口地址,可以用网络检测页查看。

07 · 选型

按场景选协议与线路

没有一套配置适合所有场景。选型顺序建议是:先定线路,再定协议,最后调客户端。线路决定路径与稳定性,协议决定握手、开销与弱网表现,客户端决定这些能力能不能发挥出来。

AI 工具与长连接

ChatGPT、Claude、Gemini 这类工具的共同点是「长时间保持一条连接,然后持续接收流式响应」。它们对首包不算极端敏感,但对中途断线、重新认证很敏感。选型时优先稳定:中转或专线 + Trojan/VLESS over TLS,减少连接重建;不要在对话中途频繁切换节点。出口地区要符合服务要求,否则可能遇到地区限制。更多细节可以看ChatGPT 用 VPN 推荐这篇。

流媒体与 4K

流媒体看的是持续吞吐与出口 IP 的信誉。直连或中转都可以,关键是出口地区与目标平台匹配,且线路在晚高峰有足够余量。Hysteria2 在丢包较多的链路上可能更稳,但如果平台对 UDP 或机房 IP 有限制,换回 TCP 类协议更省事。VPNVL 的解锁支持页按平台列出了可用地区,选之前先对照。

跨境办公与会议

会议对抖动最敏感,对绝对延迟反而没那么敏感。IEPL 专线的价值在这里最明显:固定通道减少排队,长时间连接不容易断。协议选 TCP 类的 Trojan 或 VLESS,配合客户端的分流,把内网与本地服务排除在代理之外,减少不必要的转发。出差场景可以看出差 VPN 推荐里的用量估算与核对清单。

移动端与游戏

手机经常在 Wi-Fi 与蜂窝之间切换,支持连接迁移的 QUIC 协议更省心;但如果不确定 UDP 是否被限速,先准备一套 TCP 备用。游戏看延迟与抖动,选离自己近的入口、出口与游戏服务器同区,优先有线或 5GHz Wi-Fi;不要在后台同时跑下载。

预算与套餐怎么配合

选型不只发生在客户端里,也发生在购买时。VPNVL 的月订阅按开通日每月重置流量:¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB;流量包是用完为止、永久不过期,¥158/300GB、¥358/1000GB、¥658/3000GB。用量稳定就选月订阅,用量忽高忽低或想留余量就配流量包。预算有限时,可以先看十元档位能买到什么,再决定组合方式。

什么时候该换服务商

如果所有线路、所有协议、所有设备在同一时间都不可用,先查本地网络与账号状态;如果只有某一条线路长期不稳,换线路;如果只有某一个协议在特定网络下不行,换协议;如果所有线路在晚高峰都长期拥塞,而其他时间段正常,才需要考虑服务商的容量。把「换服务商」当成第一反应,通常会错过更简单的修复。

08 · 排查

分层排查流程

排查的目标不是「把所有设置都试一遍」,而是用最少的变量定位问题。下面五步按顺序走,每一步都留下记录;如果五步之后仍未解决,带着记录联系支持,比一句「连不上」有效得多。

1. 界定范围。是单设备还是所有设备?是单个网站还是所有网站?是全天还是晚高峰?把这三个问题答完,问题已经缩小一半。
2. 检查本地。有线与 Wi-Fi 各试一次;确认系统时间自动同步;确认没有同时开两个代理;确认 DNS 没有被浏览器或安全软件改写;确认路由器没有跑满上传。
3. 只换一个变量。先换线路,再换协议,再换设备。每换一次,记录结果。不要同时改线路、协议和 DNS,否则无法判断哪一项起了作用。
4. 看日志。客户端日志里的握手失败、DNS 超时、TLS 错误、连接重置,比「打不开」更有信息量。截图或复制日志前,先遮掉订阅地址与令牌。
5. 带信息求助。时间、设备与系统、线路名称、协议、错误提示、已经尝试过的步骤。信息越具体,定位越快。

常见现象与处理

连上但打不开网页。先看 DNS:浏览器自己的 DoH 可能绕过客户端;再看系统代理是否只开了一半;最后看 MTU,尤其是小页面能开、大页面卡住的情况。

只有某个应用不行。检查分流规则是否把这个应用排除了;有些应用使用证书固定,不接受代理证书;有些应用只走 UDP,而当前线路的 UDP 不可用。

频繁断线。手机省电策略、Wi-Fi 漫游、NAT 超时、心跳间隔都可能是原因。先关掉省电限制,再换网络对比;如果只在移动网络断,优先考虑连接迁移能力更强的协议。

速度慢。先分清首包慢还是吞吐低;再看设备 CPU 是否跑满;再看 Wi-Fi 信号与路由器;最后换线路类型。不要只盯着协议名。

安全与隐私边界

排查时不要把订阅地址、令牌、完整日志原样发到公开群组或截图里。VPNVL 不记录日志,但订阅地址本身就是访问凭据;把它当作密码看待。需要协助时,只提供线路名称、协议、错误类型与时间,不提供凭据。

常见问题