协议与线路技术参考

先把协议、传输和线路分开

同一个连接问题，可能发生在不同层

客户端里看到的“节点”，通常是若干配置的合称：入口地址、认证信息、协议、传输方式、出口位置和路由规则都可能包含在内。协议约定客户端怎样与入口交换数据；传输方式决定这些数据如何借助 TCP、UDP 或 TLS 等机制送达；线路拓扑则描述入口之后的数据经过哪些网络路径。一个页面打开慢，不能只凭协议名称判断原因。设备到本地网络的连接、入口是否可达、跨境段拥塞以及目标服务的响应，都会落在同一个加载进度条上。

先确认“故障发生在接通前，还是接通后”。如果客户端连入口都无法建立会话，优先检查订阅是否仍有效、系统时间是否准确、当前网络是否允许所用传输，以及客户端是否支持该配置。若会话已经建立，只有某类网站缓慢，则应查看分流规则、目标服务所在地区和出口线路。若所有应用在相近时段一起变慢，再考虑共享链路的拥塞。按层排查比反复更换协议名称有效，也能避免把目标网站自身的错误归因于本地客户端。

比较协议之前，先固定比较条件

“换了协议就变快”的观察只有在其他条件相近时才有参考价值。比较时尽量使用同一设备、同一接入网络、同类目标服务和相近的测试时段；记录切换前后的线路类型、出口地区与客户端模式。如果同时从远距离直连切到近距离专线，又更换了协议，就无法判断体验变化来自哪一层。实际使用不必追求实验室式测试，但至少要知道自己改动了什么。线路页上的地区名称表示可选出口，不直接等于设备到入口的物理距离。

协议也不是“加密强度排行榜”。Shadowsocks、VMess、Trojan、VLESS、Hysteria2 与 TUIC 的设计目标、可选传输和实现方式各有差异，安全属性需要结合实际加密层、客户端实现和密钥管理判断。比如 VLESS 本身不以自带加密作为卖点，常与 TLS 等传输安全机制组合；带有 TLS 的配置，也仍需正确验证连接对象。名称相同的两个配置可能采用不同传输，名称不同的配置也可能共用同一段拥堵链路。

另一个容易混淆的词是“规则模式”。它决定哪些流量进入代理、哪些流量保持原路径；它不改变协议握手，也不会修复拥塞。应用走错规则时，用户可能误以为某个协议完全不可用。判断时先确认目标请求实际走了哪条路径，再讨论协议差别。需要完成导入与连接的读者可回到使用教程；需要查看覆盖地区与线路类型的读者可转到线路列表，两页与这里分别解决操作、可选项和原理问题。

阅读后续章节时，可以把“接通”理解为入口会话已建立，把“可用”理解为目标请求确实按预期完成。前者是必要条件，却不是后者的保证。客户端显示已连接而网页不动时，先检查规则、解析结果和目标服务；客户端持续重连时，先检查握手与入口。区分这两个状态，能让故障描述更准确：向支持人员反馈时，说明发生在哪个阶段，比只写“连不上”更容易定位。

Shadowsocks 与 VMess：看实现，不只看名称

Shadowsocks 的简洁性来自职责集中

Shadowsocks 主要解决客户端与服务端之间的代理数据交换，常见实现可承载 TCP 与 UDP 流量。它的概念相对直接：客户端取得目标请求，按配置建立到入口的连接，再由入口转送。配置里真正值得核对的是加密方法是否被双方支持、认证信息是否匹配，以及 UDP 转发是否在当前客户端和线路上启用。只看到“Shadowsocks”几个字，不足以推断视频通话、游戏或网页的表现，因为这些应用使用的传输方式可能不同。

较简洁的协议结构通常便于兼容不同客户端，也便于在设备之间迁移订阅。但简洁不意味着可以忽略实现细节：客户端内核对加密方法的支持范围、系统代理接管方式、DNS 处理以及连接复用策略，都会影响结果。如果网页能打开、实时语音却没有响应，应先区分语音流量是否使用 UDP，再确认相应转发能力，而不是立刻判定服务器带宽不足。反过来，单个应用无法连接，也可能是它没有遵循系统代理设置。

VMess 的可配置空间也增加了核对项

VMess 的连接配置通常与传输层参数一起出现。比较两个 VMess 节点时，要同时看承载方式、加密相关设置和客户端支持情况。握手失败未必说明出口不可用：参数不匹配、设备时间异常或旧客户端不理解配置字段，都可能使会话在转发目标请求之前终止。导入订阅后若只有某一类配置失败，先更新客户端并重新获取面板内的订阅配置；不要手工猜测认证字段。订阅与客户端均通过用户面板取得，页面不提供静态订阅地址。

VMess 常被与 Shadowsocks 简单归为“老协议”和“新协议”，这种排序对选型帮助有限。协议诞生先后不能替代对当前实现、传输与线路路径的判断。在同一设备上，额外封装可能带来更多处理工作；在某些网络上，经过合理配置的传输又可能更贴合既有连接方式。最终体验受应用请求模式影响：短请求关心会话建立和往返等待，长时间下载更关心链路持续吞吐，实时互动则对抖动与丢包更敏感。不能用单一网页加载结果为所有场景排序。

实践中可以先选择客户端能完整识别的配置，确认目标应用能接通，再比较相同线路类型下的体验。不要把协议芯片上的名称当作服务等级；也不要因为某次连接顺利，就推断它在所有接入网络都相同。家庭网络、公共无线网络与移动网络可能对连接保持和 UDP 有不同处理方式。设备切换网络后出现变化，先测试同一配置是否仍可握手，再考虑更换传输或入口。

如果需要长期使用多个设备，留意各平台客户端是否采用相同的规则和 DNS 设置。VPNTF 支持 Windows、macOS、iOS、Android、Linux，且不限台数；这说的是服务可覆盖的平台与设备数量，不表示不同系统的代理接管方式完全一样。同一订阅在桌面端正常、移动端异常时，先核对移动端的系统权限、后台限制与规则模式。把平台差异和协议本身的差异分开，才不会在错误的层面反复切线。

Trojan 与 VLESS：分辨身份验证和传输保护

Trojan 的 TLS 会话仍要正确建立

Trojan 常以 TLS 承载代理会话。客户端首先需要完成与入口的安全连接，随后才进入代理请求的交换；因此，证书验证、目标名称和设备时间都值得检查。连接在握手阶段失败时，查看客户端错误属于证书验证、名称不匹配、网络不可达还是认证失败，比直接更换目标网站有效。TLS 是传输保护的一部分，不代表整个使用过程不受出口、DNS 或设备环境影响；本地规则错配仍可能让请求走向与预期不同的路径。

建立安全会话需要交换信息，新的短连接对握手更敏感；会话复用与连接保持则可能减少反复建立的成本。实际客户端如何复用，取决于实现和配置。不能因为某协议涉及 TLS，就断言它一定比其他协议慢，也不能因为一次连接很快，就忽略其后的线路质量。长时间使用时，入口到出口的稳定程度往往比最初握手的体感差别更重要。遇到“起初可用，过一会儿中断”，还要检查网络切换、设备休眠及连接保活行为。

VLESS 要连同外层传输一起阅读

VLESS 着重于身份与数据转发机制，本身不应被理解为完整的传输加密方案。看到 VLESS 配置时，需要继续查看它搭配的 TLS 或其他传输安全机制、采用的承载方式以及客户端是否支持整套组合。仅凭协议标签不能判断连接如何保护数据。对普通用户而言，不必手工拼装参数；从面板取得配置、使用受支持的客户端导入，再核对客户端显示的完整节点信息，比单独搜索某个协议名称更稳妥。

Trojan 与 VLESS 的比较也要避免“标签即结果”。如果两条配置的入口位置、传输、出口地区和线路类型不同，体验差异并不能归因于身份验证机制。可先在同一个目标应用上确认请求是否按规则经过目标线路，再比较接通阶段是否稳定，以及连接后的持续表现。对于频繁打开小页面的使用方式，握手与重连会更显眼；对于持续传输的大文件，拥塞控制和路径稳定性更值得关注。不同场景的瓶颈可能在不同层，单一结论很难通用。

移动设备在无线网络间切换时，原有 TCP 会话可能失效，客户端需要重新建立连接。若切换后只有某条 Trojan 或 VLESS 配置不恢复，先确认客户端是否检测到网络变化，再确认配置使用的承载方式能否在新网络下接通。桌面设备一般更容易保留前台连接，但系统休眠和唤醒也会产生类似症状。观察发生的动作——切网、锁屏、唤醒，还是单纯放置——比只记录“断线”更能指向原因。

还要区分入口连接成功与目标网站接受请求。某些网站会根据账户地区、登录状态或自身策略返回不同内容；换成带 TLS 的代理协议，并不自动改变这些条件。需要定位流媒体地区问题时，应先看目标出口和对应线路标记，再看应用缓存或账户状态。协议负责把请求送到选定路径，目标服务怎样响应仍由其自身决定。相关内容可参考站内流媒体解锁说明，不要用协议名称替代地区判断。

技术选型的底线是配置完整且可验证。客户端报错越靠近握手开始，越应先检查参数与设备；报错发生在目标请求阶段，越应检查规则、解析和出口。记录客户端展示的错误类别即可，反馈时不要公开完整订阅内容或认证信息。这样既保留了排查线索，也避免把配置问题扩大为账户风险。

Hysteria2 与 TUIC：理解 QUIC 的收益和边界

UDP 承载改变了连接处理方式

Hysteria2 与 TUIC 通常建立在 QUIC 之上，而 QUIC 以 UDP 承载连接，并把加密和传输控制结合在一起。这种架构可减少某些连接建立过程中的等待，也提供不同于传统 TCP 会话的连接管理方式。它并非“UDP 一定比 TCP 快”的证明：无线信号不稳、接入网络对 UDP 的处理、目标路径的拥塞以及客户端实现，都会改变实际体验。如果当前网络无法稳定送达 UDP 数据包，再先进的上层机制也无法凭空补回缺失的链路。

QUIC 的一个重要特点是把多个应用数据流放在同一连接中管理。某一路数据遇到丢包时，其他数据流不一定要像共享同一 TCP 字节流那样等待按序交付。不过这不表示丢包没有成本：丢失的数据仍要恢复，拥塞控制仍需调整发送节奏，设备与入口仍要消耗处理资源。浏览器快速加载许多资源时，这类差别可能值得关注；持续传输或实时交互则还要看实际拥塞算法、路径质量和应用自己的重试行为。

Hysteria2 与 TUIC 不宜只按名称排位

两者都可能使用 QUIC，但认证方式、流量管理、客户端支持和具体实现并不相同。选择时先看设备上是否有稳定支持该配置的客户端，再看当前网络对 UDP 的表现。若导入后根本无法建立会话，先检查应用权限、系统网络模式与客户端兼容性；若接通后偶尔停顿，则记录停顿是否伴随无线网络切换、信号变化或高负载应用。不同情况对应的排查方向不同，不能把“连接失败”和“连接后抖动”合并处理。

移动端尤其要留意连接保活。设备锁屏后，系统可能限制后台网络活动；客户端为了维持会话也可能周期性唤醒网络模块。保活过于频繁会增加设备活动，保活不足则可能在恢复前台时经历重新握手。具体耗电取决于系统调度、无线信号、客户端设置和实际使用强度，无法从协议名称单独推算。优先观察锁屏前后是否确实需要持续连接，再按客户端提供的后台选项调整，不必为了维持一个闲置会话而盲目拉高活动频率。

如果一种接入网络下 QUIC 配置顺畅，换到另一种网络却无法连接，不必据此判断出口已停止工作。先回到原网络确认相同配置仍能接通，再在新网络上尝试受支持的其他传输。这里的“切换”是诊断动作，不是要求长期维护多份手工配置。订阅更新可能带来新的可选线路，检查面板中的当前配置比保存一份很久以前的参数更可靠。

处理持续性卡顿时，要把“握手快”与“传输稳”分别记录。QUIC 会话建立顺畅，只说明入口阶段通过了；跨境段若有拥塞，视频缓冲和文件传输仍会受影响。反之，握手稍慢但持续数据稳定的配置，可能更适合长时间工作。优先根据应用场景挑选，不把协议宣传词当成对所有网络环境都成立的结论。

连接建立、资源占用与移动端电量

短任务看建立过程，长任务看维持过程

连接建立通常包含名称解析、到入口的网络连接、协议认证，以及可能需要的 TLS 或 QUIC 握手。应用发出请求之前，任一环节等待都会被感知为“点开后没有反应”。同一协议在连接已存在时可能表现顺畅，新建连接却显得迟缓，因此测试时要分清冷启动与连接复用。网页里多个资源也未必各自建立全新会话；客户端和应用对连接池的处理，会显著影响体感。单看协议理论上的握手流程，无法完整预测页面加载时间。

连接保持后，资源占用主要来自加解密、数据复制、封装、规则匹配以及系统网络唤醒。高吞吐任务可能让处理器持续工作，短而频繁的后台请求则可能让无线模块频繁醒来。设备温度、同时运行的应用和信号质量都会改变耗电情况。比较时应先固定应用负载与屏幕状态，再观察切换协议是否带来稳定、可重复的变化；一次电量波动不足以说明某个协议天然省电。

平台接管方式比协议标签更容易被忽略

Windows 和 macOS 上，应用是否跟随系统代理取决于软件自身设置；部分程序会使用独立网络栈。iOS 和 Android 上，客户端可能通过系统提供的网络扩展或 VPN 接口接管流量，后台运行受系统电源策略影响。Linux 的代理环境变量、桌面代理设置与透明转发并非同一回事。遇到“浏览器正常、命令行异常”时，先核对进程使用的代理方式；遇到“前台正常、锁屏后断开”时，先看系统后台策略。这些差异不该被误写成协议速度差异。

判断设备负担时还要分清持续连接和持续传输。客户端界面保持“已接通”，不表示设备一直以高负载处理数据；但某些应用频繁同步，也会让看似闲置的连接产生网络活动。如果担心电量，先在系统电池页面找出实际消耗网络资源的应用，再检查客户端的后台运行方式。直接关闭所有连接保持功能可能导致每次唤醒都重新握手，结果未必更省电。让客户端按实际使用需求运行，比追求某个抽象的“最低开销协议”更实用。

开发者调用 AI API 时，还应把应用层超时与连接建立时间分开。请求在排队、服务端处理或流式返回阶段中断，不一定是入口握手慢；并发任务共享同一出口时，也可能在应用自身的连接池中等待。记录请求开始、会话接通和收到响应的阶段，再调整程序的重试与超时策略。站内AI API 选线指南专门讨论固定出口、并发与超时的判断，本页侧重底层网络原因。

如果多设备同时使用，VPNTF 的“不限台数”表示可在支持的平台上接入，不表示每台设备一定拥有相同吞吐。家庭网络的共享带宽、各设备运行的任务以及所选出口都会影响体验。先在单台设备上确认配置正确，再逐步恢复其他任务，比在所有设备同时活动时判断协议优劣更容易。需要了解流量额度，可对照套餐价格；流量按开通日每月重置，流量包则用完为止、永久不过期。

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

路径短，不等于每一段都顺畅

直连表示设备经通常的网络路径到达线路入口或出口，路径结构相对容易理解，可能减少额外中继。但跨网络运营方的路由选择不是只看地图距离：绕路、互联点拥塞或回程不一致，都可能使看似较近的地区出现更长等待。入口地区与出口地区也可能不同。判断直连线路时，不仅看目标国家名称，还要看自己所处网络到入口的稳定性，以及目标应用从出口继续访问服务端的路径。

中转在设备与最终出口之间加入转送环节，用不同的入口与路径组织流量。它可能避开某段不稳定互联，也引入额外的转发与排队环节，因此并非天然更快或更慢。同一条中转线路在不同接入网络上的收益可能相反：一个网络到入口很顺畅，另一个网络却在最初一段就有丢包。比较时先固定目标出口地区，再在直连与中转之间切换；若出口也同时改变，目标服务返回的地区内容和连接时间都可能一起变化，难以分辨拓扑因素。

专线更应看持续性，而不是名称

IEPL 专线属于线路类型标签，关注的是受管理的跨境链路安排。专线可能让跨境段的路由更可控，但设备到入口以及出口到目标服务的路径仍需单独考虑。专线不等于对任意网站、任意时段的固定延迟承诺，也不应据此推断线路不会拥塞。如果某个目标服务在专线出口地区本身响应缓慢，切换跨境段未必能解决。应先确认问题发生在进入出口之前，还是出口访问目标之后。

拓扑和协议是可以分别调整的维度。同一种协议可能出现在不同线路类型上，不同协议也可能共用同一跨境段。当晚高峰所有协议都在某个出口变慢，优先比较不同线路拓扑或地区；当同一线路类型中只有某个配置握手失败，才优先检查协议与传输。这样的交叉比较能够缩小问题范围。切换时保留原配置作为参照，不要连续更改协议、地区、规则模式和目标应用，否则最后只知道“换完好了”，不知道原因。

地域选择也要按目标服务来定。访问账号有地区关联的应用时，出口地区的连续性可能比地理距离更重要；读取公开资料或进行普通网页检索时，可以先试更近、连接稳定的出口。VPNTF 的线路覆盖为 100+ 国家、210+ 线路，这说明可选范围，不意味着每个国家对每个目标应用的表现相同。线路列表提供地区、城市、线路类型与流媒体标记，适合在明确目标地区后缩小候选范围。

另需注意“线路断开”与“目标请求失败”不是同一事件。客户端仍显示接通，但单个网站加载失败时，可以尝试同地区的其他出口、确认分流与解析结果，再检查目标服务是否要求重新登录。如果客户端入口反复掉线，则先回看设备到入口的接入环境。按拓扑拆分后，排查不再依赖一个笼统的“线路质量”标签，而能指向具体哪一段需要切换。

丢包、抖动与晚高峰拥塞

同样是“卡”，底层原因可能不同

丢包是发送的数据没有按预期抵达，需要重传、恢复或由应用自行处理。抖动是到达时间不稳定；即使数据最后都到达，实时语音和互动操作也可能出现停顿。拥塞则是路径中某处待发送的数据超过了当时可处理的能力，排队、延迟增加和丢包可能同时发生。视频应用通常会通过缓冲掩盖短暂抖动，实时会议却更容易暴露问题；因此“视频还能播”不能证明实时链路没有波动。

晚高峰的共同特征是许多用户与应用同时占用共享网络资源，排队位置可能在本地无线网络、接入运营商、跨网互联、线路中转段或目标服务。若只在某个时间段出现，先用相同设备和目标重复观察，再比较不同线路类型或地区。若其他本地应用也同时变慢，优先检查家中或当前接入网络；若只有某个国际目标异常，再看分流和出口。不要把时段相关性直接写成“某个协议不稳定”，协议本身并不知道当前网络处于什么时段。

用症状判断重传发生在哪里

TCP 传输通常通过确认与重传保证有序交付。丢包后，等待缺失数据会影响后续交付，也可能触发发送节奏调整。基于 QUIC 的传输采用不同的流管理方式，但同样无法免除数据恢复和拥塞控制的成本。如果所有应用的持续吞吐都下降，并伴随操作响应变慢，先考虑共享路径或接入问题；如果只有初次打开缓慢、建立后稳定，更应查看解析与握手；如果仅实时应用断续，而网页基本正常，优先观察 UDP 流量和抖动。

不要把单次延迟数值当成整条路径的体检报告。一次探测可能只测到入口，实际请求还需要经过出口到目标服务；有的网络也会区别处理探测流量与应用流量。更有价值的是观察同一任务在相近条件下是否反复出现相同症状，并记下发生时设备是否切换网络、客户端是否重连、目标是否换了地区。记录过程不需要公开任何认证数据。可用“打开页面的等待阶段”“视频开始后是否反复缓冲”等描述，代替一个孤立的数字。

切换线路时，先找相同目标地区下拓扑不同的候选项，避免地区变化影响账户内容。若中转改善了稳定性，说明原路径中的某段可能是瓶颈，但不能仅凭一次切换断定故障点；若专线与直连都出现相同停顿，还需看两者是否共享接入段或目标服务。反复刷新页面只会增加请求变量。让应用完成一个完整任务，再换候选项观察，通常比连续快速拨动开关更容易看清变化。

部分应用自带重试与缓存，故障可能被延后呈现。视频先消耗缓冲区，随后才卡住；API 调用可能等待应用层超时后才返回错误；即时通信则可能在网络恢复后集中送达消息。因此要结合应用行为解释症状，而不是仅凭客户端“已连接”图标。对开发场景，区分 DNS、TCP 或 QUIC 建连、TLS 握手和应用响应阶段尤其重要。对普通用户，记住“刚打开慢”和“用着用着慢”对应不同排查入口即可。

当一个出口持续不适合当前任务时，切换到其他地区或线路类型是合理操作，但不必追求任何时段都使用同一条线路。常用目标可以保留已验证的地区选择，出现明显变化再检查当前网络与线路。若问题只发生在单个服务，也要考虑对方的服务状态、账户地区及应用缓存。链路问题和目标服务问题可以同时存在，按层记录比寻找一个万能协议更可靠。

按场景选型，按阶段排查

先确定任务需要什么

普通网页浏览可先选择与目标地区匹配、客户端能稳定接通的线路，不必先研究所有协议细节。频繁打开新页面时，观察首次连接等待和规则是否正确；连续阅读、下载资料时，再观察保持连接后的稳定性。观看流媒体时，先看线路列表的流媒体标记与出口地区，再看播放是否持续缓冲。标记是选线线索，不是对所有片库、账户和清晰度的统一保证。若账户本身有地区设置，应连同应用端状态一起核对。

AI 网页工具和 AI API 也应分别处理。网页端更像普通交互应用，要关心页面资源、登录状态和会话保持；API 调用还要关心出口是否稳定、程序如何复用连接、并发请求如何排队，以及失败时如何重试。先固定出口地区完成基本调用，再按错误发生阶段调整超时，而不是遇到应用返回错误就直接更换协议。开发者可继续阅读AI API 调用选线指南；它讨论应用层设置，本页负责解释底层连接取舍。

实时会议、语音或互动应用对抖动更敏感。先确认目标应用流量确实经过选定线路，再观察当前网络对 UDP 的处理；如果应用在无线网络切换后短暂中断，先看客户端的重连行为。长时间下载与大文件同步则更看重持续吞吐和路径稳定，选择时可以把协议握手快慢放到次要位置。移动设备需要长时间后台工作时，还要把系统电源策略纳入判断，别让平台行为被误判为线路本身的问题。

把故障描述写成可执行的检查顺序

如果“完全无法接通”，先确认订阅状态与客户端是否已更新，再看设备时间、权限、所用网络及配置兼容性。若“显示接通却无法打开目标”，先核对规则模式与目标请求路径，再看 DNS、出口地区和目标应用状态。若“接通后逐渐变慢”，先排除本地网络负载，观察是否只在特定时段出现，再比较同地区的不同拓扑。若“切换网络后才出错”，先检查客户端重连及新网络对传输的支持。每完成一项再进行下一项，避免同时改动多个条件。

做选择时，先使用设备上支持完整配置的客户端；然后按目标服务确定地区；接着在该地区比较直连、中转与专线；最后才在可选协议之间微调。这不是给协议排固定名次，而是减少无关变量。VPNTF 提供 Windows、macOS、iOS、Android、Linux 平台支持和不限台数的使用范围。客户端与订阅从用户面板获取，具体协议组合及可选线路以面板和客户端实际展示为准。需要重新走一遍导入流程时，请返回使用教程。

若还在比较服务方案，可先阅读套餐价格：月订阅为 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB；流量按开通日每月重置，中途升级差价折算成剩余天数。流量包为 ¥158/300GB、¥358/1000GB、¥658/3000GB，用完为止、永久不过期。购买决策与技术选型是两回事：先根据实际流量选择额度，再按应用选择线路。服务支持支付宝、微信、USDT 付款，并提供 7 天无理由退款。

长期使用时，保留一份简短的个人判断记录即可：常用目标、所需出口地区、当前设备、接入网络、可用线路类型，以及出现问题时的阶段。配置变化后重新验证，不把过去一次顺畅的体验视作永久结论。需要了解订阅、节点与分流等基础术语，可读新手名词速查；想进一步判断长期订阅，可读长期订阅选购说明。本页的核心方法始终相同：先定位层次，再只切换需要验证的那一项。