协议与线路技术参考

选型导读

本页是 NZVPN 的协议与线路技术参考,面向正在选择订阅方案、或已经订阅但想了解背后原理的用户。相比教程页 setup.html 的"跟着做就能完成"主线,本页更偏向系统查阅:每章可以独立阅读,也可以按目录跳转到关心的议题。

在开始之前,先明确两个基本维度。协议(Protocol)决定了数据如何被封装、加密和传输;线路拓扑(Topology)决定了数据物理上走哪条路径。两者共同决定了连接的建立速度、传输速率、稳定性和移动端电量消耗。很多用户遇到"连不上""速度慢""看 4K 卡顿"的问题,根源往往不在服务本身,而在协议与线路的搭配没有针对当前网络环境做优化。

协议层解决的是"数据以什么形式过网"的问题。传统 TCP 代理在弱网下容易因为握手重传而拖慢速度,而基于 UDP 的协议则能在高丢包环境里保持更平稳的传输。线路层解决的是"数据走哪条路"的问题。同样一个新加坡节点,走直连、中转还是 IEPL 专线,延迟与稳定性可能相差数倍。理解这两层,才能在看线路列表时做出有效判断。

NZVPN 的订阅服务覆盖 120+ 国家 / 220+ 线路,支持 Windows、macOS、iOS、Android、Linux 五大平台,不限设备台数。订阅采用月付 ¥9.9 起(60GB 流量)的三档方案,另有永久不过期的流量包可选,并提供 30 天无理由退款。本文所有关于本服务的描述均与上述事实一致,不引入任何未经证实的数据。

需要说明的是,本页不讨论任何网络管制话题,也不提供具体的节点配置命令。协议与线路是服务商在后台已经配置好的基础设施,用户侧能做的选择集中在订阅套餐与客户端设置上。但了解原理有助于判断:为什么某些协议在某些网络环境下更快,为什么专线线路值得更高的月费,以及当连接出现问题时应该检查哪个环节。

本页按"协议 → 对比 → 拓扑 → 场景"的顺序组织。前五章逐一介绍六种协议,第六章给出横向对比表,第七章讨论线路拓扑,第八章解释丢包与拥塞的成因,第九章按使用场景给出选型建议。你可以从头读到尾,也可以直接跳到最关心的章节。

Shadowsocks:轻量代理协议的取舍

Shadowsocks(简称 SS)是当前使用最广泛的轻量代理协议之一。它的设计目标非常明确:在不可靠的网络环境下,以尽可能低的资源开销建立一条加密隧道。SS 的加密方式基于 AEAD(认证加密)流密码,常见的组合包括 AES-256-GCM 和 ChaCha20-Poly1305。前者在主流 CPU 上有硬件加速,后者在移动端 ARM 处理器上表现更好。

SS 的传输层默认走 TCP,数据被封装成标准的 SOCKS5 代理流量。正因为它在协议层面上"看起来像普通代理",所以部署非常轻量,不需要额外的握手与身份验证开销。连接建立时,客户端与服务器之间只需要一次 TCP 握手加一次加密握手,整个过程通常在几十到几百毫秒内完成。对于网页浏览、即时通讯这类短连接场景,SS 的响应速度非常理想。

SS 的局限也很明显。首先是单端口多用户能力较弱:早期的 SS 一个端口只能服务一个用户,后来的实现虽然支持多用户,但需要在服务端维护用户表,遇到大规模并发时会增加管理复杂度。其次是协议特征相对固定,某些深度包检测(DPI)系统可以通过分析流量统计特征来识别 SS 流量,尽管这需要一定的计算资源。对于普通用户来说,SS 仍然是最"顺滑"的选择——客户端生态成熟、配置简单、资源占用低。

在移动端,SS 的电量表现值得单独说明。由于 SS 基于 TCP,系统可以进入低功耗模式,不需要像 UDP 协议那样频繁唤醒无线电模块。在 iOS 和 Android 上,SS 的后台保活相对容易,长时间挂机不会显著增加耗电。对于主要用手机刷社交媒体、看网页的用户,SS 是省电的优选。

在实际使用中,SS 适合以下场景:轻度至中度跨境访问、移动端长时间挂机、对连接建立速度敏感的应用(如即时通讯)、以及网络环境相对稳定的情况。如果网络丢包率较高,SS 的 TCP 重传机制会导致明显的速度下降,这时更推荐后面要讲的基于 QUIC 的协议。

NZVPN 的线路列表中,大多数普通线路默认采用 SS 或兼容 SS 的传输方式。这些线路适合日常使用,配合中转拓扑可以在晚高峰保持基本稳定。如果你追求更极致的速度表现,可以在客户端中切换到其他协议,或在套餐页选择包含专线线路的方案。

VMess 与 VLESS:完整协议框架的演进

VMess 是 V2Ray 家族的核心协议,设计上比 SS 更注重"看起来不像已知协议"。VMess 在应用层引入了 UUID 作为用户标识,并在请求头中加入时间戳,配合可选的防重放机制,使得同一份请求在网络上不会被轻易重放或识别。VMess 的加密同样基于 AEAD,但它在元数据(如目标地址、端口)上也做了加密,不像 SS 那样把目标地址暴露在明文头部。

VMess 的代价是连接建立速度相对较慢。每次连接都需要完成一次"客户端发起 → 服务端验证 UUID → 返回响应"的握手流程,在弱网下这个流程可能被重传拖长。此外,VMess 的头部带有固定前缀,这个特征在 DPI 系统中可以被识别。为了规避这一点,后来的实现引入了 mKCP、WebSocket、gRPC 等传输层变体,把 VMess 流量伪装成 WebSocket 或 gRPC 流量。

VLESS 是 VMess 的继任者,它的核心改进是去掉了 VMess 中冗余的加密层。VLESS 本身不加密数据,只负责传输元数据,真正的加密由传输层(如 TLS)完成。这样做的好处是连接建立速度明显提升——不需要先做一次应用层加密握手,直接通过 TLS 建立安全通道即可。VLESS 保留了 UUID 用户标识和防重放能力,并增加了对 XTLS 等新传输特性的支持。

在资源占用方面,VLESS 比 VMess 更轻量。由于省去了一层应用层加密,CPU 占用率下降,这在低端设备或移动端上尤为明显。VLESS 配合 TLS + WebSocket 或 gRPC 传输时,流量特征与正常的 HTTPS 网站访问几乎无法区分,适合对流量特征敏感的环境。

需要说明的是,VLESS 本身不加密数据,因此必须搭配 TLS 使用才安全。NZVPN 的客户端在配置 VLESS 线路时,会默认启用 TLS 加密,用户无需手动干预。VLESS 与 CDN 的配合也更好:因为 VLESS 的握手过程简洁,CDN 回源时不容易因为超时而断连。

从选型角度看,VMess 适合对兼容性要求较高的旧客户端,或需要 mKCP 等特殊传输的场景;VLESS 则更适合追求连接速度和现代传输特性的用户。两者在 NZVPN 的线路中都有部署,客户端会根据线路配置自动选择合适的协议,普通用户不需要手动区分。

Trojan:伪装成正常 HTTPS 流量

Trojan 的设计思路与 SS、VMess 都不同。它的核心思想是"让流量看起来与普通的 HTTPS 网站访问完全一致"。Trojan 在 TLS 隧道之上叠加了一层自定义协议,客户端与服务端之间先完成一次完整的 TLS 握手,然后通过一个类似 HTTP 的头部来传递实际请求。从网络流量上看,Trojan 连接与浏览器访问一个启用了 HTTPS 的网站几乎无法区分。

正因为这种伪装特性,Trojan 在需要"看起来像普通访问"的场景下非常有效。它的连接建立过程与普通 HTTPS 相同:一次 TCP 握手加一次 TLS 握手,之后才开始传输数据。这个流程比 VMess 少了一层应用层握手,所以连接建立速度与 VLESS 相当,但比 SS 略慢(因为 TLS 握手本身需要 1~2 个 RTT)。

Trojan 的加密完全依赖 TLS,因此对证书管理有较高要求。服务端必须持有有效的 TLS 证书,否则连接会在握手阶段失败。NZVPN 的客户端内置了证书校验逻辑,当线路配置了 Trojan 协议时,会自动完成证书验证,用户只需要在订阅导入时选择对应的线路即可。如果证书过期或域名变更,客户端会提示连接失败,此时重新获取订阅链接即可更新。

在资源占用方面,Trojan 的开销主要来自 TLS 加解密。现代 CPU 都有 AES-NI 等硬件加速指令,所以 TLS 加解密的 CPU 占用率并不高。在移动端,Trojan 的电量表现与 VLESS 接近,因为两者的传输层都是 TCP,系统可以正常进入低功耗模式。但需要提醒的是,如果网络丢包严重,Trojan 的 TCP 重传同样会拖慢速度,这是所有 TCP 协议的共性。

Trojan 的适用场景:需要稳定通过复杂网络环境、希望流量特征尽量不显眼、以及需要与 CDN 配合做域名分流的用户。Trojan 与 TLS + WebSocket 的组合可以很好地兼容 CDN,让流量从 CDN 节点回源到真实服务器,进一步隐藏后端位置。

在 NZVPN 的线路体系中,Trojan 通常部署在专线或高质量中转线路上。因为 Trojan 的伪装特性需要稳定的 TLS 连接,如果线路本身质量差,频繁的 TLS 重连反而会降低体验。对于追求"连上就能用、不折腾"的用户,Trojan 线路是省心的选择。

Hysteria2 与 TUIC:基于 QUIC 的新一代协议

Hysteria2 和 TUIC 都是基于 QUIC(Quick UDP Internet Connections)的代理协议。QUIC 是 Google 主导开发的传输层协议,底层使用 UDP,但内置了 TCP 的可靠传输、拥塞控制和多路复用能力。与 TCP 相比,QUIC 最大的优势是连接建立快——它把 TLS 握手合并进了传输握手,通常只需要 1 个 RTT 就能建立加密连接。

Hysteria2 的独特之处在于它使用了名为 Brutal 的拥塞控制算法。传统 TCP 拥塞控制(CUBIC、BBR 等)在检测到丢包时会主动降低发送速率,这在有丢包的网络里会导致带宽利用率下降。Brutal 则相反:它允许用户设定一个目标速率,然后持续以这个速率发送数据,不因丢包而退缩。这在高丢包、高延迟的链路上非常有效,可以让视频流、大文件下载保持稳定速度。

TUIC 的设计更偏向"简洁"。它同样基于 QUIC,但取消了服务端的用户表,改用类似 VLESS 的 UUID 标识。TUIC 的连接建立速度与 Hysteria2 相当,但它的拥塞控制算法更接近标准 QUIC 的默认实现,因此在极端高丢包环境下,速度表现不如 Hysteria2 激进。不过,TUIC 的资源占用更低,在低端设备上运行更流畅。

移动端电量是选择 QUIC 协议时最需要权衡的因素。QUIC 基于 UDP,而 UDP 在移动网络下需要更频繁地唤醒无线电模块,以维持 NAT 映射和连接状态。这意味着在同等使用时长下,QUIC 协议的电量消耗通常比 TCP 协议高 10%~20%。不过,QUIC 的快速重连能力也意味着网络切换时能更快恢复,减少了"重新连接"带来的额外耗电。

Hysteria2 和 TUIC 适合以下场景:移动网络(4G/5G)下高丢包环境、需要看 4K 流媒体或进行视频会议、以及网络频繁切换(如地铁、高铁)的情况。在丢包率超过 5% 的链路上,基于 QUIC 的协议往往比 TCP 协议快 2~3 倍。

NZVPN 的客户端对 Hysteria2 和 TUIC 做了全面支持。在订阅导入时,如果选择了支持 QUIC 的线路,客户端会自动配置对应的端口与传输参数。需要注意的是,某些老旧网络设备(如部分企业防火墙)可能禁止 UDP 流量,这种情况下 QUIC 协议无法工作,需要回退到 TCP 协议。

连接建立速度与资源占用横向对比

把六种协议放在同一张表里,可以更直观地看出它们的设计取舍。需要说明的是,下表的数据是基于典型网络环境(丢包率 1%~3%、RTT 40~80ms)的经验值,实际表现会因线路质量、设备性能、网络拥塞程度而有所不同。

从表格中可以提炼出几条选型规律。第一,如果你的网络环境稳定(家庭宽带、办公网络),TCP 协议(SS、VLESS、Trojan)已经足够,它们省电且兼容性好。第二,如果你经常在移动网络下使用,或者所处网络丢包率偏高,基于 QUIC 的协议(特别是 Hysteria2)能显著提升速度体验。第三,如果你对流量特征有顾虑,Trojan 和 VLESS 是更稳妥的选择。

资源占用方面,SS 和 VLESS 的 CPU 占用率最低,因为它们省去了额外的加密层。VMess 因为多了一层应用层加密,CPU 占用略高。Hysteria2 和 TUIC 的 CPU 占用取决于 QUIC 的实现质量——TUIC 的代码更精简,在低端设备上更有优势。

连接建立速度是很多人忽略的指标。短连接场景(网页浏览、API 调用)对连接建立延迟非常敏感,每多一次 RTT 都会让用户感知到"卡一下"。QUIC 协议把 TLS 握手合并到传输握手,将连接建立压缩到 1 个 RTT,这是它在移动端体验上的一大优势。而 VMess 因为需要额外的应用层握手,在弱网下连接建立可能超过 1 秒。

需要注意的是,协议的横向对比不能脱离线路质量单独看。一条高质量的 IEPL 专线配合普通 TCP 协议,可能比一条劣质中转线路配合 QUIC 协议更稳定。协议解决的是"数据怎么传",线路解决的是"数据走哪条路",两者需要结合评估。

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

线路拓扑决定了数据从用户设备到目标服务器之间经过多少跳、走哪条物理路径。常见的拓扑有三种:直连、中转和专线。理解它们的差异,是判断一条线路"值不值"的关键。

直连( Direct )

直连意味着用户设备与目标节点之间没有中间转发服务器,数据直接通过公网路由到达节点。直连的优点是延迟低——路径最短,没有额外的跳数开销。但缺点是稳定性完全取决于公网路由质量。晚高峰时,公网国际出口带宽紧张,直连线路可能出现明显的丢包和抖动。此外,直连线路在跨运营商(如移动访问联通出口)时,路由可能绕路,导致实际延迟远高于理论值。

中转( Relay )

中转线路在用户与目标节点之间插入一台或多台转发服务器。这些转发服务器通常部署在骨干网或国际出口的关键位置,能够优化路由路径、规避拥堵路段。中转的优点是稳定性好:即使公网某段出现拥塞,中转服务器也能通过备用路由绕行,保证连接不断。代价是延迟增加——每经过一跳,大约会增加 5~15ms 的延迟,具体取决于物理距离。

中转又分为"普通中转"和"智能中转"。普通中转固定走某一台转发服务器,路径相对固定;智能中转会根据实时网络状况动态选择最优路径,类似 BGP 选路。NZVPN 的中转线路普遍采用智能选路,在晚高峰时会自动切换到延迟更低的路径。

专线( IEPL )

IEPL( International Ethernet Private Line )是运营商提供的点对点专线服务,物理上独享带宽,不走公网。专线的延迟极低(通常比公网直连低 20~40%),而且几乎没有丢包——因为整条链路是独享的,不会受到其他用户流量影响。专线的缺点是价格昂贵,因此通常只部署在少数热门节点上。

三种拓扑的选择逻辑可以概括为:追求极致速度选专线,追求稳定选中转,追求低延迟且网络环境好选直连。NZVPN 的线路列表中,每条线路都会标注类型标签——IEPL 专线、中转、直连。在客户端中,你也可以按线路类型筛选。

NZVPN 的 220+ 线路中,专线、中转和直连按比例搭配,覆盖 120+ 国家。热门地区(香港、新加坡、美国)通常同时提供三种拓扑,用户可以根据使用场景选择。比如,看 Netflix 建议选专线,日常浏览选中转,玩游戏选直连。

丢包与晚高峰拥塞的成因与应对

丢包是跨境网络中最常见的性能杀手。理解丢包的成因,才能判断一条线路是否值得长期使用。丢包的原因大致可以分为三类:物理链路损耗、路由器队列溢出、以及路由绕路。

物理链路损耗

海底光缆、陆上光缆在长距离传输中会产生信号衰减,电信号或光信号经过中继器时可能出现误码。误码率在正常范围内时,由链路层的纠错机制处理,不会影响上层协议。但当链路老化或受天气影响时,误码率上升,超出纠错能力的数据包会被直接丢弃。这类丢包通常是持续性的,表现为某条线路长期不稳定。

路由器队列溢出

这是晚高峰丢包的最主要原因。互联网上的路由器都有缓冲区(队列),当某个方向的流量超过链路带宽时,数据包会在队列中排队等待转发。如果队列满了,新到达的数据包就会被丢弃。晚高峰时,国际出口带宽被大量用户共享,队列溢出概率显著上升,导致丢包率从平峰的 0.1% 飙升至 3%~10%。

拥塞控制算法的作用就是让发送端感知到网络拥塞,并主动降低发送速率,避免持续丢包。TCP 的 CUBIC 算法会在丢包后把拥塞窗口减半,这虽然缓解了拥塞,但也导致吞吐量骤降。BBR 算法通过测量瓶颈带宽和最小 RTT 来动态调速,在丢包环境下能保持更高的吞吐量。QUIC 默认采用类似 BBR 的拥塞控制,因此在高丢包环境下表现更好。

路由绕路

路由绕路不是丢包,但会间接导致丢包。当公网路由因为故障或拥塞而切换到一条更长的路径时,RTT 显著增加,数据包在队列中停留的时间变长,更容易触发超时重传。超时重传会进一步加剧拥塞,形成恶性循环。中转线路的一个核心价值就是规避绕路:通过骨干网上的转发节点,把路径"拉直",减少不必要的跳数。

应对晚高峰拥塞,用户侧能做的选择有限,但仍有几个有效策略。第一,优先选择 IEPL 专线线路——专线独享带宽,不受公网拥塞影响。第二,在客户端中启用基于 QUIC 的协议(Hysteria2/TUIC),它们对丢包的容忍度更高。第三,避开最繁忙的时间段(通常为当地晚间 20:00~23:00),或切换到负载较低的节点。

NZVPN 的线路列表会实时显示每条线路的延迟与带宽。如果某条线路在晚高峰持续出现高延迟或低带宽,可以尝试切换同地区的其他线路。客户端内置的自动选线功能也会在连接质量下降时提示用户切换。

按使用场景选协议与线路

最后,把协议与拓扑的讨论落到具体场景。不同用途对网络特性的侧重不同,选型时应该优先满足最核心的需求。

上表的推荐不是绝对的,实际使用中还需要结合具体线路的实时状态。比如,一条直连线路在晚高峰可能比中转线路更慢,此时就应该临时切换到中转线路。NZVPN 客户端支持按协议和线路类型筛选,用户可以根据当时的网络状况灵活调整。

对于大多数用户,一个实用的策略是:默认使用 VLESS + 中转线路,这套组合在稳定性和速度之间取得了较好的平衡。如果发现某条线路在晚高峰速度下降明显,切换到 Hysteria2 或专线线路。如果设备电池续航紧张,改用 Shadowsocks 以节省电量。

关于订阅方案,如果你经常看 4K 流媒体或使用 AI 工具,建议选择 250GB 或 500GB 的月订阅档位,流量更充裕;如果只是日常浏览,60GB 的基础档已经足够。流量包适合用量波动大的用户,购买后永久不过期,可以按需补充。

最后,无论选择哪种协议与线路,30 天无理由退款都提供了试错空间。你可以先订阅一个月,在实际网络环境中测试不同线路的表现,再决定长期使用哪个方案。