协议与线路
技术参考

连接分层：协议、线路与应用

先画出实际请求经过的路径

一次跨境请求通常从应用发起，经过系统网络接口、客户端的代理或虚拟网络接口、本地接入网络、服务入口、出口网络，最后抵达目标服务。应用是否进入客户端，取决于系统代理、路由规则与分应用设置；入口是否可达，取决于当前接入网络与线路路径；目标是否响应，则还受目标服务自身状态影响。把这些环节统称为“节点速度”会丢掉重要信息，因为它们可能分别出现故障，也可能同时工作正常却组合出不理想的体验。

协议规定双方如何认证、封装与转发请求，线路描述请求实际走过哪些网络，客户端负责把应用流量送入正确路径。相同协议放在不同线路上，表现可能明显不同；同一线路换客户端，也可能因为规则、DNS 或后台策略产生差异。因此，选择协议之前，应先确认订阅已更新、目标应用确实经过客户端、当前地区与用途相符。否则，比较结果很可能只是两组配置的差别，而不是协议本身的差别。

区分代理协议、传输协议与加密层

Shadowsocks、VMess、Trojan、VLESS、Hysteria2 与 TUIC 的名称，不能直接当成完整连接栈。代理协议可能承载在 TCP 或 UDP 上，也可能叠加 TLS、WebSocket 或其他传输封装。TCP 提供可靠有序的字节流，UDP 提供数据报传递，TLS 用于建立经过认证的加密连接，而 QUIC 在 UDP 上实现安全传输与可靠流等能力。讨论性能时需要写清代理协议以及所用传输，否则同名方案之间也可能没有可比性。

加密与访问权限同样是不同问题。加密保护传输中的数据，认证决定谁可以使用服务，路由规则决定流量送往哪里。VPNRT 使用“军工级加密”作为安全主话术，但这不是一个可直接填进客户端的算法名称，也不能代替证书校验、账户保护与配置核对。技术排查应检查具体实现提供的认证方式、证书验证与密钥管理，不应从营销术语推导密码套件，更不能由此推断目标应用已经获得访问资格。

把体验拆成可以观察的阶段

页面打开慢，可能发生在域名解析、连接建立、加密握手、首段内容返回或后续资源加载阶段。视频缓冲更关注持续传输与出口到媒体服务器的路径；交互式工具则更容易暴露短请求等待、连接中断与上行不稳定。延迟只是请求往返所需时间，带宽是传输能力，丢包描述数据未能按预期抵达，抖动体现时延变化。它们相关但不等价，低延迟线路仍可能在持续下载时拥塞，而带宽充足也不保证首次打开页面迅速。

客户端的全局模式、规则模式与分应用代理，适合用来验证流量去向，不适合被当成永久排错结论。临时改成全局后目标恢复，通常提示原规则或解析路径值得检查；这不意味着所有应用都必须长期进入同一出口。尤其是支付、工作内网与本地设备访问，应按照实际业务保留合适路径。恢复规则模式后再检查目标域名的匹配结果，才能把问题定位到具体规则，而不是以扩大代理范围掩盖配置遗漏。

判断顺序是应用是否进入客户端、入口是否建立连接、出口是否抵达目标、目标是否接受请求。先确认在哪一层出错，再讨论更换协议。

记录问题时，保留目标应用、接入网络、所选地区、协议与传输方式、失败阶段及客户端错误摘要即可。分享诊断材料前应遮盖账户信息、订阅地址与认证字段。不要把完整订阅复制到公开讨论区。若尚不能判断协议与线路的区别，可先用服务器页面核对线路类型，再依照后文的受控比较方法排查。

流式协议：封装与加密取舍

Shadowsocks 与 VMess 的关注点

Shadowsocks 的核心是加密代理转发，通常以较直接的封装完成流量传递。常见 AEAD 方案同时提供机密性与完整性保护，但具体密钥派生、重放防护与会话行为需要看采用的方案及实现。它并非只支持 TCP，UDP 转发能力也要结合客户端和服务端核对。较少的外层封装有利于减少额外处理，不过实际资源占用仍取决于密码实现、硬件加速、数据规模与并发连接，不能仅凭名称宣布它最省电。

VMess 将认证与数据封装放在协议设计中，实际部署可能配合不同传输方式。某些实现与配置对系统时间和认证状态较敏感，因此出现认证类报错时，自动校时、订阅完整性及客户端兼容性都是合理检查项。它的资源成本不能脱离外层传输讨论：直接流式传输与叠加 WebSocket 的路径可能有不同开销，服务端负载也会影响结果。比较时应记录完整组合，而不是把所有 VMess 连接视为同一种性能方案。

Trojan 与 VLESS 的边界

Trojan 通常使用 TLS 提供外层安全连接，并在其中完成认证与代理请求转发。证书验证、服务端名称与系统信任链是连接是否成立的重要条件。握手失败不一定意味着账户无效，也可能是时间异常、名称不匹配或证书链问题。排错时应读取错误类型，不能为了让连接通过而直接关闭证书校验。TLS 的部署方式与会话复用会影响首次连接成本，因此“使用 TLS”本身既不是速度保证，也不是速度不足的充分原因。

VLESS 侧重较轻的认证与请求封装，其自身不提供与完整加密传输等同的保护，安全性必须结合底层和外层方案理解。把“轻量”解释成无需加密是不正确的，把它解释成一定比其他协议快也过于简化。相同代理名称可配合不同安全与传输配置，使用者应依照订阅导入，不随意删除加密层或修改服务端名称。实际选择看的是交付组合是否兼容当前客户端与网络，而不是单独看协议字段。

外层封装为什么会改变结果

WebSocket 可以让代理数据适配相关服务部署，但也增加了握手与帧处理环节。其他基于 HTTP 的封装可能影响连接复用、流控制与中间设备行为。多加一层不必然显著拖慢，也不自动带来稳定性提升；它解决的是特定部署约束。对使用者而言，最重要的是客户端能否正确处理这套组合，以及入口和出口路径是否合适。未经服务端支持而在本地替换传输方式，通常只会让双方无法理解彼此的数据。

“TCP 类协议”也不能与“只适合网页”画等号。很多视频和文件传输本来就使用可靠流，它们可以在健康的 TCP 路径上获得良好体验。真正需要关注的是丢包后的恢复、长连接保持、并发请求竞争与应用对 UDP 的需求。游戏或会议是否适用，应验证所需数据报有没有经过正确转发，不能仅凭网页能打开就认定其他业务正常。

选型时优先使用面板提供且客户端明确支持的组合。若两条候选线路的地区、入口与出口都不同，观察到的差异不应全部归因于代理协议。可先保持线路类型与目标任务接近，再比较连接成功、页面响应与持续传输。协议负责承载数据，但它不会消除物理距离、出口拥塞、目标服务限流或本地网络故障。

QUIC 协议：可靠流与 UDP 边界

QUIC 解决什么，又保留什么

QUIC 在 UDP 上提供加密传输、连接管理与多路流等能力。应用看到可靠流时，底层仍会检测丢失并进行恢复，而不是简单丢弃未到达的数据。它能减少不同流之间由传输层有序交付造成的相互等待，但某条流内部缺失的数据仍可能阻塞该流的后续交付。所有流也共享路径容量和相关拥塞状态，因此“多路复用”不是无限并行，更不意味着网络拥塞时每个请求都不受影响。

QUIC 具有连接迁移的设计能力，但是否能在接入网络变化后保持业务，还受代理实现、客户端状态、服务端策略与应用行为限制。不能据此承诺从无线网络切到蜂窝网络时任何任务都不会中断。它的握手和连接复用也提供优化空间，不过首次连接、恢复连接与已建立连接是不同状态。把热连接的结果拿去与其他方案的冷启动比较，容易把缓存和会话恢复误认为协议的固有优势。

Hysteria2 的传输与拥塞取舍

Hysteria2 基于 QUIC，面向代理场景处理可靠流与数据报转发。其拥塞控制和带宽相关设置是理解表现的重要部分，具体行为应以客户端和服务端实现为准。配置中出现带宽字段，不表示填写越高就能获得越多容量。对路径能力估计过于激进，可能把接入端或中间队列压满，表现为下载继续但交互变慢、上行等待或丢包增加。该现象应通过收敛参数与重新验证判断，不能只靠继续提高数值处理。

对于有一定丢包但 UDP 路径可用的接入网络，Hysteria2 可以作为比较对象；然而丢包原因仍然重要。随机无线干扰、拥塞丢弃和数据报过滤不是同一类问题。若当前网络不能可靠传递所需 UDP 流量，协议设计再合适也可能无法建立连接。反过来，能完成握手但大流量任务异常，则需要继续查看分片、路径 MTU、队列与拥塞控制，不宜把所有症状统称为 UDP 不可用。

TUIC 与数据报转发的适用条件

TUIC 同样以 QUIC 为基础，结合认证、连接复用及代理转发。其可靠流与数据报能力需要与客户端交付方式一起理解：应用的数据报可以通过不同机制承载，可靠性、延迟和开销之间存在取舍。它与 Hysteria2 的差别不能简化为一个固定速度排序，因为实现选择、拥塞控制、接入网络与服务负载都会参与结果。实用判断是目标任务能否稳定完成，以及同样环境下是否减少了可感知等待。

QUIC 在用户态实现的处理方式，使其资源占用容易受到实现优化、设备性能与并发规模影响。它可能改善某些网络下的体验，也可能在低功耗设备上产生不同的处理负担。持续传输时，加密、数据拷贝、丢包恢复与数据报处理都需要资源。不要因为传输栈较新就默认其更省电；应在相似任务和网络条件下观察设备发热、后台活跃与连接稳定性，避免用桌面表现代替移动端结论。

UDP 是承载方式，QUIC 是建立在其上的传输协议。QUIC 的可靠流会恢复丢失数据，但它无法凭空增加路径容量，也无法保证当前接入网络允许所需数据报通过。

如果 QUIC 类连接反复超时，可先确认订阅有效、客户端支持对应协议，再换接入网络复测。相同设备在其他网络正常，提示原接入路径值得调查；所有网络都失败，则应核对配置与服务端状态。对照一条面板提供的流式候选线路，可以帮助区分 UDP 路径问题与账户、解析或客户端问题。保留错误摘要，不要通过关闭安全验证或自行猜测端口掩盖原因。

连接成本：握手、复用与资源占用

冷启动和持续传输应分别比较

连接建立包含域名解析、到入口的传输握手、加密与认证、代理请求转发，以及出口到目标的连接过程。某些过程可以复用或并行，某些需要等待前序结果。因此“协议连接快”必须说明比较的是哪一段。客户端里的连通性测试可能只探测入口或指定测试地址，与真实应用连接目标并不相同。它适合筛掉明显异常的候选项，却不适合单独决定哪个方案最适合大型文件、视频播放或长时间交互。

冷启动指没有可复用会话和相关缓存时的连接，热连接则可能利用已经建立的传输、解析缓存或会话恢复。两者都反映真实使用，但不能混在同一组结果里。日常浏览会同时出现新连接与复用连接；长时间播放更偏向持续数据传递。测试时可分别观察客户端刚连接后的首次打开与后续重复操作，注明状态。只有保持比较条件一致，才能判断变化来自握手成本、路径质量还是应用缓存。

复用的收益与竞争

连接复用可以减少重复建立连接的开销，但也可能让不同任务共享同一传输瓶颈。若可靠数据被集中承载在单条有序流中，丢失可能让后续内容等待恢复；采用独立流的传输可以减少部分相互阻塞，不过各任务仍会竞争带宽。复用并非始终开启就更好，需要看实现、网络与任务类型。大量短请求可能受益，持续大下载与敏感交互共用路径时则应观察公平性，而不是只观察总下载量。

资源占用也不只等于处理器负载。客户端维护路由表、DNS 缓存、连接状态、规则匹配与日志，都会使用内存和处理时间；TUN 模式还可能增加数据包读写与系统接口处理。加密算法是否得到硬件支持、程序使用什么实现、后台是否反复重连，也会改变负担。即使协议相同，不同客户端和规则集也可能出现明显差别。因此，协议选型与客户端选型需要分别比较，避免把复杂规则的成本记在传输协议名下。

测试记录怎样避免误导

比较连接建立时，使用同一设备、同一接入网络、相同目标与相近时段，并尽量保持地区和线路类型相近。先记录应用操作，再记录协议与传输，不需要预设哪一个应当获胜。若刚切换线路，目标连接可能仍沿用旧出口，应等待应用重建连接后确认流量去向。浏览器缓存、应用预加载与后台同步都会干扰观察，必要时关闭无关任务，但不要为测试修改安全设置或清除不相关的账户数据。

观察资源负担时，短暂的处理器峰值不等于长期消耗高，某次内存增长也不一定是泄漏。可以查看任务结束后是否回落、空闲时是否持续活跃、连接失败时是否反复重试。若只有开启详细日志后负担增加，应先恢复正常日志级别再比较。若设备在直连任务中也明显发热，则应用本身、媒体解码或系统更新可能更值得检查。技术判断应解释现象，而不是挑一个协议作为所有设备问题的统一原因。

有关测试工具、时段与指标的具体组织，可继续阅读VPN 速度实测怎么做。这里不提供未经验证的性能排行，也不把某次连接成绩推广到其他网络。可靠的选型结论应包括测试任务、环境、观察阶段与失败边界，让之后的复测可以沿用同一口径。

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

地区名称只是出口信息的一部分

线路的地区标签通常帮助判断出口位置，但不能完整说明路径。连接可能先抵达服务入口，再通过中转或专用链路到达出口，最后访问目标。地理上更近的出口不一定有更短的实际网络路径，因为路由由运营网络之间的连接与策略决定。选线时应同时看入口可达性、跨境段、出口到目标的关系。若目标位于较远地区，近处入口仍可能方便连接，但完整请求的往返时间还包括后续路径。

直连通常指客户端直接连接相应入口，不额外经过服务提供的中转节点。其路径结构相对直接，但质量取决于当前接入网络到入口的路由与互联情况。中转则把客户端先送到较合适的入口，再转往出口；它可能改善不理想的跨网路径，也增加转发环节与潜在故障点。“少一跳一定更快”与“多一跳一定更稳”都不成立，因为多出的距离可能换来更合适的互联，少掉的环节也可能保留更拥塞的公共路径。

IEPL 专线解决的是哪一段

IEPL 属于专用连接的线路形态，理解时应关注它在整体路径中的覆盖范围。服务标签写有专线，不代表从用户设备到目标网站的每一段都由专用链路承载。本地无线接入、家庭宽带、进入服务的路径以及出口访问目标的网络，仍可能成为瓶颈。专线的选型价值在于相关传输段的路径与容量管理方式，而不是对所有应用作出绝对稳定承诺。实际感受还需要结合入口、出口及高峰时段复测。

VPNRT 的线路会话示意包括香港 IEPL 专线、新加坡 IEPL 专线、日本中转、美国直连、意大利中转与法国直连。这里的组合用于理解地区和线路类型，不提供静态延迟、带宽或平台可用结论。具体交付和地区信息请查看服务器页面与用户面板；不要从示意磁贴推断每种协议在每个地区都有对应入口，也不要从国家标签推断某项服务必然接受该出口。

路径诊断工具的解释边界

路由跟踪可以提供路径线索，但不能直接还原代理之后的所有环节。系统工具可能走本地默认路由，客户端探测可能只测入口，代理后的目标连接又属于另一段路径。中间设备还可能限制诊断报文，使某一跳不响应，却继续正常转发业务数据。因此，看到星号或中间跳延迟增加，不能马上认定那里故障。应结合最终目标、真实应用表现和测试流量是否经过客户端，避免把控制报文响应策略当成业务丢包。

若同一接入网络下多条不同出口都慢，应优先检查本地接入与共同入口；若同一入口的某个出口异常，则出口路径更值得关注；若只有一个目标异常，则继续检查出口到目标以及目标自身状态。切换线路时保留目标与任务不变，才能判断是地区差异还是任务变化。有关按地区、类型和用途选线的简化规则，可阅读VPN 线路怎么选。

建立候选线路集合时，应让它们具有不同的路径特征，而不只是不同显示名称。两个名称不同却共用入口和出口的条目，未必能够互相补足；不同拓扑的候选项则更有助于判断问题范围。候选项也需要在常用接入网络中验证，而不是只保存到收藏。保留适合日常交互、持续传输与特殊目标的选择依据，之后路径变化时才能及时重测。

丢包与晚高峰：恢复机制和排错

先判断丢失发生在哪里

丢包可能来自无线干扰、接入设备队列、中间链路拥塞、服务端负载、数据报处理限制或目标侧策略。可靠传输会尝试恢复缺失内容，所以用户看到的可能是停顿而不是明显错误。实时数据报应用则可能表现为声音断续、画面变化或动作反馈异常。两种表现都需要结合实际任务解释。不能因为下载最终完成就认定没有丢包，也不能因为会议不顺畅就认定代理协议失败，因为应用自己的编解码与服务状态同样会参与结果。

晚高峰通常意味着共享资源上的需求增加。家庭接入、跨网互联、服务入口和出口都可能拥塞，而这些瓶颈不一定同时发生。队列堆积时，数据还在传送，但新请求需要等待，形成“大文件仍在下载，网页却迟迟没有响应”的现象。此时继续增加并发可能让竞争更明显。合理方法是减少无关传输，观察交互是否恢复，再在相近时段比较其他路径；单次早间测试无法回答晚间稳定性问题。

区分队列等待与路径不可达

拥塞控制的作用是根据路径反馈调整发送行为，不是保证始终占满链路。TCP 与不同 QUIC 实现的反馈方式、恢复和控制策略可能不同，但都面对有限容量。参数太激进可能把队列压满，参数过于保守可能不能充分利用健康路径。使用者应优先保留交付配置，不根据测速网站的瞬时值随意抬高带宽设置。若客户端确实提供相关参数，应阅读其解释并只改变一个设置，验证交互与持续传输是否一起改善。

路径 MTU 描述能够沿路径有效传递的数据包大小。封装增加额外头部后，可供原始数据使用的空间发生变化；若路径中的相关反馈无法正常返回，可能出现小请求成功而较大传输卡住的现象。但这个症状并非 MTU 问题的专属证据，目标限流、缓存与服务负载也可能相似。排查应先检查客户端是否提供自动处理与诊断信息，再依据官方说明调整，不能套用一个未经验证的固定数值到所有设备和网络。

建立分支，而不是反复盲切

完全无法连接时，先看错误发生在解析、入口连接还是认证握手。解析错误优先核对 DNS 与域名，连接超时检查接入网络和入口，认证错误核对订阅、时间及证书相关信息。可以访问但持续传输停顿时，转向丢包恢复、拥塞、MTU 与出口容量；只有某个应用异常时，检查规则、应用连接缓存及目标状态。这样的分支能够减少无关操作，也避免用重装客户端代替每次定位。

本地对照应尽量保持设备与目标一致。若无线网络异常而有线或其他接入方式正常，提示本地无线或接入路径值得调查；若多个接入网络都只在同一候选线路上异常，才更有理由关注那条线路。对于接入环境不同的设备，不应直接比较协议成绩。排查期间还要注意其他设备的云同步与下载，因为它们可能共享上行，把交互请求和确认报文一起推入等待队列。

诊断工具的中间跳不回应，并不等于业务数据在那里丢失。应把真实应用的最终结果、入口连通和出口访问分别记录，避免单独使用某个探测结果下结论。

提交问题时，用“目标打开后持续等待”“握手报证书错误”或“切换接入网络后恢复”这样的观察描述，比只写“很卡”更有效。附上线路名称、客户端平台、接入类型与错误摘要，同时遮盖认证数据。若需要继续处理，可通过用户面板工单提供资料；不要在公开页面贴完整订阅。排错完成后恢复被临时修改的模式和日志设置，并复测原来的业务，而不是只确认探测图标变为正常。

移动端电量：后台、重连与分流

电量表现不是协议名称的固定属性

移动端耗电由无线通信、加密处理、应用任务、屏幕与系统后台管理共同决定。协议带来的影响只是其中一部分。持续下载会让无线接口和处理器保持活跃，短时间内反复发送保活或重试也可能延长活跃状态。某个协议在桌面设备上的处理负担较低，不代表在移动设备上同样省电，因为硬件能力、实现方式与系统调度不同。选型应比较相近业务与接入条件，而不是读取一个没有测试环境的协议省电排名。

后台连接需要在可用性与资源消耗之间取得平衡。过于频繁的保活可能增加无线活动，间隔过长又可能让中间网络清理空闲状态，导致恢复应用时重建连接。合理值取决于客户端、传输与接入网络，不宜照抄陌生配置。若应用回到前台后需要等待，应先判断是系统暂停了客户端、网络发生变化，还是原连接已失效。把所有后台等待都归因于协议，会忽略系统真正限制流量的环节。

Android 与 Apple 移动系统的检查方向

Android 的省电策略与后台限制可能影响 VPN 服务持续运行。客户端在前台正常、锁屏后反复中断时，应检查系统是否允许它按产品说明在后台工作，以及电池优化是否造成暂停。不同设备的设置入口可能不同，应按系统实际名称核对，不用不存在的统一菜单路径。必要的后台权限应给客户端，而不是把所有应用都加入例外。进一步的安装与保活操作可参考安卓 VPN 设置指南。

iOS 的网络扩展运行受系统管理，连接状态与普通应用前台状态不是同一个概念。切换接入网络、系统回收或配置变更时，网络扩展可能重新建立传输，目标应用自身也可能需要恢复请求。遇到回前台后无响应，应先确认系统 VPN 状态、客户端最近错误和应用连接是否重建，再讨论协议替换。不要用长期保持客户端界面亮屏来证明后台正常，那样改变了测试条件，也把屏幕消耗混进电量比较。

分应用代理与接入切换

分应用代理可以缩小进入代理的业务范围，减少不必要的流量处理，但节电效果取决于实际任务，并非开启后必然明显。若目标应用没有被包含，或其相关系统组件走了不同路径，可能出现界面部分加载、媒体失败或认证跳转异常。此时要查看应用与域名规则的对应关系。规则模式也可能按目标域名决定去向，分应用模式则按应用选择，两者作用位置不同，不能只看开关状态判断最终出口。

从无线接入切换到蜂窝接入时，原路径、地址与网络限制可能改变。支持连接迁移的传输也要看代理实现是否实际使用了该能力，应用则可能保留已失效的连接。测试时记录切换前后入口状态与目标恢复情况，不要把短暂恢复直接等同于服务故障。若只有接入切换会触发问题，可对照另一条传输类型不同的候选线路，并检查自动重连行为，而不是同时更换协议、地区与规则。

VPNRT 支持 Windows / macOS / iOS / Android / Linux，同时在线不限台数；这属于平台与账户事实，不表示所有设备的系统行为相同，也不保证所有客户端都有相同的分应用功能。客户端与订阅通过用户面板获取。使用同一账户比较设备时，应控制后台任务与接入网络，把系统差异、应用负担和协议表现分别记录。

场景选型：候选方案与复测记录

先定义任务，再筛选协议

日常网页访问关注首次响应、短请求和多域名资源加载，候选方案应优先满足客户端兼容、入口可达和目标路径合适。若常用网络上的流式方案已经稳定，没有必要只因为协议名称较新就替换。若经常遇到不同请求相互等待，可以比较复用方式或 QUIC 类候选项，但应保持地区与任务接近。判断依据是实际操作是否更顺畅，而不是客户端列表里哪一个字段看起来更先进。

流媒体与大文件更依赖持续传输和出口到目标的路径。选择时观察播放过程、拖动后的恢复以及较长任务是否连续完成，同时区分应用缓存与真实网络改善。服务访问还受地区、账户、内容授权与出口识别影响，不能从协议支持推断平台可用。需要相关信息时查看解锁支持页面，连接后按目标服务核验；这里不列未经事实支持的平台可用清单，也不把切换协议当成内容权限解决方法。

交互、会议与开发工具的判断方向

交互式工具更重视请求等待和连接连续性，持续吞吐很高却频繁停顿的路径可能并不适合。会议或实时业务还要核对数据报转发、上行负担及抖动，网页正常只能证明部分连接正常。开发工具可能同时涉及登录页面、接口请求、代码仓库与长连接，它们的规则去向不一定一致。遇到部分功能失败，应先确认相关请求都进入预期路径，再比较候选传输，避免只围绕主域名反复切换。

对存在丢包的网络，QUIC 类方案值得纳入比较，但前提是所需 UDP 路径可用、设备与客户端支持交付配置。对限制数据报或握手不稳定的接入环境，可用面板提供的流式方案做对照。对资源紧张的设备，则优先使用实现稳定、规则适度且后台行为可解释的配置。协议、地区、线路类型和参数应逐项变化；一次全部替换虽然可能恢复访问，却无法知道哪一项真正有效，也不利于下次复现。

让比较结果能在之后复用

复测记录应包括任务、接入网络、设备平台、客户端模式、候选地区、线路类型、协议与传输组合，以及观察到的失败阶段。对于成功任务，也注明是冷启动还是已连接状态。结果不必写成评分，可直接描述首次打开是否等待、持续传输是否停顿、接入切换后是否恢复。这样的记录能够解释为什么保留某个候选项，而不是形成没有条件说明的永久排名。路径或客户端发生变化后，应重新验证原结论。

失败记录应包含对照分支：是否只影响某个目标，是否只发生在某种接入网络，是否在其他线路恢复，是否伴随明确的认证或证书错误。把这些观察并列，可以判断下一步需要调整规则、检查本地网络还是联系服务支持。提交时只保留必要摘要，订阅与认证字段应隐藏。成功建立连接后还要回到原任务验证，不能以连通性测试通过作为所有应用问题已解决的标志。

可执行的选型结论应写成“在当前接入网络与这类任务下，保留该协议和线路组合”，而不是“某协议在所有地区、设备与时段都更快”。

套餐、设备与技术判断分开处理

流量预算影响套餐选择，不应被混进协议性能结论。VPNRT 月订阅为 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB，流量按开通日每月重置，中途升级差价折算成剩余天数。流量包为 ¥158/300GB、¥358/1000GB、¥658/3000GB，用完为止，永久不过期。完整说明见套餐页面。不要从价格档位自行推断独享出口、特定带宽或额外协议权限，事实表没有提供这些差异。

VPNRT 提供 90+ 国家 / 210+ 线路，同时在线不限台数，支持支付宝 / 微信 / USDT，7 天无理由退款。建立账户无需邮箱地址，使用用户名与密码即可。完成账户与订阅流程后，按使用指南导入交付配置，再用本文的分层方法验证。覆盖范围与设备政策提供选择空间，实际选型仍以当前线路、接入网络和目标任务的复测为依据。