协议与线路
技术参考

一次访问经过哪些环节

打开网页时，应用通常先解析域名，再建立传输连接，随后进行安全协商并发送请求。使用代理后，还会增加客户端接管流量、连接代理入口、转发到出口等环节。它们可能重叠执行，也可能复用已有连接，因此用户看到的等待并不等于某个节点的延迟。页面迟迟没有内容，可能停在域名解析；文字出现而图片缓慢，则可能是图片域名走了不同规则，或者下载阶段遇到拥塞。

先辨认客户端的工作方式也很重要。系统代理通常只接管遵循系统代理设置的应用；虚拟网络接口模式则通过路由接管更多流量，但仍受到系统权限、规则和应用行为影响。浏览器可以访问，并不能证明其他应用已经走相同路径。排查前应确认当前启用的模式，检查目标应用是否在规则范围内，避免把接管范围的问题误判成协议不兼容。

协议、传输与线路不是同一个选项

代理协议负责身份验证、数据封装与转发语义；底层传输负责把数据送到对端；线路则描述入口、承载路径与出口之间的实际关系。客户端里某个名称可能把这些信息写在一起，但它们仍是不同维度。相同协议能够部署在不同地区和拓扑上，相同地区也可能提供不同协议。比较时如果同时更换协议、地区和入口，结果只能说明整个组合不同，无法判断哪项调整真正有效。

加密同样需要分层理解。应用自身的 HTTPS 连接与客户端到代理入口的加密连接，不是同一段保护。前者主要保护应用与目标站点之间的数据，后者保护代理传输链路。加密可以降低链路内容被读取或篡改的风险，却不负责判断目标网站是否可信，也不代替账户安全。使用订阅时仍应核对来源，保管账户凭据，并避免把含有访问凭据的订阅内容贴到公开讨论区。

建立可以对照的观察记录

有效记录应描述现象发生在哪个阶段，而不是只写“网络不好”。例如客户端是否显示连接成功，目标域名是否能解析，网页是完全打不开还是内容加载不全，故障只出现在某个应用还是所有应用。再补充当前网络类型、地区选择、代理模式和出问题的时间段。这样的记录能够把排查方向缩小，也便于在更换线路后判断问题是否真正消失。

连接测试、网页访问和实际任务应分开看。客户端的测试功能可能只访问特定地址，也可能仅验证传输连接，它不一定覆盖目标应用的登录、资源加载或长连接。测试显示正常但应用失败时，应回到目标应用本身验证，而不是不断刷新测试结果。首次使用的完整验证顺序见快速上手；本页后续章节则解释各阶段失败时，为什么需要选择不同的调整方法。

先固定应用、网络和地区，再调整一个变量。让每次变化都有可比较的前后状态，比同时启用多项优化更容易找到原因。

Shadowsocks：较直接的代理封装

Shadowsocks 的核心思路是让客户端与服务端按约定的加密和封装方式交换代理数据。相较于层次较多的组合，基础结构通常更直接，但这不意味着任意实现都更快。加密算法、处理器支持、客户端实现、连接数量与实际路径都会影响结果。选型时应首先确认订阅能被当前客户端完整识别，再观察目标应用的连接与持续传输表现，而不是只根据协议名字推断资源开销。

它对 TCP 与 UDP 的处理需要分别确认。浏览网页可用，并不自动证明依赖 UDP 的语音或其他应用也适配当前链路。客户端可能支持协议本身，却没有启用对应的转发能力；服务端的能力和入口网络条件也可能不同。若只在某类应用出现问题，应查看应用所需的传输是否被接管，以及订阅是否提供相应能力，不要自行把不匹配的参数补进导入配置。

VMess：认证、时间与传输组合

VMess 包含自身的身份验证与数据处理机制，并常与不同传输方式组合使用。对用户而言，真正需要关注的是完整组合能否被客户端理解，而不是只认协议标签。传输路径、服务名称、主机字段或相关安全参数存在差异，都可能让连接在建立阶段失败。导入成功只代表配置被解析，不代表远端认证已经完成；遇到失败应查看日志中的具体阶段，再确认配置是否需要更新。

系统时间也是容易忽略的环境因素。依赖时间相关校验的连接，在设备时间明显偏离时可能出现认证问题。正确做法是恢复系统正常的时间同步，并检查休眠恢复后状态是否异常，而不是随意改认证字段。另一方面，额外的传输封装可能帮助适配某些部署方式，也会引入更多需要协商和处理的环节。兼容性与部署弹性增加，并不等于每个场景都能获得更短等待。

Trojan 与 VLESS：理解安全层放在哪里

Trojan 常见部署依赖 TLS 来保护传输，并通过约定的认证方式提供代理能力。因此证书是否有效、域名是否匹配、系统信任链是否正常，都是连接建立的重要条件。证书错误不应通过关闭验证来长期解决。关闭验证会削弱对连接对象身份的确认，掩盖的可能是配置错误、设备时间错误或错误入口。应优先核对面板交付信息与客户端日志，再决定是否需要重新导入。

VLESS 的基础协议侧重精简的认证与转发，不自行提供与外层安全传输等价的加密保护。讨论安全性时必须看完整组合，不能把协议名当成安全结论。它可以搭配不同传输与安全机制，具体能否使用取决于客户端和服务端共同支持的参数。某些组合减少了一部分协议处理负担，却可能在其他层增加握手或封装，因此也不能据此直接宣称整体连接一定更快。

以上说明是技术类别的比较，不是 VPNUO 的逐线路能力清单。面板未提供的组合不应通过手动改协议名称来尝试替代。实际需要的是能被客户端正确处理、与入口匹配、适合当前应用的完整配置；如果希望继续理解地区与线路类型如何参与选择，可结合线路选择文章阅读，避免把路径质量问题全部归到协议上。

UDP 是承载方式，不是速度保证

Hysteria2 与 TUIC 都与 QUIC 技术相关，通常以 UDP 承载连接。QUIC 在用户态处理连接、加密与流控制等功能，可以在同一连接中承载不同数据流。它并不是把可靠传输的责任取消，而是把相关机制放到不同层实现。因此“使用 UDP”不能直接翻译为“没有重传”或“适合所有游戏”；实际可靠性、拥塞控制与数据转发行为，仍要看协议实现和应用类型。

理解这类协议时，还要区分外层承载与内层业务。通过 UDP 承载的代理连接，里面既可能传递网页这类可靠数据流，也可能转发应用自己的 UDP 数据报。外层能够建立连接，不代表内层每种业务都被正确处理。反过来，目标应用使用 TCP，也不妨碍它由合适的 QUIC 类代理承载。选型应以完整转发能力和实际任务为准，而不是让应用传输与代理承载机械对应。

Hysteria2：拥塞控制与带宽参数需要协调

Hysteria2 的重要讨论点是拥塞控制，以及在路径存在丢包和波动时如何组织发送。不同配置与实现可能采用不同控制方式，不能把某种表现套用到所有部署上。涉及带宽估计或发送速率的参数时，应优先使用服务端交付和客户端默认的匹配设置。把估计值盲目调高，不会创造额外容量，反而可能增加排队、丢包与本地网络压力，让同时进行的网页和语音任务更难使用。

若网络对 UDP 的处理较差，这类连接可能无法建立，或出现连接后间歇停顿。此时应先切换到另一种接入网络进行对照，再用已知可用的其他传输作为参照。只有 UDP 类连接受影响时，入口网络或路径兼容性更值得检查。不要把失败简单解释为设备性能不足，也不要连续修改多个传输参数；能够正常回退到适配当前网络的方案，本身就是可靠使用的一部分。

TUIC：关注复用、连接维护与客户端支持

TUIC 也利用 QUIC 提供的能力组织代理传输，连接复用与数据报处理是理解它的重要线索。复用可以让业务共享已建立的连接状态，减少重复建立外层连接的工作，但共享并不意味着完全互不影响。不同流仍会竞争路径容量、拥塞窗口和设备资源。当后台下载占满上行或下行时，聊天和网页也可能受到影响，不能只凭“多路复用”就预期所有任务都能同时保持原有响应。

客户端支持必须覆盖实际配置，而不只是界面上出现了协议名称。相关安全参数、数据报处理方式与连接维护行为，需要与服务端兼容。设备从休眠恢复、接入网络切换，或者网络设备清理空闲映射后，已有连接可能需要重建。QUIC 的设计包含应对路径变化的能力，但具体代理应用能否平稳恢复，还取决于实现、系统限制和服务端策略，不能据此承诺切换网络时业务始终不中断。

QUIC 类协议值得作为候选，但应保留适配当前网络的替代线路。判断依据是目标业务的持续表现，不是协议名称的新旧。

对照测试时，可以先确认基础网页能否访问，再执行真实任务，最后观察网络切换与后台恢复。若下载顺畅但语音仍有断续，应检查实时数据报的处理，而不是继续追求更大的下载吞吐。若任务开始很快、持续一段时间后停顿，则应关注队列、连接维护和设备资源。把建立阶段与持续阶段分开记录，能够避免把不同原因合并成一句“UDP 不稳定”。

这类协议的优势与代价都具有条件性：用户态处理和加密会消耗设备资源，保持活跃连接可能增加无线通信，拥塞控制也需要适应真实路径。桌面网络中的良好表现不应直接推断到移动网络。实际使用时保持客户端配置可回退，优先采用面板提供的完整订阅，并将协议选择与后文的电量、拓扑和拥塞分析一起判断，才比单独比较协议标签更有意义。

连接快，不等于持续下载快

用户感受到的“快”至少包含开始等待和持续传输两种体验。短任务可能主要消耗在解析、建立连接、安全协商和目标服务处理；长任务则更容易受到路径容量、拥塞、重传与设备处理能力影响。一个连接建立较快的组合，未必有更高的持续吞吐。反过来，下载大文件表现良好的线路，也可能因为解析或握手等待，让打开小网页显得不够利落。比较前应先明确自己想改善哪一段。

连接复用会明显影响观察。刚启动客户端、刚切换网络或刚选择地区时，通常需要建立新的状态；连续访问时，则可能复用解析缓存、安全会话和已有连接。把刚建立的连接与已经预热的连接直接比较，会把缓存效果误认为协议优势。更合理的方法是分别记录首次访问与连续访问，并在相似状态下重复同类任务。不要为了获得好看的结果，专门选取最顺畅的一次作为长期结论。

资源开销来自整个处理链

设备需要完成加密、解密、封装、数据复制与规则匹配。开启虚拟网络接口后，还可能增加用户态与系统网络栈之间的数据处理。复杂规则、大量连接、详细日志和额外插件都可能参与资源消耗，所以进程占用高不一定由协议本身造成。应在相同客户端模式和相近业务负载下观察，再检查是否有后台同步、媒体转码或浏览器活动。把所有耗用都归到代理进程，也可能错过真正的设备瓶颈。

处理器对特定加密运算的支持、客户端实现的优化程度，以及系统对后台任务的调度，都会改变开销。相同协议在不同设备上没有固定不变的排名。持续传输时如果设备明显发热，吞吐随温度上升而下降，或者其他本地应用也开始迟缓，就需要考虑性能和散热，而非继续更换远端地区。此时减少并发任务、恢复默认日志级别，并选用兼容的简单配置，通常更有助于判断原因。

怎样得到有用的对比结果

先选择能代表真实用途的任务，而不是只运行吞吐测试。远程办公可以观察文档同步与会议恢复，AI 工具可以观察提交请求到开始响应，以及输出过程是否停顿，流媒体则关注开始播放和拖动进度后的恢复。每个任务都应使用同一目标来源，并记录失败形态。若某次任务被目标服务限流或排队影响，它就不能单独用来评价代理线路，更不能拿来给所有协议下结论。

协议切换只有在面板确实提供相近条件的候选时，才适合做相对直接的比较。若不同协议同时对应不同地区和不同承载路径，就应把结论写成“这个组合更适合当前任务”，不要声称已经证明某协议更优。遇到无法控制的条件，应承认比较边界。对照过程比最终排名更重要，因为它让之后换设备、换网络或遇到晚高峰时，仍能按相同方法重新判断。

资源选型最终是体验、兼容性与设备负担之间的平衡。日常小任务无需为了追求理论吞吐而增加复杂封装；长时间高负载也不应只看开始是否迅速。保持可恢复的配置，使用客户端正常维护的功能，减少与目标无关的调参，能够让测试更清晰。若需要选择流量额度，可另看套餐价格；流量额度与协议性能是不同问题，不应混为选型依据。

无线通信与后台唤醒怎样消耗电量

移动设备的能耗不只来自加密计算。无线模块从空闲进入活跃状态、维持通信、处理重传，以及系统唤醒代理进程，都可能消耗电量。频繁发送很小的数据也可能让无线模块持续活跃。因此空闲时的后台行为与持续下载时的处理效率，应分开观察。某种协议在大文件传输中资源占用较低，并不意味着它在长时间待机时也一定更省电，两种负载涉及的主要成本可能不同。

连接保活用于帮助维持网络设备中的映射和连接状态，但过于频繁的保活会增加通信与唤醒，过于稀疏则可能让空闲连接失效。最佳设置依赖接入网络、系统后台策略和服务端行为，不存在适用于所有设备的通用参数。正常使用应先保留订阅与客户端默认值。只有在明确复现空闲恢复失败时，才有理由研究维护设置，而不是把激进保活当作常规提速手段。

系统限制决定后台行为

iOS 对网络扩展与后台执行有系统级约束，客户端界面留在前台与设备锁屏后的行为不必然一致。Android 的后台限制、电池优化和厂商管理策略，也可能影响连接进程。排查时应观察断开是否总发生在锁屏、切换应用或系统清理之后，再检查系统允许的后台运行设置。直接把所有省电机制关闭并非必要步骤，应该围绕实际故障做最小调整，并保留调整前后的记录。

从无线局域网切到移动网络时，地址、路由和网络设备状态都可能改变。某些连接能恢复，某些需要重建，目标应用自己的会话也可能超时。此时客户端显示已连接，但应用仍需重新请求，并不必然意味着代理状态错误。可以先尝试重新加载目标任务，再检查客户端连接和当前网络是否一致。若只是网络切换后的短暂恢复问题，不宜把它与持续传输中的随机断流混在一起。

把待机、前台和弱信号分开观察

比较电量时，应尽量保持屏幕亮度、应用任务、信号条件和设备温度相近。弱信号下无线通信本身可能更费电，目标应用后台同步也会改变结果。如果换协议的同时换了网络，便无法把差异归因于协议。系统电量统计可以帮助寻找异常进程，但统计归属并不总能直接解释链路成本；应结合设备是否发热、是否频繁重连、是否存在持续上传来判断，避免只凭单张截图下结论。

待机耗电异常时，先暂停不必要的自动测试和频繁更新，再检查日志是否反复出现连接重建。持续重试可能意味着入口不可达、证书或认证失败，也可能是系统不断结束后台进程。前台高负载发热时，则应减少并行下载，确认是否开启了与当前任务无关的复杂处理。两类问题的处理方向不同，不能靠更换一个听起来更轻量的协议名称同时解决。

实际选择可以保留日常配置与特殊任务配置，但不应为了自动切换而增加难以理解的规则。日常以连接恢复、后台兼容和电量可接受为主；大流量任务再考虑持续传输表现。VPNUO 支持 Windows / macOS / iOS / Android / Linux，同时在线设备不限台数，但设备数量不代表不同平台会表现一致。客户端获取和订阅导入仍应通过面板完成，相关操作见快速上手。

直连：路径直接不代表网络距离最短

这里的直连指客户端直接连接所选远端入口，不额外经过服务提供方安排的中转环节。它减少了人为增加的转发层，但互联网路由仍由沿途网络决定。地图上相邻的地区，实际路径可能绕行；看起来更远的地区，反而可能拥有更合适的互联。地理距离只能作为初步候选依据，不能替代实际任务验证。选择直连时，应同时观察当前接入网络到入口的路径，以及出口到目标服务的表现。

直连的优势通常是结构容易理解、转发环节相对少，但它对公共网络的互联变化更敏感。如果平时正常、特定时间普遍变慢，问题可能来自共享路径拥塞，而非客户端参数。此时继续更换同一路径上的协议，效果可能有限。可以保持目标服务不变，换用面板提供的其他入口或线路类型，再对照是否改善。结论应针对当前路径，不宜扩展成所有直连线路都存在相同表现。

中转：增加环节，也可能改善互联

中转在线路中引入额外入口或转发节点，让用户先到中转位置，再由后续链路连接远端。多经过一个环节会增加处理与传播成本，但如果后续路径比原先的公共互联更合适，整体体验仍可能改善。因此“跳数更多必然更慢”并不准确。需要衡量的是总路径、排队和转发处理的共同结果，而不是只数节点名称。入口质量、入口到出口的承载，以及出口到目标站点都需要考虑。

中转也有共享资源和故障定位的复杂性。入口拥塞可能影响不同出口，某段转发异常则可能只影响部分线路。若多个地区同时出现相似故障，但它们共用相同入口，应优先怀疑共享环节，而不是认为所有目标地区都出了问题。客户端通常无法完整看到内部路径，因此用户记录可观察的现象即可，不需要自行推测机房结构。实际入口与线路绑定应以面板信息为准。

IEPL 专线：明确承载范围与剩余变量

IEPL 专线可用于组织相对可控的承载路径，但专线并不覆盖从用户设备到目标应用的所有环节。家中无线网络、接入运营网络、出口后的公共路径，以及目标站点自身仍可能影响体验。专线标签说明的是线路组织方式，不能被理解为所有访问始终无波动。讨论稳定性时，应明确哪些环节可能更可控，哪些仍是外部变量，避免把某段承载能力扩大成整条业务链路的保证。

同样，专线也不能自动解决账户权限、目标服务地区策略或应用服务器排队。AI 工具不能登录、流媒体目录不同、游戏服务器维护等问题，可能与承载路径无关。选择专线后若吞吐改善但目标功能仍不可用，就应检查应用层，而不是继续更换安全参数。VPNUO 的地区与可选线路请查阅全球节点，本页不推定任何具体城市、机房或协议绑定。

实际选线可以先保留适合目标地区的候选，再比较不同拓扑在真实任务中的连续表现。不要把国家覆盖数量当成某个国家的线路质量，也不要为了地图距离不断切换出口。VPNUO 覆盖 110+ 国家 / 160+ 线路，这提供了选择空间，但具体可用内容仍以面板为准。对需要保持登录状态的应用，应在开始任务前确定候选，尽量避免任务进行中反复改变出口。

丢包、延迟和抖动怎样影响应用

延迟描述数据往返所需的时间，抖动描述这种时间的变化，丢包则表示部分数据未能按预期到达。它们影响不同应用的方式不同。文件传输通常能依靠重传恢复，但可能出现速度波动；实时语音和游戏更关注及时到达，过晚的数据即使补回也可能失去价值。因此下载正常并不能证明实时业务适配良好，单次连接测试看起来很低，也不能代表整个任务期间都没有抖动。

丢包不一定来自远端线路。无线信号干扰、接入设备负载、后台上传、接口切换和路径拥塞都可能参与。某些测试请求还会受到网络设备的低优先级处理，因此测试中的丢失不应直接等同于实际业务丢包。应结合真实应用是否停顿、重传或重连来判断。若测试异常但任务始终正常，先记录现象即可；若任务明显受影响，再逐步更换接入方式和候选路径进行对照。

晚高峰为什么容易变慢

晚高峰通常意味着共享资源上的并发需求增加。接入网络、公共互联、中转入口、出口或目标服务都可能形成瓶颈。当到达的数据超过某段链路及时处理的能力时，队列会增长，交互等待变长，严重时还会丢包。协议可以改变发送和恢复方式，却不能创造不存在的物理容量。如果多个应用都在同一时间变慢，应先怀疑共享路径，而不是对每个应用分别调整配置。

家庭网络也会出现排队问题。后台备份或持续上传占用链路时，浏览网页和会议可能同时变迟缓，即使下行看起来仍有空间。排查时先暂停后台流量，再比较交互任务是否恢复；条件允许时换成有线连接，或者靠近无线接入设备。这样的本地对照成本较低，也能避免把无线环境问题误报成远端故障。若本地变化没有影响，再转向线路与目标服务层面。

用故障范围决定下一步

所有应用都失败时，先检查本地网络是否可用，再确认代理模式、订阅有效状态和入口连接。只有某个应用失败时，优先检查分流规则、域名解析、目标站点状态和账户条件。只有某类传输失败时，则检查 UDP 或相关转发能力。若同一应用换网络后恢复，接入路径值得重点关注；若换多条线路仍在相同操作处失败，目标应用或本地状态更值得调查。

诊断连接时要区分“入口已建立”与“请求已完成”。客户端可能成功连接代理服务，却在出口到目标站点的阶段失败；也可能传输已经正常，但应用等待远端处理。日志中的证书错误、认证失败、解析失败和超时，指向不同环节。应记录错误类别与发生步骤，不要只保留最终的断开提示。提交材料前清理用户名、订阅内容和访问凭据，避免公开分享完整配置。

线路测试只是线索。排查顺序应由故障范围决定：本地网络、流量接管、连接建立、目标访问，再到持续业务表现。

路径 MTU 不匹配也可能造成难以理解的停顿：小请求正常，大数据传输异常，或特定网络下部分内容反复加载。它只是可能原因，不能凭现象直接确诊。优先让客户端使用正常的自动处理或默认配置，并比较其他接入网络；确需调整时，应根据客户端文档和支持建议操作。盲目修改分片、缓冲和超时参数，会增加变量，让原本可以定位的问题变得更难复现。

向支持提交问题时，写清设备平台、网络类型、发生步骤、候选地区和错误类别，并说明哪些对照已经做过。不要附带不必要的个人内容，也不要把目标网站的私密对话作为证明材料。可通过客服页面或面板工单继续沟通；常见连接问题也可查阅帮助中心。有结构的记录能让下一轮排查更具体，而不是重复尝试已经确认无效的操作。

AI 工具与远程办公：先稳定会话

AI 工具的体验往往包含登录、提交、等待生成和持续接收输出。开始响应缓慢可能来自网络建立，也可能来自远端排队；输出中途停止可能涉及长连接、应用超时或路径变化。选择时先保持相对固定的地区和出口，再观察真实任务是否能够完成。频繁换地区可能引发额外验证，也会让问题难以比较。相关用途可继续阅读AI 加速说明，但最终仍以目标服务的访问结果和账户条件为准。

远程办公则应把会议、文档同步与远程桌面分别验证。会议更重视抖动与恢复，同步更关注持续传输，远程桌面还会放大交互等待。优先选客户端兼容、后台恢复正常、长任务能完成的组合，再研究协议之间的差别。不要在会议进行中反复切换线路来追逐测试数值；可以提前确认备用候选，在确实影响任务时切换，并记录切换前后的故障是否相同。

流媒体与游戏：对准业务的限制条件

流媒体选线不能只看起播速度。还应观察持续播放、拖动进度、切换节目后的恢复，以及目标平台账户与地区政策是否允许当前内容。协议和线路有助于改善传输，但不能替代平台授权，也不能保证特定地区目录。若开始播放正常而后续持续缓冲，应检查吞吐与共享流量；若只有某个节目不可播放，则要区分内容条件与连接问题。进一步说明见流媒体专题。

游戏关注的是到游戏服务路径上的及时传递，而不是到任意测试地址的结果。语音、登录和对局可能使用不同目标与传输，必须分别观察。全局代理可能改变更多流量的路径，未必符合游戏所需的精细路由；协议支持 UDP 也不等于已适配某个游戏。可以参考游戏加速与代理的区别，先确定问题发生在登录、联机还是对局，再决定是否适合使用当前代理组合。

建立可保留、可回退的选择顺序

实际决策可以从当前客户端完整支持的订阅组合开始，先确定目标地区，再比较线路类型，最后才在可控条件下比较协议。得到适合日常任务的配置后，保留一个用途明确的备用候选，并写下切换理由。配置更新后若出现变化，应先核对订阅是否完整刷新，再复测原来的任务。不要同时导入来源不明的规则和参数，也不要把其他服务的设置直接拼接到当前订阅中。

技术选型与套餐选择应分开。VPNUO 月订阅为 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB，流量按开通日每月重置，中途升级差价折算成剩余天数。流量包为 ¥158/300GB、¥358/1000GB、¥658/3000GB，用完为止，永久不过期。应按实际使用量与使用节奏选择，不把价格档位理解为特定协议、地区内容或性能等级的保证，完整信息以套餐价格页为准。

账户方面，无需邮箱地址，使用用户名和密码即可注册；同时在线设备不限台数，支持支付宝 / 微信 / USDT，并提供 30 天无理由退款。退款细则见使用条款。这些是服务条件，不是技术测试结论。完成本页查阅后，回到真实任务验证：连接能够建立、目标能够访问、过程能够持续、异常能够恢复。满足这些条件的组合，才是适合当前设备、网络和用途的选择。