协议与线路技术参考

CONNECTION MODEL

连接模型与判断顺序

协议、传输、线路分别负责什么

一次网页访问并不是客户端到服务器的一条简单直线。应用先提出目标地址，系统或客户端决定流量是否进入代理，客户端再连接入口，把请求交给远端出口，最后由出口访问目标服务。协议负责身份验证与请求表达，传输负责数据如何在网络中送达，线路则决定这些数据经过哪些运营商和链路。把它们混成“节点好不好”，很容易在错误的位置反复修改设置。

同样标着 VLESS 的连接，可以搭配不同传输和安全层；同样标着东京的线路，也可能经过不同入口和中转路径。因此，协议名不能直接推出延迟、吞吐或可访问的内容范围。看到新协议不必立刻替换现有连接，先确认当前问题发生在建立连接、持续传输，还是访问特定目标。只有把故障阶段分开，后续比较才有明确含义。

连接建立快，不等于长时间传输快

打开网页时，域名解析、传输握手、安全协商和远端建立目标连接，都可能成为等待来源。首次访问通常还包含缓存尚未命中的开销，随后刷新则可能复用连接。若用首次访问的新线路与已预热的旧线路比较，结论会偏向后者。较稳妥的做法是保持相同目标、相同客户端模式和相近测试条件，分别观察首次打开、再次访问以及连续使用的表现。

大文件传输更看重持续吞吐，通话更看重抖动和短时丢包，交互网页则经常受请求建立时间影响。下载速度看起来很好，会议仍然卡顿，并不矛盾：拥塞时排队可以让吞吐维持在较高水平，却把实时小数据包拖在队列后面。选型时应先写清“哪里不好用”，不要把所有体验压缩成一个速度评价，也不要把客户端的探测结果当成目标网站的实际响应。

建立可以复查的比较记录

记录时保留使用地区、接入网络、线路名称、协议、客户端模式和症状即可，不需要公开账户凭据。线路名称相近也要记录完整分组，否则难以确认是否真的换过路径。比较期间暂停后台下载，保持目标服务和设备不变；遇到异常再改变一个条件，例如只换入口或只换接入网络。多个条件一起改，虽然可能暂时恢复，却无法解释问题，也不利于之后复现。

本页的资源占用和建立速度都采用条件性描述，不给协议排固定名次。实现质量、加密硬件支持、连接复用和服务器负载，可能比协议本身的差别更明显。若连接已经符合使用需求，维持兼容且便于排查的方案往往更合理。只有出现可复现的短板，再针对那个短板调整，才能避免为追求名称上的更新而引入额外变量。

先确认请求是否进入预期线路，再讨论线路性能。分流错误造成的直出访问，不能通过更换加密算法解决。

SHADOWSOCKS / VMESS

Shadowsocks 与 VMess 的取舍

轻量协议仍依赖完整的运行环境

Shadowsocks 以加密代理转发为核心，通常具有较直接的请求封装路径。客户端与服务端需要对加密方法、凭据和目标请求格式达成一致，随后把应用流量转发出去。它的实现相对紧凑，常被用于希望减少额外封装、重视客户端兼容性的场景。不过“轻量”只说明设计倾向，并不意味着任意设备上都更省电，也不意味着它能修复接入网络自身的丢包。

实际连接还可能包含插件或其他外层传输。加入这些部分后，握手流程、兼容要求和资源消耗都会变化，不能继续按最简路径估计体验。导入订阅时应保留服务端提供的完整参数，不要只看协议名就手工删去看似多余的字段。加密方法不匹配通常会导致连接失败，而不是自动退回一个较慢但可用的模式，凭据错误也不会靠重复测速自行恢复。

VMess 的身份与时间条件

VMess 是包含身份验证和请求封装的代理协议，可运行在不同的底层传输之上。它的使用体验与客户端实现、外层传输以及是否额外启用安全层密切相关。把 VMess 简化为“比另一种协议慢”会忽略这些条件：同名配置的建立流程可能不同，连接复用方式也可能不同。比较时必须同时看协议、传输和安全设置，而不是只比较订阅列表中的名称。

排查 VMess 时，设备时间是否正常是值得先核对的条件。时间异常可能影响认证，也可能同时影响外层证书验证，看起来就像线路突然全部失效。恢复系统自动校时后，应重新建立连接再观察。不要为了绕开错误而随意调整认证参数；若订阅在另一台设备可用，优先检查本机时间、客户端兼容情况和导入是否完整，而不是立即认定服务器故障。

如何比较而不误判

如果服务提供同一地区、相近路径上的不同协议，可以在相同网络下观察网页打开和持续访问；若线路入口已经不同，结果只能说明整个组合的体验，不能单独归因于协议。尤其不要用一条空闲专线上的 Shadowsocks，与另一条拥塞中转上的 VMess 推导协议优劣。服务端资源、出口路由和目标距离都可能足以改变结果，协议只是其中一层。

需要 UDP 的应用，还要确认服务端、客户端和本地转发模式是否都支持相应转发。订阅里出现协议名称，并不代表所有应用的数据都会自动按期望方式处理。若网页正常而语音异常，应检查 UDP 转发、分流规则与应用自身的连接路径。对于只需稳定浏览和文档工作的用户，优先选择导入完整、客户端支持成熟、实际访问顺畅的现有配置，比手动拼接参数更容易维护。

本页不建议根据网络文章直接替换加密方法或修改传输字段。服务端没有对应配置时，本地调整只会使双方无法协商。有关订阅获取、更新与凭据保管，可继续阅读订阅链接入门指南，先确认配置来源与更新流程，再进行性能比较。

TROJAN / VLESS

Trojan、VLESS 与安全层

把请求协议与加密通道分开理解

Trojan 通常在 TLS 安全连接内完成认证与代理请求。这里存在不同职责：TLS 负责通道机密性和服务端身份验证，代理协议负责说明访问目标以及验证使用权限。证书验证失败与账户凭据错误虽然都可能表现为连不上，但发生阶段不同，处理方法也不同。先读客户端日志中的错误类别，比直接重置全部配置更有效，也能避免把本地时间异常误判成线路故障。

VLESS 的基本请求层不以自身提供内容加密为前提，实际安全属性取决于它所搭配的安全层和传输配置。因此，“VLESS 自身较简洁”不能被理解成“无需检查安全设置”。也不能只看到 TLS 字样就认为整条使用路径都已正确配置。应同时确认服务端身份验证、客户端支持和订阅参数来源，让协议、传输与安全层形成完整组合，而不是把名称当作安全结论。

证书、域名与系统时间

使用 TLS 时，证书需要与预期服务端身份相符。证书链无法验证、域名不匹配或设备时间异常，都可能终止握手。遇到这类错误，不应以关闭证书验证作为常规修复办法。先核对自动校时、订阅更新状态和客户端是否使用系统可信证书；若问题只出现在公共接入网络，还应确认是否需要先完成该网络的正常接入流程，再尝试建立安全连接。

部分订阅包含用于握手的服务端名称、传输路径或其他参数。这些字段并不是显示用备注，修改它们可能改变服务端如何识别连接。复制配置时遗漏字段，常见表现是端口可达却无法完成应用层握手。应优先重新导入完整订阅，而不是根据线路名称猜测参数。向工单提供日志时保留错误类型即可，身份标识、密码和订阅地址应遮盖后再提交。

封装层越多，越需要知道每层的作用

不同传输组合可能额外引入握手、请求头处理和连接维护。它们有各自的部署用途，但并不是层数越多就越稳定。对频繁短请求而言，连接是否复用会影响建立开销；对持续传输而言，底层拥塞与缓冲策略可能更重要。看到复杂的配置不必据此推断性能更好，看到简短配置也不应推断安全不足，必须回到实际启用的安全层和传输行为。

资源消耗同样取决于实现。具有硬件加速的设备处理安全通道时，表现可能与较旧设备明显不同；客户端是否在用户空间转发数据，也会影响处理器占用。若连接正常但设备发热，先观察是否同时开启了详细日志、频繁探测或多个代理程序。把全部额外工作都归因于 Trojan 或 VLESS，会掩盖真正消耗资源的本地处理路径。

VPNWhen 的安全营销话术为“军工级加密”。具体连接仍应检查客户端的安全层与身份验证状态；加密通道不替代账户保管、终端更新和目标网站自身的安全措施。

选择这类组合时，可以把兼容性放在首位：订阅是否被完整识别、客户端是否报告缺失字段、连接能否稳定恢复。技术上可组合的选项很多，服务实际提供的配置却是确定的。遵循订阅提供的组合，通常比照着通用示例自行拼装更可控；涉及首次导入的具体步骤，请回到上手教程完成操作。

HYSTERIA2 / TUIC

基于 QUIC 的传输选择

换一种传输，不是跳过拥塞控制

Hysteria2 与 TUIC 都属于基于 QUIC 的代理方案。QUIC 在 UDP 之上实现安全连接、流与可靠交付等能力，因此“使用 UDP”不等于“所有数据都不保证送达”。浏览网页所需的可靠字节流，仍然需要处理丢失与顺序。理解这一点很重要：换用基于 QUIC 的方案，是改变传输机制与实现策略，而不是让网络容量、排队和无线干扰从此不再产生影响。

不同流可以减少彼此之间某些交付层面的等待，但同一连接仍可能共享拥塞控制和链路容量。某条流大量发送时，其他流也可能受到带宽竞争影响。QUIC 也不能消除接入路由器的排队，更不能缩短地理传播距离。它在某些丢包环境中表现有利，在另一些受限网络中则可能无法顺利建立，选择必须以所在网络是否支持相应传输为前提。

Hysteria2 与 TUIC 的关注点

Hysteria2 的配置与实现会涉及带宽估计、发送策略以及相关拥塞控制行为。错误理解带宽参数，可能导致发送过于激进或利用不足；把参数写得很大不等于线路获得了更多容量。尤其在与其他设备共享网络时，过度占用上行会使交互请求排队，表现为下载仍在进行，网页和通话却明显变慢。服务提供的参数应优先保留，不宜照搬陌生环境中的调优建议。

TUIC 也通过 QUIC 承载代理请求，但认证、转发与具体实现存在自身设计。连接建立、UDP 转发和拥塞策略的表现需要结合客户端支持判断。不能因为两者都使用 QUIC，就把配置字段相互替换，也不能推断任意客户端都支持相同功能。导入后若协议被忽略、线路缺失或报不支持，应先确认客户端能力，而不是把错误线路复制到其他分组继续尝试。

丢包环境与移动切网的边界

无线信号波动导致的随机丢失，与拥塞造成的持续丢失并不是同一种问题。某些策略在前者下能更充分利用链路，面对后者却可能继续增加竞争。若换协议后速度恢复但其他应用明显变差，需要检查共享链路是否被占满。比较不应只看单个下载任务，也要观察同时进行的网页、通话与设备响应，才能确认改善是不是把等待转移给了别的任务。

QUIC 具备支持连接迁移的机制，但客户端、服务端和代理应用是否实际启用，以及接入网络如何变化，都会影响结果。不能据此承诺无线网络与移动数据之间切换时持续无感。切网后如果停在“已连接”却无法访问，应先让客户端重新建立连接，再检查解析与分流是否恢复。界面状态只表示某个连接阶段，不保证所有目标请求都已经成功。

因此，基于 QUIC 的方案适合作为经过验证的选择或备用，而不是唯一答案。若接入网络对 UDP 不友好，保留兼容的其他传输更实用；若主要问题是目标出口拥塞，换协议也未必改变瓶颈。阅读地区与线路说明时，应把传输类型和线路路径一起看，避免用协议名字代替完整选线。

DIRECT / RELAY / IEPL

直连、中转与专线拓扑

入口地区与出口地区不是同一概念

线路列表里的地区通常帮助识别出口，但用户首先接触的可能是另一处入口。请求可以先进入就近入口，再沿中转或专线到达目标地区，最后从出口访问服务。入口影响接入体验，出口影响目标看到的地区与网络来源，中间路径影响持续传输。只按地图距离选择出口，会忽略入口可达性与运营商互联；只看入口很近，也无法推出目标网站一定响应更快。

直连一般表示客户端直接连接远端服务入口，路径层次较少，部署关系也较直观。然而，实际公共网络路由未必沿地理最短路径前进，运营商之间的互联和拥塞会影响结果。它可能在空闲时表现很好，也可能在特定时段波动。直连不是低质量的同义词，更不是低延迟保证，关键仍是所在接入网络到远端入口，以及出口到目标的完整路径。

中转改变的是经过的路径

中转通过额外节点把流量引向另一段网络。看起来增加了跳转，却可能避开原路径中不理想的互联，使实际体验改善；也可能因为中转负载或绕行而变差。多经过一个节点不必然更慢，少经过一个节点也不必然更稳。排查中转线路时要分别考虑接入到中转、中转到出口、出口到目标这些部分，不能将所有停顿都归因于最后显示的地区。

IEPL 专线描述的是特定线路资源与承载方式，不是应用层协议。它可以与不同代理协议配合，也仍然依赖本地接入、服务入口、设备能力和出口到目标的网络。专线有助于提供更可控的跨地区承载路径，但不意味着家庭无线干扰、目标网站故障或客户端错误都会被消除。把专线当作路径条件理解，比把它当作任意场景的速度承诺更准确。

按应用观察完整往返路径

实际请求有去程与回程，它们不一定对称。仅凭客户端看到的路由探测结果，不能完整还原回程，更不能精确指出某个中间设备造成了应用故障。部分路由设备降低探测回复优先级，出现探测丢失也不一定影响真实转发。应把探测当作辅助线索，与目标应用的持续响应一起看，不要仅因某个中间跳点没有回复就认定线路中断。

选择东京、香港或其他地区时，先满足目标服务的地区需求，再比较同地区可选路径。对内容服务而言，地区只是必要条件之一，内容授权、账户设置和出口识别策略也可能影响结果。因此线路表中的示例不能延伸为特定片库的持续保证。对工作应用而言，离服务部署位置更合适的出口可能更有帮助，但仍需要以真实操作验证，而不是按地区名称猜测。

VPNWhen 覆盖 100+ 国家 / 180+ 线路，具体分组与当前可选项以订阅和面板为准。需要查看地区示例时，可前往服务器页面。查阅时把地区、线路类型和协议作为不同维度记录；若连续切换的只是同一路径上的不同备注，可能并没有真正绕开原有瓶颈。

路径优化不能替代目标可用性。入口连得上、出口可达与目标应用允许访问，是需要分别确认的条件。

LOSS / QUEUE / CONGESTION

丢包、抖动与晚高峰拥塞

先分清随机丢失与持续排队

数据包丢失可能来自无线干扰、接入设备处理不足、链路拥塞或路径变化。它在应用中的表现也不同：可靠传输可能等待重传，实时语音可能出现短暂缺口，视频则可能依靠缓冲暂时掩盖。看到画面停顿不能立刻认定远端线路丢包，因为本地设备解码、目标服务响应和后台任务也会造成类似现象。排查的起点应是确认哪些应用同时受到影响。

抖动指延迟随时间变化。即使平均等待看起来可以接受，只要短时波动较大，实时互动仍可能不顺畅。排队是常见来源：当发送速度超过某段链路的处理能力，数据进入缓冲区，后来的交互请求也要等待。缓冲能减少立刻丢弃，却可能扩大延迟。于是“大文件还在下载，网页突然不灵敏”往往值得先检查带宽竞争，而不只是寻找另一种协议。

晚高峰不是单一故障名称

晚高峰意味着使用需求集中，但拥塞位置可能在家庭接入、运营商互联、中转承载或出口侧。若停止本地同步与下载后明显恢复，优先检查家庭网络负载；若同一接入网络上的多个设备同时变差，而换接入网络恢复，则接入路径更值得关注；若仅某条线路异常，其他同地区路径正常，才更有理由把问题缩小到该线路组合，而不是整个服务。

上传被占满尤其容易被忽略。下载任务也需要发送确认和控制信息，视频会议、云端备份同时竞争上行时，交互体验可能先恶化。此时反复测速会继续增加负载，让症状更混乱。应先暂停占用网络的后台任务，再观察真实业务是否恢复；确认共享链路仍有余量后，再比较线路。测试工具本身也是流量来源，不应把它视为完全中立的旁观者。

保持变量可控的排查顺序

先确认普通直连访问与本地网络是否正常，再检查客户端状态和目标分流，随后在同地区选择不同路径，最后才考虑改变传输协议。这样安排不是认定协议不重要，而是先排除影响面更大的条件。若多个协议共用相同入口和出口，切换协议可能保留全部拥塞路径；如果换了接入网络就恢复，继续修改服务端参数通常不如检查本地网络更有价值。

若小请求可用、大内容持续停顿，还可能涉及路径对数据包大小的处理。封装会增加额外开销，路径发现不顺利时可能产生难以直观看出的异常。不过这不意味着应立即手改 MTU。优先恢复客户端默认设置，核对是否存在叠加隧道，并记录故障是否跨网络复现。随意降低参数可能暂时掩盖问题，也可能引入额外碎片或降低效率，具体调整应有明确证据。

提交工单时，写清接入地区、网络类型、线路名称、出现时段、影响应用，以及换网络或换线路后的变化。这些信息比“所有线路都慢”更容易定位。日志只保留必要错误，遮盖订阅链接与身份字段；不要上传含账户凭据的完整配置。需要协助时使用面板工单入口，不必公开敏感内容来证明故障。

关于游戏中的延迟、丢包与代理适用边界，可继续阅读游戏加速与 VPN 的区别。游戏连接成功与获得更好路径是不同问题，应先确认该游戏流量是否真正经过预期线路。

CLIENT / POWER / NETWORK CHANGE

平台兼容与移动端电量

同一订阅不代表相同转发路径

Windows、macOS、iOS、Android 与 Linux 的网络接口、后台调度和权限模型不同。即使导入同一订阅，客户端也可能通过系统代理、虚拟网络接口或应用内转发处理流量。某些应用遵循系统代理，另一些应用则使用自身网络逻辑。因此“浏览器可用但其他应用失败”，首先应检查客户端工作模式与规则覆盖，而不是只看线路开关是否已经打开。

桌面端还要留意多个网络工具同时运行的情况。它们可能竞争系统代理、路由和解析设置，形成请求进入甲程序、解析由乙程序处理的复杂路径。出现异常时，应先退出不需要的工具，恢复单一客户端环境，再验证目标访问。重新导入订阅无法自动消除其他程序遗留的系统设置；如果客户端退出后仍然无法正常访问，应检查系统代理是否按预期恢复。

耗电来自持续工作，不只来自加密

移动端耗电包含加密处理、用户空间转发、无线模块唤醒、连接保活和应用实际传输。空闲时反复探测线路、保持详细日志，可能比协议名称上的差异更值得注意。大量小请求会频繁唤醒网络和处理器，持续大流量则让无线模块保持忙碌。比较电量时应保持相近的使用任务、屏幕状态和网络条件，不能把看视频与待机时的差异归因于协议。

信号较弱时，接入链路自身可能消耗更多资源，重传也会增加额外工作。设备发热不一定表示客户端算法低效，也可能是后台同步、内容解码或网络反复重连共同造成。应先在系统电量与流量统计中确认主要消耗来源，再观察客户端日志是否出现持续重连。若发热只在某个接入环境出现，换一个稳定接入网络比立即改协议更能说明问题。

待机与切网要单独验证

设备休眠后，系统可能暂停应用活动或改变后台连接状态。唤醒时客户端显示上次的连接名称，不代表旧连接仍然有效。若亮屏后短暂不能访问，应观察是否完成重新握手，再判断是否为线路故障。对于 Android，应按客户端说明检查后台管理，不宜盲目放开所有系统限制；对于其他平台，也应区分系统调度造成的恢复等待与远端路径的持续异常。

从无线网络切到移动数据后，本地地址、默认路由和解析环境都可能改变。客户端需要根据实现重新建立或迁移连接，应用也可能保留已经失效的连接池。若客户端重连后浏览器恢复，而某个应用仍卡住，可以先重开该应用，避免把它保留的旧状态误判为线路不可用。切网行为应独立测试，不要与后台下载、休眠恢复同时混在一起比较。

VPNWhen 同时在线不限台数，但设备之间仍会共同使用所选套餐的流量资源；设备数量不应被理解成额外的流量额度。客户端下载统一通过面板下载入口，订阅需登录后获取。除 iOS 外登录即可获取客户端，iOS 的获取条件以面板显示为准，具体导入流程见各平台上手步骤。

连接稳定时，不必为追求理论上的省电而不断切换协议。先减少无必要的探测与调试工作，再用相同任务观察实际耗电。

SCENARIO / VERIFICATION / FALLBACK

按场景选择协议与线路

把主要任务写成可验证的目标

选型从任务开始，而不是从协议列表开始。网页和文档工作重视打开速度与连续响应，视频重视持续吞吐与缓冲，会议重视抖动和短时丢包，长时间任务则重视连接恢复与出口一致性。先确定最常见任务，再选择地区与路径，最后确认客户端支持的协议组合。一个方案能完成主要任务，并且出现问题时容易恢复，通常比技术名称更复杂但难以维护的方案更实用。

对于 AI 工具，稳定的会话、账户自身状态和目标服务的地区政策都可能影响体验。线路连接成功不代表账户一定获得使用资格，也不保证长任务永远不中断。选择满足目标地区需求的出口后，先验证登录、普通请求与持续会话，再判断是否适合实际工作。任务执行期间频繁切换出口可能引入额外验证，因此线路比较应尽量在重要任务开始之前完成。

观看与实时互动采用不同标准

流媒体应先确认内容服务是否接受当前出口、账户地区和内容授权，再观察持续播放。能够打开首页并不能代表目标内容可播放，短片正常也不能推导长时间播放的稳定性。若地区结果不符合预期，先检查分流和出口是否正确；若播放中反复缓冲，再检查路径负载与本地带宽竞争。用协议切换处理内容授权问题，通常并没有对准故障层。

会议、远程桌面和游戏更看重往返稳定性。此时应避免同时进行大量下载，优先选择实际路径平稳的线路，而不是只按大文件吞吐挑选。若应用使用 UDP，要确认客户端模式与远端支持；若应用没有进入代理，协议比较就没有意义。游戏还涉及服务器所在地区和专用优化路径，普通代理不能被推导成所有游戏的加速承诺，详情可参阅相关网络知识文章。

保留备用路径，而不是堆积配置

主线路应承担日常任务，备用线路则尽量提供不同入口、传输或承载路径。若所有备用都共用相同瓶颈，数量再多也未必有帮助。保存能够识别的线路备注，并记录适用接入环境，避免在故障时面对大量近似名称。订阅更新后重新确认主备是否仍然存在，不要长期依赖已经删除的手工配置；订阅链接本身应按账户凭据保管，不应放进公开笔记。

套餐选择与协议选择也应分开。VPNWhen 月订阅为 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB，流量按开通日每月重置，中途升级差价折算成剩余天数。流量包为 ¥158/300GB、¥358/1000GB、¥658/3000GB，用完为止，永久不过期。应依据实际流量任务比较，而不是因为某个协议名称就推断需要更高档套餐，完整说明见套餐页面。

本服务提供 14 天无理由退款，支持支付宝 / 微信 / USDT。无需邮箱地址，用户名与密码即可注册。准备使用前，可先按快速上手教程完成导入，再以常用任务验证地区、路径和恢复行为。若仍不能确定故障发生在哪一层，整理接入环境、线路与症状后提交工单，比持续更换全部配置更容易得到可执行的下一步。

最终保留的不是“最先进协议”，而是在当前设备、接入网络与目标任务下可复现、可解释、可恢复的连接组合。