VPNHO 协议与线路详解

连接指标：先拆开一次跨境访问

客户端连接，不等于应用已经完成访问

一次访问可以分成几个交接环节：应用发起请求，客户端按规则决定是否代理，连接进入节点，再由出口访问目标服务。客户端显示已连接，通常只说明代理通道已经准备好；目标网站是否接受出口、域名是否正确解析、应用是否采用系统代理，仍要另行确认。将这些环节混在一起，就容易把账户错误、解析失败或应用分流误判为协议性能问题。

首次打开网页时，域名解析、传输连接、加密握手和目标服务器处理都可能增加等待。后续访问若复用了已有连接，体感会明显不同。比较协议时，应区分首次访问与持续使用：首次访问更能反映建立连接的成本，连续翻页或长时间播放更能反映连接复用与持续传输表现。拿刚启动的客户端与已经预热的客户端相比，结论通常不可靠。

延迟表示往返等待，带宽表示通道可承载的传输能力，吞吐量则是应用实际收到数据的速率。它们相互关联，但不能互相替代。下载较快的线路可能在交互操作时等待明显；往返较短的线路也可能因为拥塞而无法持续供给视频。选型前先写清目标：网页响应、文件传输、直播连贯或会话稳定，观察指标才有方向。

连接建立、资源占用与稳定性分别观察

协议自身的握手只是建立连接的一部分。底层采用 TCP 还是 QUIC、是否叠加 TLS、有没有额外传输封装，都会改变交换过程；节点认证、客户端实现和连接复用也会影响结果。因此，不能仅凭协议名字排列固定的快慢顺序。同名协议在不同传输方式下的表现，可能比不同协议之间的差异更大。

资源占用包括加密计算、内存缓冲、连接管理以及网络接口活动。桌面设备的计算余量较大，通常更需要关注路径质量；移动设备还要考虑无线接口维持活跃、后台唤醒和重连。看到客户端耗电上升时，不宜立刻归因于加密算法。弱信号、频繁切网、持续上传和过密保活都可能让电量表现变化。

稳定性也需要拆开记录。通道断开、应用请求超时、视频缓冲、登录状态失效，分别指向不同层面。建议记录发生时的网络环境、线路名称、协议、目标应用和现象，同时保留客户端错误摘要。记录中不要复制订阅地址或认证信息。这样换线后才能判断是哪一环节改善，而不是只留下“这条不稳定”的模糊印象。

建立一个可复核的比较基线

比较时保留同一设备、同一接入网络和同一目标任务，关闭正在抢占传输的后台任务，并尽量避免同时改变出口地区与协议。若面板没有同路径的不同协议选项，就只能比较完整线路方案，不能将结果表述成纯协议对比。首次请求与持续请求分别记录，缓存命中、已建立的会话和目标服务负载也要纳入解释。

Shadowsocks 与 VMess：封装和认证的取舍

Shadowsocks：较直接的代理传输模型

Shadowsocks 的核心用途是将应用流量交给加密代理通道，再由远端代理访问目标。它通常不把完整的网络接口直接暴露给应用，是否覆盖整机流量取决于客户端的系统代理、隧道模式和分流规则。看到订阅里出现 Shadowsocks，只能确认节点使用这一代理协议，不能据此判断所有应用已经进入通道，也不能推断具体采用了哪种加密方法。

其传输结构相对直接，理解和定位问题时可以优先核对地址、端口、加密方法与认证参数。采用现代认证加密的实现，会同时处理内容保密与完整性验证；但具体安全属性仍取决于算法、密钥管理和实现维护。不要将“支持某协议”当作加密配置已经正确的证据，也不应自行把订阅中的加密方法换成网上推荐项，服务端不匹配时连接会失败。

资源表现方面，封装较少往往有利于减少额外处理，但真实开销还受到硬件加速、客户端内核、连接数量和流量形态影响。浏览网页与持续传输文件的负载不同，移动端后台维持通道的成本也不等于前台加密成本。选用 Shadowsocks 时，更有价值的检查是应用是否走对规则、UDP 是否被正确转发，以及线路本身能否满足任务。

VMess：认证信息与传输层组合

VMess 在代理会话中定义了认证和数据处理方式，也常与不同的底层传输组合使用。用户看到的节点名称可能只标注 VMess，却没有说明传输封装、TLS 或其他连接选项。这些组合会影响握手路径和中间设备的处理方式，因此排错时需要阅读客户端实际导入的节点详情，而不是只看列表里的协议胶囊。

认证参数错误、客户端兼容性不足和系统时间异常，都可能导致会话建立失败。其中，系统时间问题容易被忽略：浏览器能正常打开普通网站，并不代表依赖时间相关校验的代理认证一定正常。若日志集中出现认证失败，应先检查账户订阅是否有效、设备时间是否由系统正常同步，再刷新订阅核对配置，不要直接把问题归为晚高峰拥塞。

额外传输封装可能增加处理步骤，也可能为特定部署提供适配能力。是否值得采用，应由所处网络和服务端配置决定。把多层封装理解为“层数越多越稳定”并不准确：每层都有自己的超时、缓冲和连接生命周期，排错也更复杂。保留面板提供的配置，可以避免客户端与服务端在路径、主机字段或传输设置上产生不一致。

如何比较，如何处理兼容性问题

在选择两者时，先确认客户端能够完整识别订阅，而不是仅显示节点名称。导入后若某个节点出现不支持字段或无法识别的传输类型，应从用户面板获取受支持客户端，或选择面板中已有的兼容节点。不要手工删去陌生字段让配置“通过检查”，因为被删除的字段可能正是服务端要求的认证或传输条件。

若相同任务在两类节点上表现不同，先核对它们是否使用相同出口和线路类型。一个走中转、另一个走专线时，拓扑差异足以改变结果。只有其他条件基本一致，才适合讨论协议和实现开销；条件无法一致时，就把结论记为节点方案比较。对普通使用者而言，能稳定完成任务的兼容方案，比抽象的协议排名更有参考价值。

UDP 相关应用还需要额外验证。客户端支持某协议，不等于当前转发链条对 UDP 的处理完整；系统代理也未必覆盖应用的 UDP 流量。若网页正常而实时互动应用异常，优先检查客户端模式、规则和节点的 UDP 能力，再排查出口路径。技术细节可与线路列表中的线路类型说明对照，避免仅换协议而保留原来的路径问题。

Trojan 与 VLESS：认证和加密不是同一层

Trojan：理解 TLS 在连接中的作用

Trojan 常借助 TLS 建立受保护的传输通道，再在通道中完成代理认证与请求。TLS 的用途是保护传输内容并验证服务器身份，代理认证则决定用户是否有权使用节点，两者不是同一个步骤。服务器证书验证失败与代理密码错误会产生不同的排错方向；将它们统一处理为“节点不可用”，会错过可以直接修复的配置问题。

证书校验会涉及服务器名称、信任链和有效期。订阅中提供的服务器名称字段，应与服务端部署相匹配，不宜自行改成节点地址或随意填写域名。遇到证书错误，应先检查系统时间、订阅是否更新、客户端是否受支持，然后通过工单核对节点配置。关闭证书校验虽然可能改变报错结果，却也改变了服务器身份验证，不适合作为长期解决方案。

TLS 握手会增加首次建立连接时的交换与计算，但持续连接可以摊薄这部分成本。浏览器和客户端是否复用连接、任务是否频繁创建短连接，都会影响体感。长时间传输时，路径拥塞和出口处理能力往往更加重要。因此，不能将 TLS 握手存在，直接解释为 Trojan 持续速度一定较低，也不能把首次打开较快当成整体稳定性保证。

VLESS：轻量认证不等于自带完整加密

VLESS 侧重较轻量的代理认证和请求处理，其协议层本身不承担完整的数据加密职责。部署时需要结合适当的安全传输方案，才能讨论通道的内容保护。仅知道节点采用 VLESS，不足以判断它的安全属性、建立连接过程和资源开销；还要核对底层传输以及服务端要求的相关设置。

这也是为什么同为 VLESS 的节点，可能在不同客户端上出现兼容性差异。客户端需要理解整个配置组合，而不只是识别协议名称。面板提供的服务器名称、传输选项与认证字段之间可能存在关联。若只复制地址和用户标识，遗漏其他字段，节点即使显示在列表里，也可能无法完成连接。推荐采用完整订阅导入，而不是凭记忆重建配置。

讨论轻量化时，应区分协议头部开销、加密计算和客户端调度。减少协议层工作，不会消除底层安全传输的成本，也不会缩短物理路径。对大量短请求而言，连接复用策略可能比头部长度更有影响；对持续视频而言，稳定供给数据通常比首次握手差异更重要。选型需要跟随任务，而不是把“轻量”当作万能结论。

从错误发生的位置决定下一步

若连接在证书阶段失败，先处理身份验证与配置一致性；若已进入代理认证阶段，再检查订阅有效性与认证字段；若通道建立后只有特定网站失败，则检查应用分流、解析和出口接受情况。这样的顺序可以减少无效换线。客户端日志中不同错误词的含义可能随实现变化，应结合发生阶段阅读，不宜只截取一句报错就下结论。

VPNHO 的银行级加密是服务信任话术，技术核对仍应落实到客户端受支持、订阅参数完整和安全验证正常。加密保护传输，不替代目标网站的账户安全或设备系统维护。也不要在排错时将认证信息发送给陌生的在线配置工具；确需协助时，使用面板工单，提供去除敏感字段后的错误摘要与操作过程。

Hysteria2 与 TUIC：基于 QUIC 的传输思路

UDP、QUIC 与应用数据的关系

UDP 提供数据报传输，不像 TCP 那样直接提供按序可靠字节流。QUIC 在 UDP 之上实现安全连接、可靠传输和流管理，因此“基于 UDP”不等于应用数据允许随意丢失。Hysteria2 与 TUIC 使用 QUIC 相关机制承载代理流量，但具体认证、拥塞控制和转发策略并不相同，不能把它们视为只换了名称的同一种协议。

QUIC 可以将多个逻辑流放在同一连接内，减少某个流的数据丢失对其他流按序交付的直接阻塞。不过，流仍共享路径容量与拥塞状态。若接入网络持续丢包、出口带宽被占满，其他请求仍然可能变慢。多流机制改善的是传输组织方式，不会创造额外带宽，也不保证任何应用在高峰时段都保持同样表现。

接入网络是否允许稳定的 UDP 通信，是选择前需要检查的边界。部分办公、校园或访客网络可能对 UDP 有特殊处理；设备上的其他网络工具也可能改变数据报路径。若 TCP 类节点正常而 QUIC 类节点无法建立连接，应优先怀疑传输可达性与客户端支持，而不是继续调高传输参数。保留兼容的备用线路，通常比强行修改配置更有效。

Hysteria2：吞吐目标需要匹配真实路径

Hysteria2 的设计关注在具有延迟或丢包的路径上组织传输，并具有与带宽估计或拥塞控制相关的配置选择。不同实现和服务端设置会决定哪些选项生效。用户不应把网上给出的带宽值照搬到客户端：过于积极的发送目标可能使接入链路形成排队，影响其他应用；估计过于保守，则可能无法充分利用可用容量。

相关参数应理解为传输策略输入，而不是运营商带宽证明，也不是本服务的速度承诺。节点名称中的协议标注不能说明服务端使用哪种具体策略。通过订阅获得的配置应先保持原样，完成实际任务验证；确有异常时，再核对面板说明与受支持客户端的设置。直接提高数值而不观察排队、丢包和应用响应，容易把下载变化误当成整体优化。

长时间下载与网页交互同时进行时，特别适合观察这种边界。若文件进度较快，但网页和实时会话明显等待，问题可能是本地接入或路径队列被持续占用。可以暂停下载复核交互响应，再检查是否存在上传占满或背景同步。此时应调整负载与选线策略，不必立即把所有现象归结为 Hysteria2 的协议缺陷。

TUIC：流管理、认证与连接生命周期

TUIC 同样基于 QUIC 组织代理连接，涉及认证、可靠流与数据报转发等机制。其具体表现与客户端和服务端是否兼容、协商是否成功、所用拥塞控制策略有关。某些实现可能提供提前发送数据或连接复用相关选项，但是否启用、能否生效应以实际配置为准。不能从协议名直接推断首次连接一定更快，更不能把不同实现的测试结论无条件迁移。

移动网络切换时，QUIC 的连接标识与路径验证机制为连接迁移提供基础，但是否真正保留会话，还受到实现支持、地址变化、网络策略和代理链条影响。后台被系统暂停、服务端会话超时或新网络限制 UDP，都可能导致重建连接。因此，“采用 QUIC”不等于从无线网络切到移动网络后所有应用会话都能连续保留。

选择这类协议时，建议按建立连接、持续交互、持续传输和切网恢复分别检查。先确认可以正常建立通道，再观察目标应用，不要只看客户端内的节点测试结果。若任务是上传材料或参加实时会议，成功送达与会话连贯更重要；若任务是持续观看视频，则重点看缓冲恢复。通用对比只能帮助提出假设，最终仍要在实际接入网络验证。

直连、中转与专线：线路如何交接

直连：路径简单，但质量取决于实际路由

直连通常表示本机直接连接远端入口，不经过服务提供方额外设置的中转入口。这里的“直接”是服务拓扑描述，不代表网络中没有运营商路由器，也不代表物理路径最短。互联网会依据运营商互联和路由策略转发，地理距离较近的节点，实际路径也可能绕行。因此，看地图距离只能形成初步预期，不能直接推断延迟。

直连的好处是交接环节较少，排错时更容易区分本地接入和远端节点问题；但它会更直接受到公网互联、跨网拥塞和路由变化影响。如果白天正常而高峰期间持续变慢，可能是共享路径资源的变化。此时换成另一个协议但保留相同入口和出口，未必能改变瓶颈，因为问题发生在代理协议之外的网络链路。

还要区分代理入口与最终出口。应用看到的是出口访问目标服务的身份，而客户端建立连接的是入口地址，两者未必位于同一位置。节点名称往往是方便用户选择的标签，不是完整网络拓扑。判断目标平台是否接受访问，应核对实际出口与账户条件；判断建立连接是否顺畅，则更需要关注本机到入口的路径。

中转：增加一段交接，换取路径选择空间

中转将本机流量先交给入口或中转节点，再送往远端出口。增加一段并不必然增加最终体感等待：若原有公网路径绕行严重，而中转后的路径更顺畅，整体交接反而可能更合适。但中转也增加了需要维护的环节，入口拥塞、转发队列和中转到出口的连接都可能成为瓶颈，不能只凭线路类型宣称固定优势。

中转线路出现问题时，应比较同入口不同出口与不同入口同地区的节点。如果同入口的多个出口同时异常，入口或共享中转段值得优先检查；若只有一个出口异常，则可能是出口负载、远端互联或目标服务接受情况。面板未展示完整拓扑时，不要自行猜测具体机房，可以向客服提交现象对照，帮助定位共享路径。

对用户而言，入口所在地与出口所在地承担不同职责。入口主要影响接入交接，出口主要影响目标服务访问和地区识别。选择流媒体或 AI 工具时，要以出口是否符合目标平台条件为准，而不是以中转入口名称判断服务地区。线路列表中的地区标签应与面板说明结合阅读，遇到含义不明确的标签，应先确认再形成选型结论。

专线：看清专用承载覆盖到哪里

IEPL 专线通常指线路中的专用以太网承载部分，用于连接不同位置的网络端点。它与公网中转的资源组织方式不同，有助于服务方控制特定承载段的交接质量；但用户本机到接入点、出口到目标服务仍可能经过其他网络。专线标签不意味着端到端所有环节独占，也不能替代目标服务的账户、版权地区或访问规则。

VPNHO 覆盖 120+ 国家 / 210+ 线路，具体节点、地区和线路类型请查阅线路列表并以面板可用项为准。不要把覆盖范围理解为所有地区拥有相同拓扑或相同服务接受能力。选线时先确定出口用途，再比较入口接入和高峰表现；长期使用可保留已验证的主线路与不同路径的备用线路，避免备用方案与主线路共享同一个瓶颈。

丢包与晚高峰：从排队位置定位问题

拥塞不是一个笼统的“速度下降”

拥塞发生在某段路径收到的数据超过其当时可处理的能力时。数据可能先进入队列等待，队列继续增长后再被丢弃；用户感受到的则可能是网页迟迟没有响应、视频缓冲或上传停顿。晚高峰是观察共享资源变化的常见时段，但并不是诊断结果。瓶颈可能位于家庭路由器、接入网络、运营商互联、中转入口、出口或目标服务。

上传占满尤其容易造成误判。同步文件、备份照片或发送材料，会让本地上行队列变长，影响其他连接所需的小数据包与确认信息。表现可能是下载和网页一起变慢，实际上出口线路并没有改变。排错时先暂停背景传输，并在同一接入网络复核；若暂停后恢复，就应处理本地负载，而不是连续切换远端节点。

无线信号弱、干扰和接入点拥挤也会导致重传与等待。代理客户端无法直接修复无线链路的问题。可以在设备允许时靠近接入点，或使用更稳定的接入方式对照，保持出口和任务不变。如果所有节点都在同一接入环境异常，换接入网络后恢复，本地链路便比协议差异更值得调查。这样的对照比只刷新测速更有解释力。

丢包、重传与队头等待

丢包可能来自拥塞，也可能来自无线误码、设备处理或网络策略。可靠传输会尝试恢复缺失数据，但恢复需要时间，并可能触发发送节奏调整。TCP 按序交付字节流，前面的数据缺失会让后续字节暂时无法交给应用。若多个应用请求又被封装在共享连接中，阻塞表现会受客户端复用策略影响，不能仅从某个网页等待判断是哪层丢包。

QUIC 将流的交付组织得更独立，但流共享的拥塞控制与路径容量仍然存在。持续损失会拖慢整体传输，也可能增加设备处理与网络活动。选择基于 QUIC 的方案可以作为验证方向，却不是所有丢包的通用修复。先确认 UDP 路径稳定，再比较实际任务；若换协议同时换了出口，必须承认路径变化也参与了结果。

隧道封装还会占用数据包空间。路径能够承载的包大小与客户端封装不匹配时，可能出现小请求正常、大请求停顿的现象；分片或相关控制消息被特殊处理时，问题更明显。遇到这类情况，先核对受支持客户端的默认配置与接入环境，不要随意照搬网上的 MTU 数值。修改包大小属于有针对性的排错，需要保存原值并复核任务。

用交叉对照缩小范围

可以先比较普通网络访问与代理访问，再比较不同出口，最后比较另一种接入网络。普通访问也异常时，本地或接入侧优先；同入口多个出口异常时，共享入口段优先；只有特定目标失败时，目标服务与分流优先。这个顺序不是绝对诊断，但能减少改动变量，让工单记录从“都很慢”变成有条件、有对照的现象描述。

时段记录也应保持任务一致。白天打开已缓存网页、晚上观看实时直播，并不能证明高峰线路退化。最好重复相同操作，记录首次响应、持续传输和失败阶段。节点测试里的往返结果只反映它使用的测试目标与方式，不一定代表真实应用路径。不要把某次测试的小幅变化描述成服务整体质量变化，尤其在任务没有明显差异时。

持续异常时，保留去敏后的客户端错误、接入网络类型、节点标签、目标应用和复现步骤，通过面板工单提交。说明换线与换接入后的结果，通常比附上一张没有上下文的截图更有用。观看赛事的用户还可参考体育直播线路选择说明，把实时播放中的缓冲与播放器策略一起判断。

平台与电量：后台行为也属于连接条件

移动端耗电来自计算与网络活动

移动端电量表现不仅由协议加密决定。无线接口维持活跃、后台保活、反复重连、持续数据传输和信号强弱，都会参与耗电。某协议在前台持续下载时表现较好，并不代表锁屏待机时也更省电。比较前应分清任务：长时间播放、频繁短请求或后台待机；不同任务的负载形态不同，不能混在同一条“省电排名”里。

保活用于维持连接或让网络设备知道会话仍存在，但过于频繁可能增加唤醒和无线活动。间隔过长又可能使中间设备回收闲置状态，后续访问需要重新建立连接。实际参数应采用受支持客户端与服务端提供的配置，不宜照搬其他网络的经验值。若锁屏后频繁失效，应先检查系统后台策略与网络切换，再考虑协议层保活问题。

移动网络与无线网络切换会改变地址、路由和接口状态。即便代理通道恢复，应用原有连接也可能需要重新建立，上传中的任务可能要求重新提交。观察恢复时应区分客户端重连成功和应用会话连续。重要操作前先确认当前网络稳定，避免在上传、支付确认或实时会议期间主动切网；协议选择无法代替应用自身的恢复机制。

Android 与 iOS 的后台边界

Android 设备的省电与后台管理会因系统和设备设置不同而变化。若前台正常、锁屏后断开，先检查客户端的后台运行权限、省电限制和网络权限，并确认是否存在其他网络工具争用同一隧道。解除限制也要有选择，围绕连接任务调整，不必把所有应用都设置为无限制。详细操作可结合安卓后台保活与分应用代理说明查阅。

分应用代理可以减少不必要的流量进入线路，也让本地应用继续使用原有路径，但它需要符合实际业务依赖。某应用可能通过外部浏览器完成登录，或调用系统组件上传材料；只代理主应用而遗漏相关组件，可能导致登录返回失败。规则调整后，应把完整任务走一遍，而不是只确认应用首页可以打开。

iOS 的网络扩展与后台行为由系统管理，客户端能提供的设置未必与桌面端相同。锁屏、网络切换和系统资源安排都可能影响连接生命周期。遇到异常时，检查受支持客户端的连接状态与系统网络权限，避免套用 Android 的后台设置思路。也不要把系统界面显示的通道标记当作所有应用流量都已经代理的证明。

桌面端也需要验证实际应用路径

Windows、macOS 与 Linux 上，系统代理通常只影响遵循相应设置的应用；命令行工具或独立网络组件可能使用自己的代理参数。隧道模式能够覆盖更广的流量，但需要适当权限和路由配置。若浏览器正常而终端失败，优先检查它们是否采用相同路径，不要直接换节点。Windows 新用户可先阅读从客户端到开机自启的操作指南。

VPNHO 支持 Windows / macOS / iOS / Android / Linux，同时在线不限台数，但各设备仍需使用适配客户端并单独验证规则。客户端通过用户面板获取。将一个设备的结果当作全部平台的结果并不稳妥；完成前台任务、锁屏恢复和切网复核后，再决定长期保留的协议与备用方案。

场景选型：把推荐变成可复核的交接记录

从目标任务决定优先级

网页浏览与网课平台通常需要稳定完成短请求、登录和资源加载，优先检查首次响应与连续操作是否顺畅。文件传输更关注持续吞吐和长连接恢复，实时会议则要关心数据报路径、抖动和切网影响。这里没有统一的协议冠军：先用受支持的默认方案完成任务，发现明确瓶颈后，再决定是否需要改变协议或线路拓扑。

AI 工具的登录、生成请求、流式返回与文件上传可能走不同接口。首页可访问，不代表完整工作流都已完成；出口是否被目标平台接受，还受平台政策与账户条件影响。验证时应覆盖实际任务，观察失败发生在登录、提交还是持续返回阶段。专题说明见AI 加速，本页只负责解释如何区分协议、路径与应用层问题。

流媒体也需要分别验证平台访问、账户登录、内容可见和持续播放。某出口能打开平台，不等于全部内容可观看；地区、账户与版权条件仍由平台决定。持续播放异常时，先观察缓冲与恢复，再对照时段和路径；仅在开始播放时失败，则更需要检查目标平台接受情况。可结合观影解锁说明阅读，不将线路标签理解为永久保证。

保留主方案与真正不同的备用方案

主方案应是实际网络中已验证的稳定组合，而不是名称最复杂的组合。记录客户端模式、协议、出口地区与线路类型，以及适合的任务。备用方案尽量在主要瓶颈上有所区别，例如不同入口或不同承载路径；两个名称不同却共享相同入口的节点，可能在同一故障中一起受影响。面板未说明共享关系时，不要自行编写拓扑结论。

比较协议时尽量固定路径，比较拓扑时尽量固定任务。每次切换后先完成基本连通，再复核目标应用，最后观察持续使用。若应用保留旧连接或缓存，切线后可能暂时仍沿用原状态；应按应用的正常方式重新发起任务，必要时重启应用，但不要在未保存工作时强制关闭。记录要能让同事重复操作，而不是只写主观感受。

出口与 DNS 的验证属于另一条检查线。域名由哪里解析、应用是否自行使用加密解析、客户端分流是否命中，都会影响结果。一个查询页面不能证明所有应用路径相同，单次解析结果也不能概括完整隐私状态。可以参考出口 IP、DNS 与分应用验证，将连通检查与路径检查分开完成。

技术选型与套餐选型分开处理

协议不会替代套餐容量管理，也不能仅凭名称判断流量消耗。持续视频、文件传输与重复上传都会使用流量，重试与封装也可能影响统计，具体以面板口径为准。VPNHO 月订阅为 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB；流量按开通日每月重置，中途升级差价折算成剩余天数。不要把容量档位自行解释成协议权限或速度档位。

间歇使用可对照流量包：¥158/300GB、¥358/1000GB、¥658/3000GB，用完为止，永久不过期。完整选择见套餐价格。支付方式为支付宝 / 微信 / USDT，30 天无理由退款；需要核对具体条款时查看退款政策。无需邮箱地址，使用用户名与密码即可创建账户，账户操作与订阅交付均在面板完成。

最后，把选型结果写成一份简短交接记录：设备与接入环境、客户端模式、节点标签、任务步骤、可观察结果、备用路径和待确认项。若仍有异常，再附上去敏后的日志摘要提交工单。这样后续换网络、换设备或更新订阅时，都可以沿用同一套复核方法。长期可用的依据是任务重复完成，而不是某次测试数字或某个协议名称。