协议与线路技术参考

链路基础

先把协议和线路分开看

一次访问经过哪些环节

点击连接后，客户端先要找到服务端并建立会话，然后应用的数据才会进入传输通道。数据从设备出发，经过当前接入网络、运营商网络、所选入口与出口，最后到达目标服务；返回内容沿可用路径回到设备。协议主要规定客户端与服务端怎样建立会话、封装数据和处理传输。线路则描述数据在网络中经过什么入口、如何转接、从哪里出去。两者相互影响，却不是同一个开关。

因此，看到“某协议连接很快”时，先问它快在何处。建立会话所花的时间、网页首个响应到达的时间、持续下载时的吞吐和视频播放中的停顿，分别对应不同阶段。一次握手省下的等待，不能自动抵消远距离传输、出口拥塞或目标网站处理请求的时间。反过来，较长的初次建立过程也不代表建立后一定慢。只凭客户端出现“已连接”就判断线路质量，同样会漏掉应用端的问题。

把指标对应到体感

交互式网页与远程操作关注的是响应是否及时，持续传输更在意吞吐是否平稳，语音和会议还关心延迟的变化幅度。丢包是部分数据未能正常抵达；抖动是到达间隔忽长忽短。即使平均延迟看起来相近，频繁抖动仍可能造成声音断续。测速窗口里的瞬时高值也不能代表一段较长会话的表现：下载可以利用缓冲掩盖波动，实时交互则很难。

本页后面的对照表使用“倾向”“取决于实现”等定性措辞，因为设备性能、客户端实现、接入网络和目标服务会改变结果。不同协议也可能搭配不同底层传输与封装方式；只读协议名称，无法得知完整数据路径。比较时要保持测试条件一致：同一设备、同一接入网络、同一目标服务，并尽量只改变一个变量。先固定线路换协议，再固定协议换线路，结论才有解释力。

选型顺序：先确认目标服务能正常访问，再判断波动来自接入网络、协议配置还是线路拓扑。不要把所有异常都归因于节点地区。

阅读线路名称时保留边界

地区名通常描述入口、出口或服务侧标识，不等于数据从头到尾只经过该地区。客户端显示的连接状态表示本地与服务端之间的某一步成功，不能替代目标网站的实际访问验证。线路类型标签也是拓扑提示，不是对任何时段速度的保证。需要了解 VPNZR 提供的地区与线路分类，可在阅读原理后打开服务器页面对照；页面上的地区、城市和类型信息比单独看国旗更适合做初筛。

还应区分“线路不可连接”和“某个应用不可用”。前者常表现为客户端无法建立会话，后者可能发生在 DNS 解析、目标站点响应、应用账户状态或内容区域判断等后续阶段。诊断时记录问题停在哪一步，比反复更换协议名称有效。把建立、传输、解析、应用分别当成检查点，后文涉及协议与拓扑的比较才不会混在一起。

设计沿革

Shadowsocks、VMess 与 Trojan 的取舍

Shadowsocks：简洁的数据通道

Shadowsocks 的基本思路是让客户端把应用流量交给远端，由远端继续发起请求。它的实现路径相对直接，适合希望少设选项、先确认基础连接是否正常的情况。简洁不代表所有客户端都采用同样的传输设置，也不代表在拥塞网络里能单靠协议保持稳定。客户端与服务端必须支持一致的加密及连接参数；只知道协议名称而没有完整、有效的订阅信息，不能据此手动猜出可用配置。

评估它时，先看客户端能否正确导入，再看目标应用在持续使用时是否稳定。如果刚连接就失败，排查重点通常是订阅状态、入口是否可达与客户端配置；如果连接成功后只有特定网站慢，应继续检查线路出口和目标站点，不要立即认定是协议封装造成的。不同实现对 UDP 等流量的支持也需分别核对，不能把一个应用的成功结果外推到所有应用。

VMess：能力由实现与配置共同决定

VMess 常见于支持多种传输组合的客户端。它提供的配置空间有利于适配不同应用环境，同时也增加了定位问题时需要核对的项目。传输层、加密方式以及服务端对应能力不匹配，都可能表现为“选了节点却连不上”。在相同网络条件下，对比协议时应记录实际采用的传输方式，否则把不同的传输组合都叫作“VMess 测试”，结论并不精确。

功能选项多不意味着每项都应开启。为一个本来稳定的场景叠加额外封装，可能增加处理成本或让排错路径变长。移动设备上尤其要关注客户端是否在网络切换后及时恢复，而不是只看首次连接是否顺利。遇到连接建立缓慢，可先重试同线路，再换同地区的其他线路；若只有一种协议持续异常，再核对客户端兼容性与订阅更新情况。

Trojan：关注端到端匹配

Trojan 通常依赖 TLS 建立连接。这里的关键不是名称听起来更“安全”，而是客户端、入口服务和证书等条件能否正确配合。TLS 握手有其建立过程，初次连接的体感受往返延迟、连接复用和客户端实现影响。会话建立以后，持续传输仍会受到线路带宽与拥塞制约；不能把握手特征当成观看视频时永不缓冲的依据。

如果 Trojan 配置无法连接，应区分本地时间与系统环境异常、订阅条目过期、入口不可达等可能性。不要通过关闭客户端已有的校验选项来掩盖错误提示；更合适的做法是更新订阅、换一条已知可用线路，并查看客户端提供的明确错误信息。对普通用户而言，正确导入由服务提供的配置比手工拼接参数可靠。对进阶用户而言，则要把“协议本身的机制”与“某个入口的具体部署”分开评价。

这几种协议没有脱离场景的统一排名。连接失败先排查配置和入口；建立成功但持续卡顿，再比较拓扑、出口和拥塞情况。把故障发生阶段写下来，能避免仅因更换协议后碰巧换到了另一条线路，就把改善全部归功于协议。

传输方式

VLESS、Hysteria2 与 TUIC 怎么比较

VLESS：区分核心协议与外层传输

VLESS 更适合作为“需要连同传输方式一起阅读”的协议名称。它本身不应被当作一套完整、固定的线路方案：同为 VLESS 的条目，外层传输、连接建立步骤和实际表现都可能不同。比较两个条目时，先核对它们是否走同类传输、是否使用同一地区和相近的线路拓扑。只凭名称断言它一定比 VMess 更快，会把实现与网络路径的差异错误归因于协议。

对日常使用而言，配置兼容性比参数数量更重要。订阅导入后，确认客户端能识别条目，并在目标应用中完成一次真实访问。如果只有某个平台的客户端无法建立会话，而同一订阅在其他设备可用，可优先核对该平台客户端对对应传输的支持情况。不能把某个平台的失败解释为整个地区的线路都失效。

Hysteria2：重视波动下的持续传输

Hysteria2 基于 QUIC 相关传输能力，常用于希望在有波动的链路上维持较好吞吐的场景。它对网络状况的适应方式与常见 TCP 路径不同，但实际效果仍取决于接入网络能否稳定承载相应流量，以及入口、出口和目标站点的状况。某条连接在下载测试中表现顺畅，不代表在所有运营商网络或所有应用里都更合适。

评估 Hysteria2 时，不要只看短时峰值。可以观察长时间浏览是否出现停顿、网络切换后是否恢复，以及语音或远程操作时是否有明显抖动。如果同一线路的其他传输方式可用、只有该协议反复无法建立连接，先检查客户端支持与当前接入网络，再决定是否换线。协议可以改善某些传输条件下的利用方式，却不能制造线路本身没有的出口容量。

TUIC：把会话恢复和资源消耗纳入判断

TUIC 同样需要结合客户端实现与底层网络来评价。支持 QUIC 的连接方式可能在移动网络切换等情况下提供不同的恢复体验，但“可能”不等于每个设备、每条线路都能无感切换。操作系统的后台限制、客户端保持连接的策略，以及应用是否主动重试，都会影响用户最终看到的结果。

资源消耗方面，不宜给协议贴固定的“省电”或“耗电”标签。持续高吞吐会使用无线电与处理器资源；频繁断开重连也会增加唤醒次数。应在同一设备、相近使用时长与同类应用负载下比较。如果一个方案连接建立迅速，却在锁屏后反复失去连接，实际体验未必比建立稍慢但会话平稳的方案好。先确定要优化的是初次等待、持续传输还是后台恢复，再比较协议。

协议名称只是一层索引。VLESS 还需看外层传输；Hysteria2 与 TUIC 还需看接入网络和客户端实现。判断依据应落在相同用途的实际访问上。

查看客户端选项时，也要避免把“支持某协议”误读成“每条线路都提供该协议”。可选项目以实际订阅条目为准。VPNZR 线路的分类与地区可先在服务器页面查看；如果已有客户端条目，则按其提供的参数使用，不凭技术文章推导服务端设置。这样既能保留协议选择的灵活性，也能让故障记录对应到真实使用的线路。

路径结构

直连、中转与专线的路径差异

直连：环节少，但路径并非固定

直连通常表示从用户网络接入对应入口，不额外安排所述服务内的中转链路。它的优点是结构容易理解，出现故障时可以较快缩小检查范围。不过，“环节少”不能直接推导为“延迟最低”：互联网中的实际路由由多方网络共同决定，同一目的地从不同接入网络出发，也可能走不同路径。远距离访问的物理距离、运营商互联和目标站点响应都不会因为线路名称写着直连而消失。

直连适合作为初始参照。先确认目标服务可以稳定打开，再在相同应用中比较其他类型。如果直连在某段时间波动明显，而其他类型保持平稳，差异可能与接入路径有关；如果全部类型同时变差，应先检查本地 Wi-Fi、接入网络或目标服务。只有比较对象与时间窗口一致，直连的表现才是有价值的基线。

中转：用额外路径换取路径选择

中转是先到一个入口，再由该入口把流量送往后续出口的结构。多一段传输通常意味着额外的处理和路径长度，但也可能避开不理想的直达路由。它的价值取决于入口是否易达、入口到出口之间是否稳定，以及出口是否靠近目标服务。中转不是自动提速器；任一段拥塞都可能成为整条链路的限制。

排查中转线路时，最实用的办法是分段思考。客户端是否连得上入口？连接建立后，所有目标站点都慢，还是只有特定服务慢？同地区另一条中转是否也出现类似现象？如果入口连接稳定而目标应用反复停顿，问题可能位于后续传输或出口。普通用户不必掌握每个内部节点地址，但应记录线路类型、目标应用、接入网络与问题时段，便于与直连结果对照。

IEPL 专线：关注链路设计，不把名称当保证

IEPL 专线是一类线路拓扑标签，用来区分其跨境段的组织方式。专线与普通互联网转发在路径安排上有差异，但用户设备到入口、出口到目标服务的两端仍受实际网络条件影响。即便跨境段表现平稳，本地接入拥塞、出口负载或目标站点自身异常仍会造成卡顿。因此，不能仅凭“专线”二字推断每个地区、每个时段和每种应用都更快。

对会议、远程操作等对波动敏感的任务，可以把 IEPL 专线列入优先试用的类型，同时保留同地区中转或直连作为对照。若专线稳定但目标应用仍提示区域不匹配，应先核查出口地区与应用要求，而不是反复切换连接协议。若连接建立都不成功，则应先确认客户端和入口；拓扑优势只在链路可用之后才有讨论意义。

选择时先锁定目标地区，再比较类型，最后才考虑协议组合。如果同时改变国家、拓扑和协议，就无法判断哪项变化带来了结果。完整地区与类型列表见服务器页面；这里的表格解释标签含义，不替代当下网络中的实际访问测试。

故障机制

丢包与晚高峰拥塞从哪里来

丢包不只有一种来源

数据包可能在无线接入、运营商互联、线路入口或后续出口的任何环节未能及时抵达。无线信号受距离和干扰影响；网络设备在队列排满时可能丢弃数据；目标服务也可能主动限制请求。应用看到的症状取决于传输方式：有的会等待重传，有的更倾向于继续送后续数据。前者可能表现为页面加载突然停住，后者在实时音视频中可能表现为声音或画面短暂缺失。

不能把一次请求失败直接认作整条线路丢包。浏览器缓存、域名解析、应用自身重试与服务器响应都可能改变观察结果。更稳妥的检查是使用同一目标、同一接入网络，连续观察能否重复出现相同现象，再与同地区其他线路比较。如果仅一个应用异常，先查该应用的账户、区域与服务状态；如果多个互不相关的应用同时出现连接中断，再考虑共同的网络环节。

拥塞为何常在特定时段出现

晚高峰是网络需求集中的场景描述，并非每条线路都按同一时刻开始或结束。共享链路上的流量增加，排队时间可能变长；队列继续增长，抖动与丢包也可能随之出现。即使客户端仍显示“已连接”，应用的数据也可能正在排队。单看协议的握手成功率，无法判断持续传输时是否会拥塞。

遇到时段性变慢，先保存参照：同一设备、同一目标服务，在不同线路类型下分别完成相同操作。记录的是“网页是否顺畅加载”“会议是否出现断续”“视频缓冲是否频繁”等可复查现象，而不是凭一次测速峰值选出所谓永久最优线路。如果直连与中转表现不同，可进一步检查路径选择；如果各类型同时波动，还需要考虑本地接入与目标服务的负载。

重传、缓冲与看起来矛盾的结果

协议会通过不同方式处理丢失和乱序的数据，但没有办法凭空补足受限的链路容量。缓冲较充分的视频可能暂时看不出波动，实时通话却很快出现断续；一个下载任务可以持续推进，网页上依赖多个短请求的交互仍可能感觉迟缓。因此，“下载正常、会议卡顿”并不矛盾，也不必马上推断是客户端故障。要先确定应用对延迟、抖动和吞吐的侧重点。

还要留意本地网络切换造成的假象。设备在 Wi-Fi 与移动网络之间切换时，原连接可能需要重建；应用往往把这段空白显示为加载中。如果问题只发生在移动过程中，可优先验证网络切换后的恢复，而不是在固定网络下重复测速。对于桌面设备，暂停占用网络的后台任务，再观察同一线路，能帮助区分本地争用与远端拥塞。

一次测试只能说明当时的路径。记录目标应用、接入网络、线路类型与现象，再在相近条件下复查，才能判断问题是否具有规律。

稳定性的判断可以参考连接成功率与断线率自测方法。文章侧重怎样记录观察；本章解释为什么连接成功、瞬时吞吐和持续使用可能给出不同答案。两者结合，比只看客户端里一个状态标记更接近实际体验。

终端条件

设备性能、后台连接与电量表现

建立连接与维持连接是两笔开销

协议消耗的资源不只发生在建立会话时。初次连接涉及解析、握手与必要的认证；持续使用还需要处理加密、数据封装和接收；设备锁屏后，客户端可能按系统规则维护或重建连接。这些环节对应不同的 CPU、无线网络和电量开销。把连接按钮按下后等待的时间当作唯一标准，会遗漏后台运行时的重复唤醒与网络切换成本。

在相同设备上比较时，先固定应用负载。如果一种方案用于长时间视频，另一种仅用于打开几页文字，电量差异没有可比性。屏幕亮度、信号强弱、系统节能策略和后台应用同样影响耗电。信号不稳时，无线设备可能为维持传输做更多工作，这种变化不应直接记到协议名下。尤其在移动使用场景，线路入口是否稳定、断线后是否反复重连，往往比理论上的封装开销更值得关注。

移动端的后台规则

iOS 与 Android 都会管理后台活动，但具体表现受系统设置、应用权限与客户端实现影响。锁屏后应用暂时没有发起请求，不等于线路故障；解锁后短暂重建会话，也未必意味着订阅已失效。需要判断的是目标应用恢复前台时能否正常访问，以及从 Wi-Fi 切到移动网络后是否需要手动重新选择线路。若频繁失败，应先查看系统是否允许客户端保持所需的网络活动，再检查订阅条目与线路。

如果刚完成导入却始终无法访问，不要先通过耗电表现推断协议问题。按新手指引确认客户端、订阅和连接步骤，再用浏览器验证实际出口。针对 iPhone 的导入与配置允许步骤，另见iOS VPN 新手指南。这些操作性页面负责具体界面顺序，本章负责解释为什么前台连通与后台保持可能得出不同结果。

桌面与移动设备如何分工

Windows、macOS 和 Linux 桌面设备常用于持续工作，适合把长时间连接与目标应用的稳定性放在前面；iOS 与 Android 更容易遇到网络切换、锁屏和电量约束。VPNZR 支持 Windows / macOS / iOS / Android / Linux，且同时在线不限台数，因此可以在常用设备上分别检验同一用途，而不必假定一台设备上的最佳选择必然适用于另一台。

比较移动端方案时，可以先让设备保持在同一种网络下完成目标任务，再单独测试网络切换，最后观察锁屏后的恢复。分开测试的原因是每一步都引入新的变量。若只有锁屏后异常，换远端地区未必能解决系统侧的后台限制；若固定网络下持续卡顿，则应回到线路和拥塞的分析，而不是首先调整系统电量选项。

实际决策

按使用场景选协议与线路

网页与 AI 工具：先验证完整请求

浏览网页和使用 AI 工具时，体验由多个短请求组成：页面资源、登录状态、持续对话和文件操作可能经过不同接口。先选目标服务适用的出口地区，再用真实操作验证登录、提交与返回是否完整。只看到首页打开，不代表后续请求都正常。协议方面，优先使用客户端已经正确导入且能稳定完成这些操作的条目；若请求经常中途停止，再固定地区比较其他协议或拓扑。

当一个 AI 工具访问失败、其他网站正常时，先不要把故障归为整条国际线路中断。目标服务的账户状态、地区策略和服务端响应都可能造成差异。可以先重复同一操作，核对是否发生在特定功能，再换同地区线路作对照。关于 Cursor 等具体工作流，本页提供的是网络层判断方法，而不是对第三方服务可用范围的保证。

流媒体：地区正确之后再看持续性

流媒体场景先确认出口地区与目标片库一致，再观察实际播放过程。页面能打开、片名能搜索到和视频能持续播放，是不同的检查点。视频应用有缓冲机制，短暂波动可能被掩盖；反复降低画质或频繁等待，则提示持续传输需要进一步比较。先保持地区不变，尝试不同线路类型，才能分清是出口条件还是路径稳定性造成差异。

观看需求并不能只靠协议名称解决。即使某种传输方式在短时间内吞吐较好，目标平台对出口的判断与视频源状态仍需单独确认。需要更具体的片库与画质检查步骤，可读Netflix 区域片库与带宽判断，或查看流媒体专题。这些页面聚焦观看结果；本页的线路比较方法则适用于更一般的持续传输。

会议、远程操作与移动使用

会议与远程控制更怕到达时间忽长忽短。先用常用接入网络测试目标服务，观察声音、画面或输入反馈是否连续。若直连有明显波动，可在同地区比较中转与 IEPL 专线；若切换后仍然断续，再检查本地无线环境和目标服务。不要为了追求一个看起来较低的瞬时延迟数字，放弃实际更平稳的线路。

移动场景则应增加切换与恢复测试。在固定网络下确认连接后，观察从一种接入网络转到另一种时客户端能否恢复；如果恢复不理想，比较客户端支持的其他协议条目，并核对系统的后台管理。选择标准不是“所有设备统一用一个协议”，而是让每台常用设备上的关键应用持续完成任务。VPNZR 同时在线不限台数，但各设备的接入条件仍应分别判断。

把预算与选线分开决定

线路选型解决连接体验，套餐选择解决流量与使用方式，不应拿价格代替技术判断。VPNZR 月订阅为 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB；流量按开通日每月重置，中途升级差价折算成剩余天数。另有用完为止、永久不过期的流量包：¥158/300GB、¥358/1000GB、¥658/3000GB。先按应用需求验证线路，再去套餐页面核对当前适用的流量安排。上述容量不是速度指标，也不能说明某个协议的性能。

如果用途尚未确定，可以从最常使用的应用开始建立基线：记录出口地区、协议、线路类型与能否完成任务。用途变化时再调整，不必提前为每一种可能场景准备复杂配置。这样得到的是一份可维护的个人选线记录，而不是脱离设备与接入网络的通用排行榜。

复查流程

实测连接，定位故障发生的位置

从最小可用路径开始

先确认设备本身可以访问普通网站，然后更新客户端内的订阅，选择一个目标地区的线路并尝试连接。客户端提示成功后，再访问实际要用的服务。若普通网站也打不开，应先处理接入网络；若客户端无法建立会话，检查条目是否被正确识别、订阅是否更新以及同地区其他条目是否可用。只有完成这些基础步骤，才值得比较某一种协议的性能。

连接成功但页面打不开时，换一个互不相关的网站测试。如果都失败，检查客户端路由与当前出口；如果只有单个网站失败，继续检查该站点的账户、地区或服务状态。出口地址是否变化可以作为辅助信息，但地址变化只证明某段路径生效，不证明目标应用的每项功能都可用。需要查看当前出口与基础网络信息，可使用站内网络检测，随后仍要回到目标应用完成验证。

每次只改变一项条件

比较协议时保留同一设备、地区、接入网络和目标任务，尽量选择可比的线路；比较拓扑时则固定协议与目标地区。若无法完全控制变量，应在记录中注明差异，不把结果写成协议的普遍属性。例如，从日本的直连条目切到美国的专线条目后体验改善，地区、出口、路径和目标距离都变了，不能仅据此断言专线总是更合适。

建议把观察写成简短记录：使用的应用、设备与接入网络，所选地区、线路类型和协议，连接是否建立，以及任务在什么步骤停住。不需要记录订阅内容或账户凭据。重复出现的现象比单次截图更有排查价值；若问题只在特定时段出现，保存该时段与其他时段的对照。记录足够清楚时，也更容易在提交工单时说明已经排除了什么。

何时停止调参，改为换线或求助

如果多个协议在同一条线路上都无法建立连接，而同地区另一条线路正常，优先更换线路；如果同一协议在多个地区都失败，但其他协议可用，优先检查客户端兼容性与订阅导入。若所有线路在一台设备失败、另一台设备正常，检查该设备的系统网络设置。若所有设备在同一接入网络失败，换一种接入网络验证，比继续修改单个客户端选项更能缩小范围。

调参的边界也很重要：不根据网上不完整的示例手工改写订阅条目，不靠忽略明确的证书或认证错误来强行连接。遇到无法解释的错误，保存不含敏感内容的提示文字和复现步骤，通过用户面板的工单入口反馈。说明设备平台、目标地区、线路类型、协议与故障阶段即可，不要提交密码或完整订阅地址。

检查顺序可以固定为：设备接入网络 → 客户端与订阅 → 线路入口 → 目标服务。每确认一环，再检查下一环；不要一次更换所有条件。

VPNZR 覆盖 110+ 国家 / 170+ 线路，支持 Windows / macOS / iOS / Android / Linux，采用不记录日志策略。覆盖范围提供更多可比较的路径，不等于任一路径在任意接入网络下都有相同表现。账户注册无需邮箱地址，用户名与密码即可注册；服务提供 7 天无理由退款。想先完成实际连接，请回到新手指引；需要按用途检查地区与拓扑，查看服务器页面。本手册应作为复查依据，而不是替代应用中的实际结果。