协议与线路技术参考

连接分层与判断顺序

从应用请求到出口服务

浏览器打开页面时，通常先解析域名，再建立传输连接，随后完成应用层的安全协商并请求内容。启用代理后，客户端还需要识别哪些请求进入代理，把数据交给远端入口，再由远端访问目标服务。这里存在本机、接入网络、代理入口、出口网络与目标服务等不同环节。某个环节出问题，表现都可能是页面转圈，但处理位置并不相同。先理解请求走向，才能避免把账户异常、域名解析异常或目标服务故障统称为线路慢。

协议名称描述的是客户端与远端怎样约定身份、封装数据和处理传输。传输层则负责数据抵达与重传，例如基于 TCP 的可靠字节流，或建立在 UDP 上的 QUIC。线路拓扑描述入口到出口的路径，客户端模式决定应用流量能否进入这条路径。这些概念相互配合，却不能互相替代。切换协议不会自动改变目标网站的账户地区，开启全局代理也不会把较远的物理路径变短。

区分连不上、打开慢与持续卡顿

连不上首先看连接是否建立。客户端如果直接报告认证失败，应核对账户订阅状态与配置是否更新；如果入口连接超时，则检查本地网络和当前线路。打开慢要继续区分首次请求与后续请求：首次打开慢，之后操作顺畅，常见原因是解析、握手或冷连接成本；每次操作都慢，则可能涉及持续往返延迟、排队或应用本身。持续传输时反复停住，更值得检查丢包、拥塞与客户端资源占用。

一个页面并不是一个请求。文字、图片、脚本和视频可能来自不同域名，也可能匹配不同的代理规则。因此首页能打开，不代表所有资源已经使用同一出口。排查时先选择一个可重复的操作，例如打开固定页面并进入相同功能，再观察客户端的连接记录。仅看桌面上的连接开关，只能确认客户端处于工作状态，不能确认某个应用已经被正确接管。

建立可比较的观察条件

有效比较需要保持其他条件尽量一致。测试同一目标、同一接入网络与同一种客户端模式，先只换线路，再只换协议。如果同时更换地区、协议、解析方式和规则组，即使体验变好，也无法知道真正起作用的是哪个因素。记录不必复杂，写下目标功能、出现现象、网络类型、线路名称和所做变更即可。客户端日志中的错误类别，比没有背景的速度截图更便于复现。

还要分清客户端显示的延迟、应用响应时间和实际下载速度。延迟探测可能只访问一个检测地址，应用请求却需要经过认证、数据库和内容分发。下载速度还受目标限速、本地带宽、无线信号与并发任务影响。不同指标可以互相补充，但不能拿其中一个代替整体体验。尤其不要把探测成功理解为所有目标均可访问，也不要把短暂下载峰值当成全天持续能力。

本页比较的是技术机制，不是本站协议清单。实际可用协议、传输方式与线路名称，以登录后获取的订阅和客户端显示为准。这里介绍的协议，不代表 VPNXB 在每条线路上都提供对应选项。

安全也需要分层理解。服务使用银行级加密话术，并不意味着用户可以忽略网站证书、账户权限或终端安全。代理连接的保护范围，与应用自身的 HTTPS 保护范围并不相同。正常使用应保留证书验证，避免为排障长期关闭安全检查。出现证书错误时先核对系统时间、目标域名和订阅配置，而不是把跳过验证作为常规提速设置。

常见协议的设计取舍

Shadowsocks 与 VMess：封装方式不同

Shadowsocks 以加密代理的数据封装为核心，通常由客户端接收应用连接，再把目标地址与数据发送给服务端。它不强制所有实现都采用相同的外层传输组合。具体加密方法、是否使用额外传输插件以及 UDP 处理方式，都需要看配置。相对简洁的封装有利于控制处理路径，但简洁不等于任何设备上都更快；实现质量、硬件加速和远端负载同样会影响实际表现。

VMess 包含自己的身份验证与数据封装机制，使用时也经常与不同传输方式组合。用户看到的连接成本，可能来自协议认证，也可能来自外层安全协商或额外的封装层。比较时不能只说“这是 VMess”，还需要知道底层使用什么传输、是否经过额外入口以及客户端怎样复用连接。部分实现对时间相关的认证条件有要求，设备系统时间异常时，应先修正时间再判断线路是否故障。

Trojan 与 VLESS：外层配置同样重要

Trojan 通常借助 TLS 建立加密传输，并在连接内完成代理认证。对使用者来说，服务地址、端口、身份信息、服务器名称与证书验证都属于配置的一部分。TLS 的存在有助于利用成熟的安全传输机制，但不能据此推导它的每次握手都更省时。首次连接、会话恢复和长连接复用会呈现不同体验，客户端实现与服务端配置还可能改变实际成本。

VLESS 侧重较轻的代理身份与请求封装，本身不提供数据加密，需要依靠所配套的安全层保护传输。判断安全性与性能时，必须把协议和外层一起看，不能把“封装较轻”理解为“可以去掉安全层”。同一个 VLESS 名称下，传输组合、流控方式和入口处理可能不同。订阅已经给出参数时，应优先保留完整组合，不要为了减少选项而自行删除无法理解的字段。

不要把名字当作性能等级

基于 TCP 的传输会按顺序交付数据。某段数据丢失时，后面的数据可能已经抵达，却需要等待缺失部分补齐，这会影响交互连续性。是否出现明显等待，还取决于丢包位置、往返时间、缓冲和连接复用结构。因此某个协议在干净网络上表现顺畅，到了信号不稳的无线网络却反复暂停，并不矛盾；变化可能来自传输条件，而不是协议突然失效。

额外传输层有时能改善兼容性或部署适配，但也可能增加头部、内存缓冲与处理工作。不能把“层数更少”直接等同于“体验更好”，也不能把“封装更多”视为高级配置。正确选择是保留满足当前网络与服务端条件的最小必要组合。用户端擅自更换传输方式，如果服务端没有对应监听与配置，连接通常只会失败，不会产生可比较的性能结果。

实际选型先检查客户端能否完整解析订阅条目，再观察目标功能。若某个协议条目导入后消失，或被标注不支持，优先检查客户端能力和导入格式，不要手工拼接身份信息来强行连接。若条目存在但连接失败，保留错误类别并换一个已知可用的条目作对照。学习协议原理是为了减少无效修改，不是要求使用者把服务端的部署参数全部重新设计。

Hysteria2 与 TUIC 的适用边界

QUIC 改变了哪些传输行为

Hysteria2 与 TUIC 都使用 QUIC 相关能力构建代理传输。QUIC 建立在 UDP 上，但并不是把应用数据随意发出后不再负责。它包含安全协商、可靠传输、拥塞控制和流管理等机制，可以在连接内部组织不同的数据流。理解这一点很重要：UDP 是承载方式，QUIC 是其上的传输体系，而代理协议还需要处理身份、目标地址和应用数据的转发。

QUIC 可以降低不同流之间因顺序交付产生的相互阻塞，但某条流内部仍然需要处理丢包与顺序要求。若本地无线网络持续丢包，或者远端出口已经拥塞，QUIC 不会让这些问题消失。它提供不同的恢复与调度机制，可能改善特定网络下的体验，却不是无限带宽来源。网页自身串行请求过多、目标服务响应慢，也不会仅靠更换传输层被完全解决。

Hysteria2：带宽参数需要有依据

Hysteria2 的性能讨论经常涉及带宽估计与拥塞控制。具体使用哪种方式，取决于实现和双方配置。某些设置会依据带宽参数影响发送行为，因此填写一个远高于实际条件的值，并不等于获得更高速度。发送过于积极可能把本地上行队列塞满，导致网页、语音和其他设备一起变慢。接入网络可用带宽还会随共享使用、无线信号和时段变化，不能只按运营商套餐名称填写。

对普通使用者，优先采用订阅提供的配置和客户端默认行为更稳妥。只有明确知道参数含义、服务端约束与本地接入能力，才考虑调整相关设置。调整后不仅看下载，还要检查上传时的网页响应和交互任务。如果速度显示上升，而操作延迟明显变差，就应回退。调参目标是可持续的应用体验，不是让某个计数器在短时间内达到更大的数值。

TUIC：流管理与兼容性一起看

TUIC 同样利用 QUIC 组织代理连接，并提供相应的认证与转发机制。连接复用和流管理可能减少反复创建底层连接的工作，但具体优势取决于客户端实现、目标请求模式与网络条件。UDP 转发行为也需要双方能力匹配。名称相同不代表所有客户端支持完全相同的配置选项，因此导入后应检查是否有不支持字段的提示，而不是默认所有参数都会按原意执行。

QUIC 的连接迁移能力经常被用于解释移动网络切换，但它不是“切换网络永不掉线”的承诺。客户端可能重建连接，接入网络可能改变 UDP 映射，远端也可能不接受原路径继续使用。切换无线网络与移动网络后，既要检查代理连接，也要检查应用自己的会话是否恢复。应用重新认证、视频重新缓冲和代理重连是不同过程，应分别观察。

UDP 不通时，不要只改带宽参数。先核对当前接入网络能否承载所需传输，再用订阅中的其他可用协议作对照。无法建立底层连接时，吞吐设置并不是主要矛盾。

如果同一网络下基于 TCP 的条目可连接，而 QUIC 条目始终超时，应先怀疑承载条件、映射或客户端兼容性；如果两类条目都能连接，但持续传输体验不同，再比较丢包恢复和资源占用。测试需要使用相同目标与相近时段。不要因某次 QUIC 连接更快，就把它设成所有地区、所有网络的唯一选项，保留适用于不同接入条件的候选线路更有实际价值。

还需要关注隧道与真实应用的差别。某个基于 UDP 的应用可以被代理转发，不代表代理使用 UDP 承载就一定更适合它；应用本身可能对抖动更敏感，也可能受到目标服务的连接策略影响。选择 Hysteria2 或 TUIC 时，判断依据应是连接成功率、交互连续性与设备负担的实际观察，而不是把底层名称作为用途保证。

连接建立速度与资源占用

首次连接和复用连接不是同一个测试

首次连接通常包含域名解析、到入口的传输建立、安全协商与代理认证，目标网站还可能进行自己的连接建立。这些步骤有的能够并行，有的需要等待前一步完成，因此不能仅按协议名称推断整个过程。用户感知的页面首开时间还包括远端处理和内容返回。要比较连接建立速度，应先确认比较的是冷连接，还是客户端已经保留会话与底层连接后的重复请求。

连接复用可以让多个请求共享已经建立的通道，减少重复协商与部分资源分配。它对碎片化网页请求可能有帮助，但也会让多个请求共同承受某条底层连接的异常。如果复用后的连接拥塞、重传或被关闭，影响范围可能比独立连接更大。是否值得启用，需要结合客户端默认策略和目标请求模式，不宜把复用开关简单归类为必开的提速按钮。

CPU、内存与连接数量如何互相影响

客户端需要处理加密、解密、数据复制、规则匹配、域名解析与日志。设备具备的硬件加速能力，会让同一种加密算法在不同平台上呈现不同开销。持续下载还可能增加缓冲和并发连接数量。看到 CPU 占用上升时，先区分是正常处理更多数据，还是进程在不断重连、写入大量调试日志或重复解析配置。只看某一瞬间的占用，无法判断长期资源成本。

内存占用也不能只按协议排名。连接数较多、缓冲较大或长期保留会话，都会提高占用；操作系统还可能缓存资源，导致任务结束后数字没有立即下降。真正需要关注的是占用是否持续增长、设备是否开始卡顿以及客户端是否被系统终止。排查时关闭无关的大规模同步和下载任务，保持相同应用负载，再观察更换条目后的变化，避免把浏览器自身的占用算到代理头上。

减少无效的参数试错

超时设置决定等待多久后放弃，不决定数据传得有多快。设得过短，暂时抖动也会触发重连；设得过长，故障时等待会更加明显。并发数量决定同时进行多少工作，过多可能争抢本地带宽、远端资源和设备内存。缓冲设置则在吞吐、响应与占用之间形成取舍。这些参数没有脱离网络条件的统一最佳值，优先保留默认值，只有现象明确指向某项设置时才调整。

不要为缩短握手而关闭证书验证，也不要把身份认证字段删掉后继续测试。安全检查失败时，问题是连接条件不满足，并不是多做了一项可以省略的工作。检查系统时间、服务器名称与订阅是否更新，能帮助区分过期配置与网络问题。对于由订阅管理的线路，重新获取完整配置通常比逐项猜测更可靠；修改前保存原状态，便于发现方向错误后恢复。

一个完整的资源比较应覆盖闲置、普通网页交互和持续传输。闲置时关注后台活动是否频繁，交互时看请求响应和操作卡顿，持续传输时看发热、占用与速度是否稳定。不要把这几类结果合成没有定义的综合评分。使用者真正需要的是知道自己的设备在哪个环节遇到瓶颈，以及换协议、减少并发或换线路，哪一种能够以较少代价改善当前任务。

直连、中转与专线拓扑

直连不是最短路径的保证

直连通常表示客户端直接连接境外入口，或入口与出口之间没有额外的服务中转层。它的结构较容易理解，但公共网络的路由并不按照地图上的直线运行。运营商互联、流量调度和回程策略可能让数据绕行；去程与回程也可能不同。因而距离近的地区不一定拥有更低的实际往返时间，入口名称简洁也不代表链路在繁忙时段没有共享瓶颈。

直连的优点可能是减少额外处理环节，缺点则是更直接地受到本地运营商与跨区域公共互联条件影响。某个地区在家中网络顺畅，换到办公网络却不理想，是可以发生的。比较时应固定本地接入方式，并用实际目标验证，而不是按国家距离排列固定优先级。节点页中的地区信息能帮助缩小范围，但不能替代对本地网络和使用时段的观察。

中转与专线改善的是哪一段

中转是在客户端与出口之间加入转发入口，把请求先送到一个接入位置，再沿后续路径抵达出口。额外节点会增加处理与传播成本，但如果后续路径更合适，整体体验仍可能改善。中转的价值不是节点越多越好，而是把原本不理想的互联路径换成更适合的组合。判断时既看入口可达性，也看中转后的持续传输，不能只测客户端到入口的延迟。

专线通常指某段链路采用专用或有明确资源管理的网络连接，IEPL 是常见讨论中的一个类别。服务描述里的专线不意味着从用户设备到目标网站的全部路径都是专用链路。本地无线接入、入口前的公共网络、出口之后的目标服务互联，都可能继续影响体验。即使中间一段稳定，也无法替用户消除本地信号差、目标限速或账户地区不匹配的问题。

入口地区、出口地区与内容地区

入口是客户端连接的服务地址，出口是目标网站看到请求来源的位置。两者不一定相同，订阅条目的地区名称应结合客户端说明理解。内容地区还可能受账户资料、支付地区、历史会话和平台规则影响。因此为了访问某个地区内容，首先核对出口与账户条件，而不是看到线路名称包含地区词就认定已经满足要求。相关边界可以继续查阅流媒体解锁说明。

所谓原生 IP 也需要明确口径。地址注册信息、数据库地区识别、网络归属和目标平台风控结果并不是同一件事。某个数据库显示的地区，不能单独证明目标平台会把它识别为当地用户。选线应围绕能否完成实际任务，而不是把一个标签当作通用认证。本站地区与线路入口请查看节点页面；具体线路类型以客户端提供的信息为准。

拓扑排查可以从相同出口的不同入口开始。如果目标与出口基本一致，而不同入口的体验明显不同，接入与中转路径就值得重点检查；如果多个入口都在相同目标上变慢，出口或目标服务可能更值得关注。订阅未提供可对照的组合时，不应凭名称自行推断内部拓扑。保留本地网络类型、时段与线路名称，比给未经验证的节点贴上专线或直连标签更有用。

VPNXB 的覆盖事实为 100+ 国家 / 180+ 线路。覆盖范围用于说明可选地区，不表示每个地区具有相同拓扑或相同任务适配性。线路选择应先满足目标地区，再比较可达性与持续体验。若已经找到符合任务需要的稳定候选，日常不必持续自动切换地区；过于频繁地改变出口，反而可能让应用重新认证，并增加判断故障来源的难度。

丢包、抖动与晚高峰拥塞

同样的卡顿可能来自不同问题

丢包是数据未能按预期抵达，抖动是到达时间不均匀，拥塞是进入网络的数据超过某段路径当前的处理能力。拥塞可能造成排队与丢包，丢包也可能来自无线干扰或设备异常，所以这些现象有联系，但不能混为一谈。网页短暂停顿、视频缓冲与语音断续都可能涉及它们。要判断原因，需要看症状出现在哪类任务、是否伴随其他应用变慢，以及更换接入网络后是否改善。

缓冲过深时，下载任务可能仍显示较高吞吐，但交互请求要在队列里等待。用户会觉得下载没问题，网页和语音却明显迟钝。这类表现不能仅靠提高发送强度解决，继续增加并发可能让排队更严重。先暂停上传、同步与其他持续任务，观察交互是否恢复，再考虑接入设备的队列管理或线路选择。网络体验不仅是能搬运多少数据，也包括小请求多久能够被处理。

晚高峰问题要比较完整路径

繁忙时段，本地接入、运营商互联、代理入口、中转与出口都可能出现共享资源竞争。只有在某个时间段变慢，并不能直接证明问题位于服务端。若所有线路和普通本地应用都受影响，先检查接入网络；若本地访问正常，只有某类出口变差，再比较其他地区或拓扑。持续记录相同目标在不同时段的表现，有助于区分偶发故障和稳定的时段性瓶颈。

对照测试应避免额外制造负载。多条线路同时进行大文件下载，既会争抢本地带宽，也可能让远端出口被测试本身拖慢。更合适的办法是按顺序完成相同任务，并观察传输是否频繁归零、交互是否迟缓和重连是否增多。如果只剩下某个目标慢，还要排除目标服务维护、内容源异常和账户状态。线路故障应有可重复的网络证据，而不是只有应用的一句通用错误提示。

探测结果为何可能误导

Ping 或路由跟踪能提供线索，却不是所有应用流量的完整替身。部分网络设备会降低探测报文的处理优先级，甚至不回复。中间节点没有响应，不代表它没有转发后续数据；中间跳显示丢包而最终目标正常，也不能直接认定该跳是瓶颈。反过来，探测顺畅却应用慢，也可能因为应用使用另一种传输、另一条规则或另一个目标地址。

普通用户无需为了诊断去调整大量系统网络参数。先确认本地连接质量，暂停大流量任务，更新订阅，选择相同用途的其他线路，再用同一应用操作复查。若需要进一步定位，可在客户端查看连接错误、目标域名和规则命中情况。分享日志之前遮去账户身份、订阅链接与认证信息，只保留必要的错误类别和现象描述，避免排障材料变成凭据泄漏来源。

吞吐变大但操作更迟钝，不算整体改善。持续传输与交互响应需要一起观察。尤其在上行繁忙时，应先减少竞争任务，再判断协议与线路。

路径中的 MTU 不匹配也可能让小请求正常而较大的传输异常。封装会增加额外开销，某些接入网络又存在较小的有效承载空间。如果出现特定网络下大文件停顿、部分页面资源持续失败，应把封装与路径兼容性列为候选原因。不过这些现象也可能由其他因素造成，不宜直接套用固定 MTU 数值。先保留默认设置并使用替代线路验证，再依据明确的客户端文档处理。

向支持渠道描述问题时，写清应用功能、本地网络、发生时段、条目名称、错误信息以及已完成的对照。工单可以从用户面板进入。不要只写“速度不好”，也不必提交全部浏览记录。能够复现的最小问题描述，既便于区分线路、客户端和目标服务，也能减少反复询问，让后续调整有明确的验证标准。

移动端电量与平台差异

耗电来自处理工作，也来自网络活动

移动端的电量成本不只由加密算法决定。持续传输会让无线通信保持活跃，频繁重连会重复握手与解析，过密的保活和后台探测也可能增加唤醒。弱信号环境下，设备还需要承担更高的通信负担。因此同一个协议在稳定无线网络与移动网络上的电量表现可能不同。判断耗电时要同时考虑屏幕、应用、信号与传输量，不能仅凭设备发热就认定代理协议有问题。

基于 QUIC 的连接可能在某些场景减少重建成本，但持续发送、丢包恢复与实现方式仍会影响电量。基于 TCP 的连接也可能通过会话复用减少重复工作。不存在脱离网络条件的固定耗电排名。更有意义的观察是相同应用任务下，某个候选是否反复重连、设备是否异常发热，以及停止任务后网络活动是否及时减少。不要用后台空闲与持续视频播放的结果直接比较。

系统接管范围决定应用是否走代理

桌面系统的系统代理，通常依赖应用是否遵守相关设置。有些应用自行建立连接，可能不会自动进入系统代理。TUN 或类似虚拟网络接口会在更低层接管流量，但也涉及权限、路由、DNS 与其他网络软件的协作。移动系统通常通过网络扩展或 VPN 接口提供接管能力，后台策略和系统权限仍会影响持续运行。客户端显示已启动，不等于所有平台使用相同的接管机制。

VPNXB 支持 Windows / macOS / iOS / Android / Linux。具体平台能够解析哪些协议条目、提供哪些模式，仍需看登录后获取的客户端与订阅。获取入口统一在用户面板客户端页面，不应从不明来源替换安装包。macOS 的安装与权限操作可参考Mac 怎么用 VPN：新手完整指南，本页只解释权限与连接之间的关系。

网络切换、休眠与后台恢复

设备休眠后，原来的连接可能已经被本地网络或远端回收。唤醒时客户端需要恢复接口、重新解析或重建连接，应用也可能自行重试。若只在唤醒后异常，先观察重新连接是否恢复，再检查是否存在旧代理设置、解析缓存或接口路由残留。不要马上更换账户或重装全部软件，恢复链路的问题与订阅失效有不同的处理方向。

Android 的后台运行策略可能因系统设置而改变，过度限制后台会让客户端无法持续处理连接。iOS 的网络扩展运行也受系统管理，不宜把保持某个应用界面常亮当作通用解决方案。应该遵循客户端与系统提供的权限说明，检查是否获得必要授权，并观察关闭屏幕后具体出现什么现象。任何省电设置的调整，都应只针对已确认影响连接的项目。

不限台数设备是 VPNXB 的同时在线设备事实，但各设备并不因此共享完全相同的网络环境。桌面稳定而移动端不稳定时，先比较接入网络与接管模式；各设备都在相同目标异常时，再关注出口或目标服务。流量密集任务并行运行，还会竞争同一家庭网络的资源。设备数量限制与本地网络承载能力是不同概念，不能把不限台数理解为本地带宽也没有边界。

移动端的日常设置以少改、可恢复为原则。保留可信订阅，减少没有用途的频繁探测，避免同时运行相互争抢网络接口的软件。对于偶发断连，记录是否恰好发生在锁屏、切换网络或信号下降时，再决定检查后台策略还是替换线路。能够把故障与系统事件对应起来，比不断换协议更有效，也能避免为了连接稳定而开启不必要的长期后台活动。

按使用场景选择协议与线路

网页与 AI 工具：先看完整请求能否持续

普通网页与 AI 工具的请求模式并不完全一致。网页可能分散加载许多资源，AI 对话可能维持较长的响应连接，文件上传又会增加上行负担。选择时先确认登录、请求提交与完整响应都能完成，而不是只看首页可否打开。若响应中途停止，检查连接是否重建、网络是否切换，以及应用是否返回账户或服务错误；这些现象不应全部归因于协议名称。

对于 AI 工具，出口一致性有时比频繁寻找最低延迟更重要。会话过程中改变地区，可能触发重新验证或让原有连接终止。先选满足平台规则与实际访问条件的线路，再观察长响应是否连续。协议可以按接入网络表现选择，不必把某个名称固定绑定到某个工具。更多应用层边界见AI 加速说明，其中的账户、平台规则与网络连接应分别判断。

视频、直播与传输：关注不同的连续性

点播视频能通过缓冲吸收部分抖动，直播与实时交互通常更难依靠长缓冲隐藏波动。看视频应确认目标内容地区、账号权限与清晰度选择，再检查持续传输；看直播还要关注卡顿是否在关键时刻反复出现。低延迟探测值并不保证持续流畅，高下载峰值也不保证直播连续。有关晚高峰与实时观看的取舍，可继续阅读体育直播 VPN 的线路选择。

大文件传输更容易暴露持续吞吐与设备负担，但不是所有任务都应按它来选线。某条线路下载顺畅，却在上传时让网页变慢，可能存在上行排队；某个协议传输较快，却让移动设备持续发热，也可能不适合作为日常默认。把候选分成日常交互与持续传输用途，比追求一个覆盖所有情境的冠军更合理。用途变化时再切换，不必在正常任务中反复试验。

用可回退的流程做最终选择

选型可以从订阅中的默认候选开始。先用目标应用完成实际操作，再在相同接入网络下换一条同用途线路；确认线路差异后，才比较可用的协议组合。每次只改一个条件，并保留原候选。若新设置没有明确改善，就恢复默认，不要累积已经忘记理由的改动。订阅不提供的传输组合不要自行创造，服务端与客户端必须匹配，才能得到有效比较。

遇到故障时按层回退：应用无法完成操作，先查账户与目标服务；代理连接失败，查订阅状态、入口与本地网络；持续传输异常，查竞争任务、丢包与设备占用。某个候选失效时，替换同类候选比同时改地区、协议和模式更容易定位。用于工单的记录只需包含必要条件，不要上传完整订阅链接。新手常见账户与流量疑问可以查阅VPN 新手常见问题。

技术选择还应配合实际用量。VPNXB 月订阅为 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB，流量按开通日每月重置；中途升级差价折算成剩余天数。流量包为 ¥158/300GB、¥358/1000GB、¥658/3000GB，用完为止，永久不过期。协议测试和持续下载也会产生流量，选择套餐前应先了解自己的主要任务，完整计费方式见套餐页面，不必为了试协议直接提高档位。

最终保留的是能完成任务的组合。连接可建立、目标功能可用、持续体验合适、设备负担可接受，比未经定义的协议排名更有参考价值。

VPNXB 提供 60 天无理由退款，支持支付宝 / 微信 / USDT；建立账户无需邮箱地址，使用用户名与密码即可。退款细则见退款政策。这些服务事实与协议技术能力应分别理解：退款不是性能测试结果，覆盖范围不是每个目标的可用承诺。选型结束后保留稳定候选与排障记录，后续发生网络变化时，便能按连接层、路径层和应用层逐项复查，而不是从头猜测所有设置。