协议参考:六种协议与三种线路拓扑

六种协议各自解决什么问题

一个代理协议要同时处理三件事:把 TCP 与 UDP 流量封装进一条隧道、让这条隧道在中间设备看来不像隧道、在两端完成身份认证与加密。这三件事的优先级怎么排,就分出了不同的协议。理解这一点之后,再看那些协议名就不会觉得是在挑「哪个更强」,而是在挑「这条链路缺什么」。

Shadowsocks:最轻的一层封装

Shadowsocks 是最早的轻量设计之一。核心是一条加密的 SOCKS5 隧道,用 AEAD 类算法(AES-256-GCM、ChaCha20-Poly1305 等)对载荷加密。它不做协议伪装,不假装自己是 HTTPS,只保证流量本身没有明文特征。

好处是实现简单、客户端支持面最广、握手开销最小。代价是流量形态固定:一条持续的双向随机字节流,端口也不一定是 443。在网络设备对「非标准端口的持续加密流」做分类时,它缺少一个可以依附的外壳。它的 UDP 支持也依赖具体实现,不同客户端的表现并不一致。

VMess:把协议和传输拆成两层

VMess 带 UUID 身份与时间戳校验,传输层可插拔,可以套 WebSocket、gRPC、HTTP/2、mKCP 等外壳。这是它最大的结构性优势:同一套认证逻辑可以挂在不同外观上,一种外观不合适就换另一种。

代价是协议本身复杂。时间戳校验要求客户端与服务器的时间偏差落在允许窗口内,设备时间不准会直接认证失败,而失败提示往往只是「连接超时」,很难一眼看出原因。老版本里的 AlterID 机制为兼容性保留了额外的身份派生,现在通常建议设为 0,以减少不必要的开销与重放面。

Trojan:把自己伪装成一次标准 TLS

Trojan 的思路最直接:客户端先与服务器完成一次真正的 TLS 握手,密码在 TLS 通道内作为认证凭据。对中间设备来说,这条连接与访问一个普通 HTTPS 站点没有区别,因为它在协议层面就是。

代价是必须有证书、必须占用 443 端口、证书过期或配置错误时整条线路直接不可用。它也是最依赖「服务端运维质量」的一种协议:证书链、SNI、HTTP 响应伪装任何一处没配好,都会让外观露馅或者连接失败。

VLESS:VMess 的减法版本

VLESS 去掉了协议层自带的加密与部分校验,把安全性交给外层的 TLS 或 Reality,自己只做轻量的身份传递。因为少了一层封装,它的握手更快、CPU 开销更低,配合 XTLS 思路可以做到很低的转发损耗。

代价是它自身不提供加密。配置里如果 TLS 没开好,安全性完全取决于外层,这一点和 Trojan 的「默认就走 TLS」不同。选 VLESS 的前提是确认外层传输已经配好,而不是把它当成一个可以裸奔的协议。

Hysteria2:为高丢包链路准备的 QUIC 方案

Hysteria2 基于 QUIC(UDP),自带拥塞控制。它针对的是 TCP 系协议在高丢包链路上的短板:QUIC 在用户态实现拥塞控制,可以采用对随机丢包不敏感的算法,不必像 TCP 那样把每一次丢包都当成拥塞信号。

代价是 UDP 特征明显。部分网络会对 UDP 做限速或降级,这时候它的表现会突然变得很差,而且这种变差是环境造成的,换参数解决不了。另外用户态协议栈的 CPU 占用高于内核 TCP,在低功耗设备上这一点会被放大。

TUIC:更极简的 QUIC 代理

TUIC 同样基于 QUIC,设计更接近「极简的 QUIC 代理」,支持 0-RTT 恢复握手。连接建立轮次少,重连快,适合频繁断线重连的移动场景。

代价是生态比 Hysteria2 窄一些,部分客户端与面板尚未支持。选它之前先确认手头的客户端版本能识别,否则会出现「配置写对了但客户端不认」的情况。

握手、开销与连接建立速度

协议之间的第一个可测量差异是「建立一条连接要几个往返」。这个数字直接决定首屏速度,尤其在跨境链路上,每一个往返都是一百多毫秒。

一次连接的往返次数

从点下「连接」到第一个字节发出,中间有几个不可避免的步骤:

1. 域名解析:如果客户端用域名连接服务器,先要解析出地址。用 IP 直连可以省掉这一步。
2. TCP 三次握手:一个往返,没有例外。
3. TLS 握手:TLS 1.3 是一个往返,TLS 1.2 是两个往返。这一层只有 Trojan、VLESS over TLS、以及套了 TLS 的 VMess 才有。
4. 代理协议自身的认证:多数协议把认证放在首个数据包里,不额外占往返。
5. 目标站点自己的握手:代理只负责把字节送到,目标站点的连接开销照样存在。

在一个往返 150 毫秒的跨境链路上,光是 TCP 加 TLS 1.3 就要 300 毫秒。这不是软件慢,是物理距离决定的。任何客户端优化都只能省掉软件层的开销,省不掉光在光纤里跑的时间。

各协议在这条时间轴上的位置

Shadowsocks 没有 TLS 层,认证与首个数据包合并,理论上是 1 个往返之后就能发数据。VMess 同样把认证放在首包,往返上不增加,但首包要解析时间戳与 UUID,CPU 上多一点。Trojan 与 VLESS over TLS 必须走完整的 TLS 握手,比 Shadowsocks 多一个往返,换来的是「看起来像 HTTPS」。

Hysteria2 与 TUIC 走 QUIC。QUIC 把传输握手与加密握手合并,首次连接 1 个往返;TUIC 支持 0-RTT 恢复,在会话票据有效期内重连不需要额外往返。这是 QUIC 系在「频繁断线重连」场景下的真实优势,而不是营销话术。

CPU 与内存的真实开销

加解密不是免费的,但在现代 CPU 上很便宜:

• AES-GCM 在支持 AES-NI 的 x86 处理器上有硬件加速,吞吐可以到数 GB/s 量级,单条代理连接根本压不满。
• ARM 设备(手机、路由器、电视盒子)上 AES 指令集支持不齐,ChaCha20-Poly1305 通常更快,这也是移动端推荐 ChaCha20 的原因。
• QUIC 系协议在用户态实现协议栈,每个包都要进出用户态一次,CPU 占用明显高于内核 TCP。低功耗设备上这一点会被放大成「风扇转起来」或者「电量掉得快」。
• 内存方面,主要开销是每条连接的缓冲区。多路复用可以把多条连接压进一条隧道,减少握手与缓冲,但代价是队头阻塞。

为什么握手开销会被放大

握手耗时只在「打开新连接」时付一次。浏览器对同一站点会复用连接,但现代网页往往跨多个域名:统计、字体、图片、接口各在一个域名下,一次页面加载可能触发十几条新连接。这时候握手往返会被放大十几倍,也是「协议看起来影响首屏速度」的真实原因。

反过来,视频播放、大文件下载这类长连接场景,握手只发生一次,协议之间的握手差异几乎看不出来。所以同一个协议在不同场景下的体感可以完全不同,讨论「哪个协议快」之前要先说清是什么场景。

移动端的电量账

手机上的耗电由四块构成:CPU 加解密、射频收发、系统唤醒次数、屏幕与硬件解码。协议影响的是前三块,而大多数用户感知到的「开了代理掉电快」,其实是第三块——唤醒次数。

射频唤醒的代价

移动网络的射频状态机有若干个档位:空闲、低功率、高功率。从空闲切到高功率要几百毫秒,并且在这段时间里功耗是峰值的数倍。如果一条连接每十秒发一次心跳包,射频就被迫每十秒醒一次,一整天下来是八千多次唤醒。

• TCP 系协议的保活通常可配置,系统级 TCP keepalive 默认间隔很长(以小时计),应用层完全可以不发心跳。
• QUIC 系协议为了维持 NAT 映射,默认会有周期性 keep-alive,间隔通常在十几秒到几十秒。这是 QUIC 在移动端更耗电的主要原因之一,而不是加解密本身。

所以「换协议能省电」这句话,准确的说法是「换掉周期性心跳能省电」。同样一条 QUIC 连接,把心跳间隔从十几秒调到两分钟,耗电差异会非常明显。

加解密的实际占比

在支持 AES 指令集的手机上,AES-GCM 的吞吐远高于移动网络的带宽上限,加解密占用的 CPU 时间可以忽略。真正吃 CPU 的是 QUIC 的用户态协议栈:每个数据包都要经历一次用户态与内核态之间的拷贝,在持续满速下载时,CPU 会长时间维持在较高频率。

反过来说,如果你的使用场景是刷网页、看消息,流量本身很小,QUIC 的 CPU 开销也就无从体现,耗电差异会被其他因素淹没。

后台保活与「看起来还连着」

iOS 与 Android 都会回收后台应用。代理类应用通常借助系统的 VPN 框架运行,这条通道相对稳定,但应用内的定时器仍会被系统节流。表现是:锁屏一段时间后重新解锁,连接看起来还在,但第一条请求明显变慢——这是隧道需要重建或重新协商。

这种「看起来还连着」的状态比彻底断开更麻烦,因为它不会触发客户端的自动重连逻辑。如果经常遇到解锁后第一次打开网页空白几秒,可以在客户端里把「断线自动重连」打开,或者干脆在长时间不用时手动断开。

省电的几条实操

• 手机优先用 TCP 系协议,把 QUIC 系留给弱网场景。
• 选延迟更低的近端线路:握手往返越短,射频处于高功率的时间越短。
• 关掉不必要的分应用代理:只让需要的应用走隧道,减少常驻连接数。
• 把心跳间隔调长,前提是网络环境不会因为 NAT 超时把映射表清掉。
• 长时间看视频时,电量差异主要来自屏幕与硬件解码,协议之间的差距会被稀释。

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

协议决定「怎么封装」,拓扑决定「走哪条路」。在跨境场景里,拓扑对体验的影响通常大于协议。同一个协议换一条拓扑不同的线路,体感差异可能比换三次协议都明显。

直连

客户端直接连到海外机房的公网地址,流量走运营商的国际出口。

• 结构最简单,没有中间环节,基线延迟最低。
• 但国际出口是共享资源。晚高峰时出口队列变长,丢包与时延一起上升,而且这种拥塞不受服务方控制。
• 适合:轻量网页浏览、非高峰时段、对成本敏感的场景。

直连的问题不在于「慢」,而在于「不可预测」。平峰时它可能比中转还快,晚高峰时它可能完全不可用,而这两种状态之间没有任何过渡提示。

中转

客户端先连到国内的中转入口,再由中转入口连到海外落地。

• 把「最后一公里」的不确定性收敛到一段可控链路:客户端到中转入口走国内骨干,通常稳定;中转入口到落地走优化过的跨境路由。
• 代价是多了一跳,基线延迟增加。中转节点本身的处理能力也会成为瓶颈,带宽不够的中转比直连还差。
• 关键指标不是「有没有中转」,而是「中转段的跨境路由是否被优化过」。同样叫中转,走公网出口和走优化路由是两件事。

这也是为什么不同服务商的中转线路体验差距可以很大:名字一样,背后的路由策略完全不同。判断方法只有一个——在晚高峰实际用一次。

专线

端到端的逻辑专线(IEPL、MPLS 一类),带宽独享或准独享,不经过公网出口的拥塞点。

• 延迟稳定、丢包低,晚高峰的表现与平峰接近。
• 成本高、总带宽有限,所以通常只在重点地区部署,不可能覆盖到每一个国家。
• 适合:实时性要求高的场景,例如会议、游戏、远程桌面、对稳定性敏感的业务。

专线不是「更快」,而是「更稳」。它的绝对延迟不一定比直连低,但在晚八点和凌晨两点测出来的数字应该差不多,这才是它值钱的地方。

延迟由哪几块组成

1. 物理传播:光在光纤中的速度约为每毫秒 200 公里。上海到洛杉矶直线约 10500 公里,单程光程按 1.4 倍绕行系数算约 14700 公里,单程约 73 毫秒,往返约 146 毫秒。这是物理下限,任何优化都无法突破。
2. 路由绕行:实际路由不一定走最短路径,绕行会额外增加几十毫秒。
3. 排队时延:出口拥塞时,数据包在队列里等待。这一项在晚高峰可以翻几倍,也是最不受控的一项。
4. 协议握手:见上一章,每多一层就多一个往返。

所以「这条线路延迟 40 毫秒」这种说法,只有在明确起点与终点时才有意义。同一个节点,从广州测和从哈尔滨测,数字可以差出一倍。

丢包、抖动与晚高峰

「晚高峰变慢」是跨境访问里最常见的抱怨,也是最容易被误解的现象。它不是一个原因,而是一串连锁反应的结果。

丢包从哪里来

• 误码:光纤的误码率极低,正常链路上因误码丢包可以忽略。无线段(4G、5G、Wi-Fi)是例外,信号弱时误码率会明显上升。
• 队列溢出:路由器的缓冲区满了,后来的包被丢弃。这是跨境链路上最主要的丢包来源。
• 策略丢包:部分网络设备会对特定类型的流量做限速或丢弃。这也是 QUIC 系协议在个别网络里表现不稳定的原因。

三种丢包的处理方式完全不同:误码只能靠换无线环境,队列溢出可以靠换拓扑或错峰,策略丢包只能靠换协议或换端口。不区分来源就盲目调参数,基本是白费力气。

晚高峰是怎么形成的

晚上七点到十一点,家庭宽带并发上升,国际出口的总流量接近或超过设计容量。出口设备开始排队,然后是一串连锁:

1. 队列变长,时延上升。
2. 队列满,开始丢包。
3. TCP 把丢包当成拥塞信号,拥塞窗口减半,吞吐骤降。
4. 用户感觉慢,刷新、重试,新连接涌入,拥塞进一步加剧。

这是一个正反馈,所以晚高峰的体验下降往往不是线性的,而是过了某个点之后突然变差。很多人会觉得「八点之前还好好的,八点零五突然就不行了」,原因就在这里。

为什么百分之一的丢包能毁掉一半带宽

TCP 的吞吐大致与「报文段大小 ÷(往返时间 × 丢包率的平方根)」成正比。往返 150 毫秒、丢包率百分之一时,单条 TCP 连接的理论吞吐会掉到峰值的很小一部分。这也是为什么「测速网站显示满速,但打开网页很慢」会同时出现:测速用的是多线程并发,网页用的是单条连接。

理解这一点之后,很多「玄学」就有了解释:同一时间、同一条线路,下载器能跑满而浏览器卡顿,不是浏览器的问题,是并发模型不同。

QUIC 系为什么在高丢包下更好

QUIC 在用户态实现拥塞控制,常用的算法基于带宽与往返时间建模,不把每一次丢包都当成拥塞信号。在随机丢包为主的链路上,这能让吞吐保持得更好。代价是它对「真拥塞」的反应也更迟钝,在确实带宽不足时会表现得不够公平。

换句话说,QUIC 系不是「更快」,而是「对丢包更宽容」。链路本身不丢包时,它和 TCP 系没有明显差距;链路开始丢包时,差距才拉开。

缓冲区膨胀

家用路由器与部分运营商设备使用大缓冲区。缓冲区大在突发流量下是好事,但在持续满载时会让排队时延飙升到几百毫秒。表现是:测速正常,但每一次点击都要等一会儿;视频能播,但拖动进度条要转圈。

判断方法:同时观察本地网关与境外目标的往返时间。如果网关本身就抖,问题在本地;如果网关稳定而境外目标抖,问题在跨境段。这一步能把排查范围砍掉一半。

抖动比延迟更影响体感

延迟高但稳定,用户会适应;延迟不高但抖动大,视频会频繁缓冲、语音会断续、游戏会瞬移。选线路时,抖动的权重应该高于平均延迟。很多客户端只显示一个「延迟」数字,那个数字通常是若干次探测的平均值,看不出抖动,需要自己连续测几次看波动范围。

按场景选型

前面几章讲的是原理,这一章给结论。前提是:以下建议都建立在「线路本身可用」的基础上。如果线路在晚高峰已经严重拥塞,换协议只能缓解,不能治愈。

日常网页与办公

推荐 VLESS over TLS 或 Trojan。

理由:网页加载会触发大量短连接,握手往返次数被放大。这两个协议走标准 TLS,配合连接复用,首屏体验稳定;同时它们的流量外观是普通 HTTPS,在各类网络环境下兼容性最好。不建议在办公场景用 QUIC 系:短连接场景下 QUIC 的握手优势不明显,而用户态协议栈的 CPU 开销在低配笔记本上会被感知到。

4K 流媒体

推荐 VLESS 或 Trojan,配中转或专线。

理由:流媒体是长连接、持续大流量,带宽稳定性优先。TCP 系协议在带宽充足时能跑满;专线或优化中转能避开晚高峰的出口拥塞。如果所在网络对 UDP 友好,Hysteria2 也是可选项,它在丢包链路上的码率保持更好,不容易触发播放器的降档。站内观影解锁页有按平台整理的线路建议,以及码率与带宽的关系的详细说明。

联机游戏

推荐 Trojan 或 VLESS,选近端节点,不要开多路复用。

理由:游戏对延迟与抖动敏感,对带宽不敏感。TCP 系协议的延迟曲线更平;多路复用会把多条连接塞进一条隧道,一旦隧道丢包,所有连接一起卡(队头阻塞),表现为「整局游戏突然集体延迟」。

如果游戏本身需要 UDP 转发,确认客户端与服务端都开启了 UDP,否则会出现「能登录、进不去对局」的情况。延迟与丢包的更多实测思路见游戏场景的延迟与丢包分析。

大文件下载与更新

推荐 Hysteria2。

理由:下载是纯吞吐场景,对延迟不敏感。在高丢包链路上,QUIC 系的吞吐优势最明显。代价是 CPU 占用高,在低功耗设备上可能反过来成为瓶颈——如果下载时发现速度上不去、CPU 却跑满,那就是设备算力先到了上限。

移动端长时间待机

推荐 Trojan 或 VLESS。理由见电量那一章:QUIC 系的周期性保活会持续唤醒射频。安卓端的后台保活与省电策略另有细节,可参考安卓端的实测对比。

弱网环境

推荐 Hysteria2 或 TUIC。

理由:弱网的典型特征是丢包率高、抖动大。TCP 系协议在这种情况下会反复收缩拥塞窗口,表现为「速度忽高忽低」;QUIC 系的拥塞控制对随机丢包不敏感,速度更平稳。公共场所的 Wi-Fi、移动网络信号只有一两格、高铁上,都属于这一类。

需要同时用 AI 工具时

AI 工具的接口调用是短请求,但单次响应可能很长(生成式回复是流式返回)。这类场景对首包延迟敏感、对带宽要求中等,推荐 VLESS 或 Trojan 配中转线路。更多细节见站内的AI 工具专题。

分层排错与自检

排错的核心是分层:把「能不能连」和「快不快」分开,再把「快不快」拆成延迟、丢包、带宽三块。每层只改一个变量,才能知道是哪一步起了作用。

第一层:确认流量真的走了隧道

显示「已连接」不等于流量真的走了线路。三种验证方法:

1. 查出口 IP:连接前后各查一次,应该不同,且归属地应该是线路所在地区。
2. 查 DNS:解析请求应该由隧道内的解析器处理,而不是本地运营商。如果 DNS 走了本地,会出现「能连上但部分站点打不开」。
3. 分应用验证:如果开了分应用代理,确认目标应用在代理列表里。

完整步骤见站内文章怎么确认 VPN 真的生效了。命令行下可以这样查:

# 1. 查当前出口 IP(示例地址,替换成任意返回纯文本 IP 的服务)
curl -s https://example.com/ip

# 2. 看当前使用的 DNS 服务器
nslookup example.com
# 输出里 "Server:" 后面就是实际使用的解析器地址

# 3. 连续探测,看抖动而不只看平均值
ping -c 20 example.com

注意 ping 走的是 ICMP,部分线路对 ICMP 的优先级与 TCP 不同,ping 正常不代表 TCP 正常,反之亦然。要测 TCP 的往返,用 curl 看各阶段耗时:

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

这几个数字能直接告诉你时间花在哪一段:如果 time_namelookup 很大,是 DNS 问题;如果 time_connect 大,是 TCP 握手或链路问题;如果 time_appconnect 比 time_connect 大很多,是 TLS 握手慢,通常是线路往返太长或者证书链太长。

第二层:连不上

按顺序检查,不要跳步:

• 订阅是否过期:流量用尽或到期后,客户端仍显示「已连接」,但所有请求都会被拒绝。这是最常见也最容易被忽略的一条。
• 设备时间:VMess 依赖时间戳校验,时间偏差过大会直接认证失败。开启自动同步。
• 协议与端口是否匹配:服务端配置改了而客户端订阅没更新,是常见原因。重新拉一次订阅。
• 本地防火墙:某些安全软件会拦截非标准端口的出站连接,表现是所有线路都连不上。
• 证书:Trojan 与 VLESS over TLS 依赖证书。证书过期时,客户端会报 TLS 握手失败,而不是「连接超时」。

第三层:连上但慢

1. 换线路:同一条线路在不同时段的表现差异很大。先换一条拓扑不同的线路对比。
2. 换协议:在同样的线路上换协议。如果 TCP 系慢而 QUIC 系正常,说明链路上有丢包。
3. 看时段:记录变慢的时间点。如果固定在晚间,是出口拥塞;如果全天如此,是线路本身的问题。
4. 看单连接:用单线程下载测试。多线程快、单线程慢,说明存在丢包或缓冲区膨胀。
5. 看 MTU:QUIC 对 MTU 敏感。路径 MTU 黑洞的表现是「握手成功、小请求正常、大请求卡死」。把 MTU 调低(例如 1280)再试。

第四层:只有部分应用有问题

• 分应用代理列表是否包含该应用。
• 应用是否使用了自己的 DNS 或加密 DNS,绕过了隧道内的解析。
• 应用是否强制走 IPv6,而隧道只代理了 IPv4。
• 应用是否使用了证书固定,对中间代理不兼容。

这一层的排查成本最高,因为每个应用的网络行为都不一样。有效的办法是先用浏览器验证隧道本身没问题,再逐个应用排查。

参数速查与常见误解

最后一章把客户端里那些开关逐个说清,再列几条常见的误解。这一章可以当工具页用,遇到不确定的选项回来查。

客户端里的那几个开关

• TLS:开启后流量外观是 HTTPS。Trojan 与 VLESS 必须开;Shadowsocks 与 VMess 可以套 TLS,但会多一个往返。
• XTLS 与 Reality:VLESS 的两种传输优化。前者减少加解密层的拷贝,后者让服务端在没有自有证书的情况下也能呈现真实的 TLS 特征。两者都需要服务端配合,客户端单方面开启无效。
• 多路复用:把多条连接复用到一条隧道。降低握手次数,但在丢包链路上会引入队头阻塞。网页浏览可开,游戏与语音不建议。
• UDP 转发:决定 UDP 流量是否走隧道。游戏、语音、部分视频通话依赖它。关闭后这些应用会直连或不可用。
• 拥塞控制:QUIC 系协议通常可选。基于带宽建模的算法在高丢包链路上吞吐更好,但在真拥塞时对其他流量不够友好。
• 分应用代理:只让指定应用走隧道。省电、减少干扰,但配置不当会出现「某个应用连不上」。
• 订阅自动更新:定期拉取最新线路。建议开启,但不要设得太频繁,否则每次更新都会短暂中断。

六条常见误解

误解一:协议越新越快。协议决定的是开销与抗丢包能力,带宽上限由线路与落地决定。在一条干净的低丢包链路上,六种协议的吞吐差距远小于线路之间的差距。

误解二:加密越强越慢。AEAD 类加密在现代处理器上开销很小,真正的瓶颈是链路。把加密从 AES-256 换成 ChaCha20,在手机上可能有可测量的差异,在桌面上基本感知不到。

误解三:延迟低就一定快。延迟影响的是「开始」的速度,吞吐还取决于丢包与拥塞窗口。一条往返 40 毫秒但丢包百分之二的线路,下载速度可能不如一条往返 80 毫秒但几乎不丢包的线路。

误解四:UDP 一定被限速。取决于具体网络环境,不能一概而论。判断方法很简单:在同样的线路上分别用 TCP 系与 QUIC 系协议做单线程下载,对比结果。

误解五:多层代理更安全。叠加多层只会增加延迟与故障点,不会提升单层加密的强度。需要的是正确的协议配置,不是层数。

误解六:连接数越多越快。浏览器的并发连接数是有限制的,超过之后新连接会排队。多开客户端、多开隧道只会互相抢带宽。

把这份手册用起来

如果你刚决定要试,先看套餐页确认档位:月订阅 ¥9.9 含 60GB、¥18 含 250GB、¥28 含 500GB,流量按开通日每月重置,中途升级差价折算成剩余天数;另有流量包 ¥158/300GB、¥358/1000GB、¥658/3000GB,用完为止,永久不过期。所有套餐都不限台数,支持支付宝、微信、USDT,注册无需邮箱地址,用户名加密码即可。首次付费后 7 天内可申请无理由退款。

如果你已经买好了,按使用教程走一遍导入流程,再回来按场景挑协议。想先了解服务本身的定位与原则,看关于本站。