线路与协议技术参考

一次跨境连接里发生了什么

把一次访问拆开看,数据从设备到目标服务要经过五个环节:设备上的客户端 → 本地网络(路由器、光猫、无线接入)→ 运营商出口 → 跨境链路 → 落地节点 → 目标服务。前两个环节由你控制,第三个环节由运营商决定,第四、第五个环节才是加速服务真正能优化的部分。

理解这句话很重要:跨境加速服务不能改变你家宽带的质量,也不能改变目标服务本身的响应速度。它能做的是把「运营商出口 → 落地节点」这一段换成一条更可控的路径。所以当你觉得慢的时候,先分清问题出在哪一段,比反复换节点管用得多。

协议与线路是两个独立维度

很多讨论把两者混在一起讲,结果越看越糊涂。它们是两件不同的事:

• 协议决定数据怎么封装、怎么加密、怎么握手。它是软件层的约定,同一个协议可以跑在很多条不同的线路上。
• 线路决定数据包实际走哪条物理路径、经过哪些机房、在哪一跳出境。它是网络层的事实,同一条线路上可以跑任何协议。

打个比方:协议像寄快递时选的信封和封口方式,线路像快递实际走的运输路线。信封再讲究,路线堵了照样慢;路线再顺,信封不合规也可能被退回。两者要分别评估,组合起来才有意义。

在本服务的客户端里,这个区分是直接可见的:地区侧栏的每一行都带一个线路类型徽标(专线 / 中转 / 直连),而协议是在当前线路卡下方单独选择的。这样你可以固定线路、只换协议,或者固定协议、只换线路,把变量一个一个排除掉。完整的线路清单在线路页。

延迟由四部分构成

用户感受到的「快慢」,在技术上主要体现为延迟。延迟不是一个单一数字,它至少由四部分叠加:

1. 物理传播延迟。光在光纤中的传播速度约为每秒 20 万公里,这是硬上限。以中国东部到日本东京为例,直线距离约 2000 公里,单程理论下限约 10 毫秒,往返约 20 毫秒。也就是说,亚洲区域内 20~40 毫秒的往返延迟已经接近物理极限,继续往下压的空间很小。
2. 路由绕行。数据包不一定走直线。公共互联网上的路由由各运营商之间的互联关系决定,绕经第三地是常态。一段直线距离 2000 公里的路径,实际可能走出 5000 公里。
3. 排队延迟。路由器与交换机的出口带宽有限,流量大时数据包要排队。排队延迟在链路利用率超过七成之后会快速上升,这是晚高峰变慢的主要原因。
4. 协议握手开销。建立连接本身需要往返。TCP 三次握手加 TLS 握手,通常要额外付出一个到两个往返时间。这部分与线路质量无关,但可以通过选择协议和复用连接来压缩。

前两项由线路决定,第三项由线路质量与时段共同决定,第四项由协议决定。这就是为什么「选协议」和「选线路」要分开做——它们优化的是不同的那一段。

抖动与丢包比平均延迟更影响体感

平均延迟只是三个指标里的一个。另外两个同样重要:

• 抖动:延迟的波动幅度。平均 60 毫秒、波动正负 5 毫秒的线路,体感比平均 50 毫秒、波动正负 40 毫秒的线路好得多。视频会议和实时语音对抖动最敏感。
• 丢包:数据包没能到达对端。TCP 系协议遇到丢包会重传并降低发送速率,一次百分之一的丢包在长肥管道(高延迟、高带宽的链路)上可能让吞吐掉一半以上。

所以评估一条线路,不能只看延迟数字,还要看它在晚高峰时段的抖动与丢包是否稳定。线路页标注了每条线路的类型,类型本身就暗示了它的稳定性特征——这一点在下面的线路拓扑一节展开。

六种主流协议的设计取舍

协议没有绝对的好坏,只有设计目标的差异。下面六种是当前客户端里最常见的选择。它们之间有一条比任何其他差异都重要的分界线:前四种基于 TCP,后两种基于 QUIC(也就是跑在 UDP 上)。这条分界线决定了它们在弱网环境下的行为方式完全不同。

• Shadowsocks TCP / AEAD

  轻量加密代理,资源占用最低,老设备友好。

• VMess TCP / 多传输层

  功能完整,支持复杂分流,握手开销偏大。

• Trojan TLS / 443

  把代理流量做成标准 HTTPS,特征隐蔽。

• VLESS TLS / 精简

  去掉内置加密层,握手更轻,吞吐靠前。

• Hysteria2 QUIC / UDP

  为高丢包链路调优,带宽保持能力最强。

• TUIC QUIC / UDP

  0-RTT 恢复,移动端切换网络后回得快。

Shadowsocks:够用就好的轻量方案

Shadowsocks 的设计目标是「够用就好」:一个轻量的加密代理,把本地流量加密后转发到远端节点。它没有复杂的握手协议,使用 AEAD 系列加密算法,每个连接的头部开销很小。

优点很明确:实现简单、CPU 与内存占用低、在老旧设备与路由器上跑得动、客户端生态极其成熟。它的缺点也来自同一处——功能克制。没有原生的多路复用,每条连接独立建立;伪装能力依赖插件或传输层配合,裸用时的流量特征相对固定。

适合谁:路由器、老手机、老电脑,以及只做网页浏览和轻量办公的场景。如果设备性能有限,Shadowsocks 往往是最不容易出问题的选择。

VMess:功能完整但更重

VMess 是 V2Ray 项目自研的协议,设计上比 Shadowsocks 完整得多:支持多种传输层(TCP、WebSocket、gRPC、HTTP/2),支持完整的路由分流规则,可以按域名、IP、端口决定走哪条线路。

它使用带时间戳的认证握手,这是最需要留意的一点:客户端与服务端的时钟必须基本一致,偏差过大时会直接认证失败。很多「昨天还好好的、今天连不上」的案例,根源就是设备时间不对。

握手开销比 Shadowsocks 大一些,连接建立需要的往返次数更多。在需要复杂分流规则的场景下,这个代价是值得的;如果只是简单代理,它就偏重了。适合谁:需要按域名分流、需要多条出站规则、愿意花时间配置的用户。

Trojan:把代理做成标准 HTTPS

Trojan 的思路完全不同:它不发明新的加密方式,而是把代理流量伪装成标准的 HTTPS 流量,直接使用 TLS。从外部看,它就是一次普通的 TLS 连接——因为它在协议层面确实就是。

这个设计的收益是特征隐蔽:流量形态与访问一个真实网站几乎没有区别。代价是部署上的耦合——它必须占用 443 端口并配置有效证书,一旦有别的服务抢了 443,就会冲突。

性能上,Trojan 的开销主要来自 TLS 本身。现代客户端的 TLS 1.3 握手已经相当快,实际体验与 VLESS 接近。适合谁:希望代理流量与普通 HTTPS 难以区分的场景,以及已经具备证书条件的部署环境。

VLESS:精简版的高吞吐路线

VLESS 可以理解为 VMess 的精简版:去掉了内置加密层,把加密完全交给传输层(通常是 TLS)。少一层加密,就少一次数据处理,CPU 开销和握手体积都更小。

配合 XTLS 系列流控时,VLESS 可以在转发时减少一次「解密再加密」的过程,吞吐表现是六种里比较靠前的。代价是它必须搭配 TLS 使用——裸 VLESS 没有加密,不适合单独使用。它的配置形态与 VMess 接近,熟悉 V2Ray 系客户端的用户上手没有障碍。

适合谁:现代客户端、追求吞吐、已经具备 TLS 条件的场景。日常浏览与 AI 工具的长连接,VLESS 是很稳的默认选择。

Hysteria2:为高丢包链路而生

Hysteria2 基于 QUIC,跑在 UDP 上。它最值得说的不是加密,而是拥塞控制:它使用为高丢包链路调优的拥塞控制算法(BBR 系),在跨境这种长距离、有丢包的链路上,吞吐保持能力明显好于传统 TCP 系协议。

原因在于 TCP 把丢包一律解释为「网络拥塞」,于是降速重传;而跨境链路上的丢包很多时候与拥塞无关,降速就是白白损失带宽。QUIC 系的协议可以在用户态实现更聪明的判断,把「真拥塞」和「随机丢包」区分开。

代价有两个:一是走 UDP,部分网络环境对 UDP 有额外限制或限速,实际表现会打折;二是加密与拥塞控制都在用户态做,CPU 占用与电量消耗比 TCP 系协议高一点。适合谁:跨境长距离、晚高峰丢包明显、需要稳定带宽的场景,比如 4K 流媒体和大文件下载。

TUIC:把连接建立压到 0-RTT

TUIC 同样基于 QUIC,但设计取向更偏「快」:它把连接建立压缩到 0-RTT,也就是在会话恢复时可以不带完整握手就发出数据。

这个特性对移动端特别有价值。手机在 Wi-Fi 与蜂窝网络之间切换时,连接会中断重建;TUIC 重建连接的速度更快,体感上就是「切个网络,视频没断」。它的生态规模比前几种小一些,部分客户端支持有限,选它之前先确认你常用的客户端是否支持。

适合谁:手机、平板等会频繁切换网络的设备,以及需要快速恢复连接的场景。

六种协议横向对照

连接建立速度与资源占用

「连上要等一两秒」和「连上之后速度慢」是两个不同的问题,前者属于握手开销,后者属于线路质量。这一节讲前者,以及它在移动设备上的另一面:电量。

首次连接要付出几个往返

建立一条到落地节点的连接,不是发一个包就能开始传数据的。以 TCP 系协议为例:

1. TCP 三次握手,消耗 1 个往返时间。
2. TLS 握手(TLS 1.3),再消耗 1 个往返时间。
3. 协议自身的认证,通常可以搭在 TLS 握手里一并完成。

所以在一条往返 60 毫秒的线路上,首次连接的「见面成本」大约是 120 毫秒。这个数字在打开一个网页时感受不到,但如果客户端为每一个请求都新建连接,累积起来就很明显了。

会话恢复把成本压到一个往返以内

TLS 1.3 支持会话恢复:客户端与服务端在首次连接后交换一张「票」,后续连接可以凭票直接进入加密传输,握手压缩到 0 个往返。QUIC 系协议(Hysteria2、TUIC)原生支持这一点,TUIC 更是把 0-RTT 当作核心卖点。

实际影响是:同一个客户端在几分钟内重复访问同一节点,第二次之后几乎没有握手开销。这也是为什么「连上之后用起来很顺,但每次重连都要等一两秒」的情况,通常不是线路本身的问题,而是握手路径上的某个环节变慢了——比如客户端在做延迟测试、或者线路列表在同步。

多路复用:一条连接跑完所有请求

多路复用指的是在一条已建立的连接里同时跑多个请求。好处是只需要一次握手,后续请求直接复用;坏处是这条连接一旦出问题,所有请求一起受影响。

Shadowsocks 没有原生多路复用,VMess 与 VLESS 支持,QUIC 系协议在传输层天然支持。对日常使用来说,多路复用主要改善的是「打开一个有很多小请求的网页」这类场景——首屏需要加载几十个资源的页面,复用连接的体验明显更连贯。

移动端电量:三个真实的消耗来源

手机上的电量消耗主要来自三处,与协议选择的关联度依次递减:

1. 心跳与保活。为了保持连接可用,客户端会定期发送小包。频率越高越耗电。合理的区间是几十秒一次,过于频繁(比如每秒一次)会明显影响待机时长。
2. UDP 与无线模块唤醒。QUIC 系协议走 UDP,部分移动系统对 UDP 的电源管理更激进,可能更频繁地唤醒无线模块。这是 Hysteria2 与 TUIC 在移动设备上比 TCP 系协议略耗电的主要原因。
3. 加解密与拥塞控制的计算。这两项都在用户态完成,CPU 占用高一点,电量就多一点。现代移动芯片处理这些负载很轻松,所以这一项的实际影响最小。

实践建议:如果设备只是待机、偶尔收发消息,选 TCP 系协议;如果需要长时间看视频或下载,QUIC 系协议的带宽优势通常超过它的电量代价。

资源占用对照

表里的往返次数是协议原理层面的相对描述,不是实测结果。真实体验还取决于客户端的实现质量、线路的往返时间,以及设备本身的性能。换协议之前,先确认你的客户端确实支持它——支持不完整时,「换了更差的协议」比「没换」更糟。

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

线路拓扑讲的是数据包从客户端到落地节点之间经过哪些节点、走什么样的链路。它决定了这条线路在晚高峰时段的稳定性,而这往往是「白天好用、晚上难用」问题的真正答案。

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

直连是最简单的拓扑:客户端直接连到境外落地节点,中间经过的各跳全部由公共互联网的路由决定。

优点是路径短、成本低、部署灵活。缺点也很直接:跨境段完全暴露在公共互联网的拥塞与路由波动里。同一条直连线路,凌晨可能跑得很好,晚上八点之后可能掉到难以使用。它的表现取决于运营商之间的互联质量,以及那个时段有多少人同时在用这条路径。选择直连线路时,把它当作「够用就好」的选项,而不是追求稳定的选项。

中转:用一段可控链路换稳定

中转的思路是在客户端与落地节点之间加一个入口节点。客户端先连到离自己较近的入口,再由入口节点沿一条经过优化的路径把流量送到落地节点。

这样做的好处是:客户端到入口这一段通常在同一区域或同一运营商网络内,路径短、质量好;入口到落地这一段由服务方自己规划,可以避开公共互联网上拥塞严重的互联点。用户感受到的延迟 = 客户端到入口 + 入口到落地,两段都比原来那条不可控的直连路径更可预测。

代价是多了一跳,理论上多出一点延迟。但在晚高峰时段,这个「多出来的一跳」往往反而让总延迟更低,因为它绕开了拥塞点。中转线路的另一个好处是入口可以就近选:同一条中转线路,不同地区的用户可以选择不同的入口,而不需要服务方为每个地区都部署一套落地。

需要注意的一点是:中转节点的质量决定了整条线路的上限。入口本身如果过载,后面的路径再优化也没用。这也是评估服务方时值得关注的地方——线路列表里标注为中转的条目,数量不在多,而在入口是否分散。

专线:把跨境段固定下来

专线(IEPL,国际以太网专线)是三种拓扑里最「重」的一种:跨境段不走公共互联网,而是走服务方向运营商租用的专用链路。这条链路有约定的带宽与质量指标,不与其他人的流量抢占同一个出口。

它带来的直接结果是稳定性:延迟波动小、晚高峰几乎不受影响、丢包率长期维持在很低的水平。对于需要长时间保持连接的应用(视频会议、远程桌面、AI 工具的长会话、大文件传输),专线的价值主要体现在「不会突然掉下去」,而不是「峰值有多快」。

代价是成本与覆盖。专线的单位带宽成本远高于公共互联网,所以通常只在需求量最大的地区与城市部署;数量上不会像直连那样铺得很广。在本服务的线路列表里,标注为 IEPL 专线的条目集中在日本、新加坡、美国、香港、意大利等常用落地区域,这也符合专线的部署逻辑——优先放在用户最常去的地方。

三种拓扑怎么选

选择顺序上,一个实用的做法是:默认用中转,遇到对稳定性要求高的任务时切专线,直连留给对延迟不敏感的轻量场景。本服务的客户端支持在地区侧栏里直接切换线路类型,不需要重新导入订阅。想先看完整的线路清单,可以打开线路页按地区浏览。

丢包与晚高峰拥塞的成因

晚高峰变慢是跨境访问最常见的抱怨,也是最容易被误解的现象。它通常不是「服务方限速」,而是几个可解释的机制叠加在一起。理解这些机制,能帮你判断该换线路、换协议,还是干脆换个时段。

出口带宽是共享的

运营商之间的互联带宽是有限的,而且是所有用户共享的。晚上八点到十一点是家庭宽带使用的高峰,同一时间大量用户在看视频、下载、玩游戏,跨境方向的流量同步上升。当某条互联链路的利用率超过七成,排队延迟就开始明显上升;超过九成,丢包开始出现。

这解释了一个常见现象:同一条线路,白天延迟稳定、晚上成倍上涨。线路本身没有变化,变化的是它和别人共享的那段管道有多拥挤。

丢包为什么会让速度掉得比想象中多

TCP 的设计里,丢包被当作拥塞信号:一旦检测到丢包,发送方会把发送窗口砍半,然后慢慢爬回来。这个机制在局域网里很有效,但在跨境这种高延迟链路上会放大问题。

原因在于「长肥管道」效应:往返延迟高、带宽大的链路上,发送方需要维持大量在途数据才能跑满带宽。一次丢包让窗口砍半,而爬回来需要的时间与往返延迟成正比——往返 200 毫秒的线路上,窗口恢复可能要好几秒。在这几秒里,吞吐只有峰值的一半甚至更低。

所以百分之一的丢包,在高延迟链路上可能带来三成以上的吞吐损失。这也是 QUIC 系协议(Hysteria2、TUIC)在跨境场景里表现更好的根本原因:它们能在用户态实现更精细的拥塞判断,把随机丢包与真拥塞区分开,不至于一丢包就大幅降速。

无线接入段也会贡献丢包

不是所有丢包都发生在跨境段。无线接入是最容易被忽略的一环:

• Wi-Fi 信号弱。隔一堵承重墙、距离路由器较远时,无线重传会明显增加。表现是延迟忽高忽低,而不是稳定地慢。
• 2.4GHz 频段拥挤。同频段设备多时,信道争用会带来随机丢包。换成 5GHz 频段通常立竿见影。
• 移动网络切换。手机在基站之间移动时会有短暂的连接中断,QUIC 系协议恢复得更快。
• 路由器性能不足。老旧路由器在跑加密流量时 CPU 打满,自己就成了瓶颈,表现为「连上后整体变慢」。

排查方法很简单:用同一台设备、同一条线路,分别接网线和 Wi-Fi 测试。如果网线下明显更好,问题就出在无线接入段,换线路解决不了。

一条可执行的排查顺序

1. 确认范围。是所有网站都慢,还是只有某一个?只有某一个的话,问题多半在目标服务或它的接入路径,不在你的线路。
2. 换线路类型。从中转切到 IEPL 专线。如果明显改善,说明原来的线路在晚高峰被拥塞影响。
3. 换协议。从 TCP 系切到 QUIC 系(Hysteria2 / TUIC)。如果改善明显,说明瓶颈在丢包导致的降速,而不在链路本身。
4. 换接入方式。Wi-Fi 换网线,或换到 5GHz 频段。这一步排除本地无线段的干扰。
5. 换时段。如果以上都无效,可能确实是该时段整体拥塞。换到人少的时段测试,能确认这个判断。

这五步的顺序是有讲究的:从「影响面最大、操作最省事」的一步开始,逐步缩小范围。多数情况下,前三步之内就能定位问题。如果排查过程中需要重新导入订阅,流程见教程页。

按使用场景选协议与线路

前面几节把机制讲清楚了,这一节把它们收成可以直接用的对照。选型的核心原则是:先看场景对「延迟 / 带宽 / 稳定性」三者中哪一个最敏感,再决定协议与线路的组合。

网页浏览与文档办公

这类场景的特点是请求多、单个请求小、对首字节时间敏感。协议上推荐 VLESS 或 Trojan,它们基于 TCP、握手开销可控,配合会话恢复后重复访问几乎无感。线路用中转即可,除非你所在地区的中转入口在晚高峰也吃紧。

如果要打开的是协同文档、在线表格这类持续保持连接的应用,建议切到 IEPL 专线。这类应用的体验瓶颈不在峰值速度,而在「编辑时会不会卡一下」,专线的低抖动正好对症。

AI 工具与开发场景

AI 对话工具和代码补全工具的共同点是:一个会话可能持续几分钟到几十分钟,中间有大量小请求往返,而且一旦连接中断,整个会话的上下文可能要重来。对这类场景,稳定性优先于峰值速度。

推荐组合是 VLESS + IEPL 专线。VLESS 在长连接上的资源占用低,专线保证会话不被打断。如果所在网络对 UDP 友好,也可以试 Hysteria2,它在长距离链路上的吞吐保持更好。命令行工具与开发环境的代理设置,在程序员场景的那篇文章里有更细的说明。

4K 流媒体

流媒体对带宽的要求是持续性的:4K 播放通常需要稳定在 25 Mbps 以上,而且要求这个带宽在整段播放期间保持,不能忽高忽低。协议上首推 Hysteria2,它的拥塞控制在长距离链路上更能守住带宽;线路用 IEPL 专线或优质中转。

另一个容易被忽略的点是落地区域的选择。流媒体平台的区域库与你的出口 IP 归属地绑定,选错地区会出现「能连上但内容不对」的情况。选地区时优先看平台本身在哪个区域有内容,再看该区域有没有专线节点。地区与线路的对应关系可以在线路页逐条核对。

移动设备与经常切换网络

手机和平板会在 Wi-Fi 与蜂窝之间来回切,也会在基站之间移动。这类场景对「连接恢复速度」的要求高于一切。协议上 TUIC 是首选,它的 0-RTT 恢复能让切换后的重连几乎无感;如果客户端不支持 TUIC,退而选 VLESS。

线路方面,中转就够了——移动网络本身的质量波动已经很大,专线的稳定性优势在移动场景里体现得不那么明显。电量敏感的用户可以优先 TCP 系协议,待机时的心跳开销更低。

路由器与多设备共享

在路由器上跑代理时,CPU 与内存是硬约束,协议越轻越好。Shadowsocks 是这类场景最稳妥的选择:实现简单、资源占用低、客户端支持广泛。如果路由器性能较好,也可以考虑 VLESS。

本服务的套餐不限设备台数,所以路由器、手机、电脑可以同时在线,不需要为每台设备单独买一份。流量是共享的,按开通日每月重置——如果你把路由器上的所有设备都接进来,流量消耗会比单机使用快得多,这一点要有预期。

场景对照速查

客户端里的线路与协议设置

本服务的客户端把上面这些选择做成了几个开关,不需要手写配置。这一节说明每个开关对应的是哪一层,以及什么时候该动它。

地区侧栏与线路类型徽标

客户端左侧是地区列表,每一行显示地区与城市,并带一个线路类型徽标:

• IEPL 专线 跨境段走专用链路,稳定性最好,适合长连接与流媒体。
• 中转 经就近入口转发,日常使用的默认选项。
• 直连 直接连到落地节点,路径最短,质量随公网波动。

同一个地区可能同时提供多种线路类型,这时按上一节的场景对照选。切换线路不需要重新导入订阅,客户端会直接重建连接。

当前线路卡与自动选线

主区上方的当前线路卡显示三件事:落地城市、线路类型、当前使用的协议。卡片右侧的「自动选线」开关打开后,客户端会在你选定的地区范围内自动挑一条当前状态较好的线路。

自动选线的适用场景是「不想每次手动挑」;不适用的是「需要固定出口 IP」——比如某些服务会记住你的登录地区,频繁变动可能触发额外的验证。需要固定时,关掉自动选线,手动指定一条线路。

协议切换

当前线路卡下方是协议 chips 行,列出该线路支持的协议。点一下即可切换。切换协议会重建连接,已建立的会话会短暂中断,所以正在开会或下载时不要随手切。

如果某个协议在你的网络环境下连不上,通常有两个原因:一是该协议依赖的传输层被本地网络阻断(比如 UDP 受限时 QUIC 系协议会失败),二是客户端版本过旧不支持。第二种情况升级客户端即可,客户端在面板的下载页获取,登录后可取。

设备清单与订阅同步

窗口下方的设备清单列出当前使用同一订阅的设备,每行带平台图标与同步状态。本服务不限设备台数,所以清单的长度没有上限,它只是让你知道有哪些设备在用。

订阅同步是自动的:线路有调整时,客户端会在下一次同步时拿到新列表,不需要手动更新。底部的等宽字体一行显示订阅状态与流量重置规则——流量按开通日每月重置,不是按自然月。这一点在套餐页也有说明。

手动配置时要注意什么

如果你用的是第三方客户端,需要手动导入订阅链接。订阅链接在面板里获取,登录后可见,不要把它贴到公开场合——它等同于你的账号凭据。示例格式如下(仅为格式演示,不是可用地址):

https://example.com/sub?token=YOUR_TOKEN&flag=clash

导入时的几个常见问题:

1. 导入后没有节点。多半是订阅链接复制不完整,末尾被截断。重新完整复制一次。
2. 节点有但连不上。检查客户端的协议支持情况。导入的配置里包含 Hysteria2 或 TUIC 节点,而客户端版本不支持时,这些节点会显示但无法连接。
3. 能连上但速度很慢。先确认走的是哪条线路,再按上一节的排查顺序处理。
4. 更新订阅后节点变少。确认订阅链接没有过期,以及是不是把不同套餐的订阅混在了一起。

术语表与延伸阅读

最后把本页用到的术语集中解释一遍,方便回头查阅。

常用术语

往返时间(RTT)

数据从客户端发到对端再返回所需的时间,单位毫秒。它是延迟最主要的组成部分。

抖动

往返时间的波动幅度。抖动大的线路体感比平均延迟略高但稳定的线路更差。

丢包

发出的数据包没有到达对端。TCP 系协议遇到丢包会降速重传,QUIC 系协议能在用户态做更精细的判断。

长肥管道

往返延迟高、带宽大的链路。这类链路上 TCP 的窗口恢复慢,丢包带来的吞吐损失被放大。

多路复用

在一条已建立的连接里同时跑多个请求,省去重复握手。缺点是单条连接出问题时影响面更大。

0-RTT

会话恢复时不带完整握手就直接发数据,把连接建立的开销压到最低。TUIC 以此为核心特性。

拥塞控制

发送方根据网络反馈调整发送速率的算法。不同算法对丢包的解释不同,直接决定高丢包链路上的实际吞吐。

IEPL 专线

国际以太网专线。跨境段走专用链路,不与公共互联网流量抢占出口,稳定性与抖动表现最好。

中转

客户端先连到就近入口节点,再由入口沿优化路径送到落地节点。用一段可控链路换稳定。

直连

客户端直接连到落地节点,全程走公共互联网路由。路径最短,质量随公网波动。

落地节点

流量最终出口所在的服务器位置,决定了目标服务看到的 IP 归属地。

流量重置日

本服务的流量按开通日每月重置,不是按自然月。开通日是 8 号,下一个周期的起点就是下个月 8 号。

延伸阅读

本页是系统查阅手册,如果你想按别的角度继续深入,站内还有这些内容:

• 教程页——从注册到导入客户端的完整主线流程,第一次使用建议从这里开始。
• 线路页——完整的地区与线路清单,按区域分组,标注线路类型与流媒体支持情况。
• 套餐页——三档月订阅与流量包的完整说明,以及所有套餐共同包含的内容。
• 线路怎么选——按地区、线路类型、用途三步挑节点的入门文章。
• 新手入门十问——多设备、流量计算、限速、订阅链接等最常被问到的问题。
• 买 VPN 怎么避坑——下单前该确认哪些事,以及退款承诺、支付渠道这些细节里的判断依据。
• ChatGPT 加速——AI 工具的访问与稳定性专题,含长连接的设置建议。

关于本页的说明

本页讲的是协议与线路的通用原理。文中提到的往返次数、握手开销等描述属于协议原理层面的相对比较,不是对特定网络环境的实测结论——真实体验取决于你的宽带质量、所在地区、目标服务的位置,以及使用时段。

涉及本服务的具体数字只有这些:110+ 国家 / 150+ 线路、不限设备台数、月订阅 ¥9.9 起、流量包永久不过期、7 天无理由退款、支持支付宝 / 微信 / USDT、无需邮箱地址即可注册。其余任何数字都不代表本服务的承诺。