协议与线路技术参考

协议、客户端与线路的分层判断

名称相同，不代表路径相同

一次网页访问会经过应用、系统网络接口、客户端、入口服务器以及目标服务。代理协议只规定其中一段连接如何认证、封装和传递数据，不能代替整条路径。节点名称里写着相同协议，实际入口位置、出口网络、承载方式和拥塞程度仍可能不同。因此，比较连接体验之前，应先确认比较对象究竟是协议实现，还是两条完全不同的网络路径。

客户端负责把订阅里的参数变成实际连接，还负责域名解析、规则匹配、连接复用与系统接管。订阅则是参数的交付方式，不是独立的加速技术。更新订阅可能改变节点地址、证书信息或分流规则，但不会自动修好本地无线信号，也不会提升目标网站的处理能力。理解这个边界，能避免把所有异常都归因于订阅失效，或者反复导入同一份内容。

把故障拆成可观察的阶段

连接建立可以拆成解析入口地址、到达入口、完成认证、建立目标连接以及接收应用响应。页面长时间空白，可能发生在这些阶段中的任何位置。域名解析失败时，客户端甚至没有开始协议握手；认证失败时，线路可能完全可达；目标站点响应缓慢时，代理通道也可能正常。排查时应记录失败发生的阶段，而不是仅记录一句“节点不能用”。

路由规则决定哪些请求进入代理，哪些保留原有出口。浏览器能打开网页，不等于所有应用都使用了同一路径；系统代理生效，也不等于所有应用都遵循系统代理设置。虚拟网络接口通常能覆盖更多应用流量，但仍受客户端实现、平台权限和规则影响。检查出口时，应使用实际需要访问的应用，并同时观察客户端是否出现对应连接记录。

服务范围与技术结论分开记录

VPN94 的覆盖范围为 100+ 国家 / 190+ 线路，支持 Windows / macOS / iOS / Android / Linux，同时在线不限台数。这些是服务范围，不是某条线路的吞吐量或可达性保证。具体节点、可选协议及客户端能力，以登录后的面板和实际客户端显示为准。本文讨论的协议用于建立技术比较框架，不表示每个节点都提供文中列出的全部组合。

协议还需要与传输层、加密层分开看。例如 VLESS 描述代理交互方式，而外层传输与安全配置会影响连接行为；Trojan 通常依赖 TLS 提供传输保护，但证书校验是否正确仍取决于配置。节点标题往往省略这些细节，只凭简称无法复原完整技术栈。需要深入判断时，应查看客户端识别出的协议和传输字段，而不是根据图标或名称猜测。

保留一份简短的观察记录，比收集大量无背景的测速截图更有用。记录接入网络、是否使用有线连接、应用名称、所选节点、协议以及异常现象，并写清是首次打开慢、持续传输慢还是后台恢复失败。共享记录前删除账户信息、订阅地址和认证内容。这样得到的描述既能用于自查，也能帮助支持人员区分本地接入、代理通道与目标服务问题。

流式协议的设计取舍

Shadowsocks 与 VMess

Shadowsocks 的核心思路是用相对简洁的代理封装转发流量，常见实现通过加密与认证保护客户端到服务器之间的数据。具体行为取决于所选加密方法、实现和传输方式，不能只根据名称断定资源占用。它的使用价值通常在于生态成熟、参数表达直接，适合已有兼容客户端的环境；是否支持所需的数据报转发，仍应核对客户端和服务端的共同能力。

VMess 在代理会话中包含身份验证及协议自身的数据处理逻辑。它经常与不同外层传输一起出现，因此连接是否顺畅，既受协议实现影响，也受外层封装与服务器部署影响。某个 VMess 节点表现不佳，并不能推导出所有同名节点都较慢。对于已有稳定配置的用户，迁移的理由应该是兼容需求或可复现的问题，而不是把协议名字的新旧当作性能依据。

Trojan 与 VLESS

Trojan 通常运行在 TLS 连接之上，由外层安全传输承担加密保护，协议层负责认证与代理请求。证书、域名以及服务端配置需要相互匹配。关闭证书验证可能让原本明显的配置错误暂时消失，却失去对服务端身份的正常校验。遇到证书错误时，应检查系统时间、订阅是否最新及节点参数是否完整，而不是把跳过验证当作常规优化步骤。

VLESS 的设计将协议自身的数据处理保持得较轻，实际安全性需要结合外层安全机制判断。看到 VLESS 并不意味着数据天然已经受到充分保护，也不意味着必然比其他协议省电。外层传输、连接复用方式和实现路径可能改变结果。对使用者而言，可靠的做法是导入服务提供的完整参数，避免只复制协议名称后自行拼凑不理解的安全或传输选项。

TCP 的可靠性与等待成本

这类协议常见于以 TCP 为基础的传输组合，但协议名字与底层传输并不是严格的一一对应。TCP 提供有序、可靠的字节流，接收端需要按顺序交付数据。路径丢包时，后续数据可能已经到达，却仍要等待缺失部分恢复。对网页和文件传输，这种可靠交付很重要；当很多业务共享同一条有序通道时，等待也可能扩散到原本没有丢失的数据。

额外封装通常服务于兼容性、部署方式或连接管理，不应简单理解为越少越好。增加一层传输可能带来额外握手与处理，也可能使部署更符合当前网络条件。反过来，盲目去掉封装，可能破坏服务器所要求的连接格式。客户端提供的高级开关应当围绕具体问题调整，每次只改变明确理解的选项，并保留能够恢复的原始配置。

日常选择可以先从当前平台兼容良好、证书验证正常、连接记录清晰的组合开始。若网页打开和长连接都稳定，没有必要为追逐协议名称不断迁移。需要核对具体节点提供什么组合时，查看服务器与线路说明及面板，而不是把本文的技术分类当成库存清单。协议选型的目标是减少当前环境中的问题，不是完成一份名称收集表。

Hysteria2 与 TUIC 的传输边界

QUIC 改变的是传输组织方式

QUIC 建立在 UDP 之上，在传输层整合安全握手、可靠数据流和连接管理。UDP 本身不提供可靠交付，但这不代表基于 QUIC 的应用流量就会任意丢失；可靠性可以由上层协议实现。理解这一点，才能避免把“使用 UDP”直接等同于“不可靠”，也避免把“基于 QUIC”直接等同于“所有网络都更快”。底层数据报能否顺利通过，仍是先决条件。

QUIC 可以在同一连接中组织相互独立的数据流。当某个流的数据需要重传时，其他流不必因为同一个传输层有序字节流而全部等待。不过，各流仍共享实际链路容量和拥塞状态。无线信号差、出口队列积压或服务器资源不足时，多流设计不能创造额外带宽。它缓解的是某些等待关系，不是取消链路上的物理限制，也不是对应用体验的统一承诺。

Hysteria2 的拥塞控制需要匹配环境

Hysteria2 使用 QUIC，并具有面向代理流量的传输与拥塞控制设计。实际实现可能提供与带宽估计相关的参数，也可能使用不同的拥塞控制路径，具体以客户端支持为准。把带宽相关选项填写得越大，并不会自动得到更多吞吐量；错误的估计可能增加排队、丢包和对其他业务的干扰。无法确认含义时，优先保留订阅或客户端提供的默认配置。

在存在随机丢包或路径波动的环境中，Hysteria2 的实际体验值得比较，但不能脱离线路进行判断。若所在网络对 UDP 有严格限制，可能出现连接建立失败、空闲后失联或传输中断。此时应保留能正常工作的其他传输方案作为备选，先确认本地网络条件，再讨论参数优化。持续失败的底层通路，不会因为反复切换拥塞选项就变成可靠连接。

TUIC 的连接组织与实现差异

TUIC 同样利用 QUIC 承载代理流量，并围绕连接复用、流与数据报转发组织交互。其体验受客户端实现、服务端配置、路径质量及应用类型共同影响。对于大量短连接，连接保持和复用可能影响首次请求成本；对于持续数据传输，拥塞控制与服务器处理能力更值得观察。不能仅凭双方都使用 QUIC，就假定 TUIC 与 Hysteria2 的行为完全一致。

QUIC 的连接标识为路径变化提供了协议基础，但连接迁移是否生效，要看实现、配置与对端支持。设备从无线网络切换到蜂窝网络时，应用仍可能重新认证，系统也可能暂停后台进程。迁移能力不等于任何应用都能不断线。比较移动切换体验时，应观察正在进行的实际业务是否恢复，而不是只看客户端界面上的连接开关是否保持开启。

用业务结果验证，而不是只看连接成功

客户端显示握手成功，只说明认证与初始通路已经建立。数据报转发、较大的响应、空闲后的恢复仍可能受到网络设备状态或路径报文大小影响。可以分别观察普通网页、持续下载与需要数据报的应用，判断异常是否只出现在某类业务。不要用持续的大流量测试掩盖空闲恢复问题，因为频繁传输会不断刷新中间设备的连接状态，反而改变原本要观察的条件。

选择这类协议时，应同时保留兼容性与资源成本的视角。QUIC 常由用户态实现承担更多传输逻辑，设备较弱、并发较多或吞吐量较高时，处理负担可能变得明显。反之，良好的实现也可能减少某些等待并改善交互。没有设备和网络背景的“必选协议”结论没有可迁移性。适合当前场景的协议，应当能在正常使用、空闲恢复和网络切换中重复得到可接受的结果。

连接建立、吞吐与资源占用

首次打开与持续传输是不同指标

首次打开页面，常常包含域名解析、代理握手、目标连接与应用层请求。持续下载则更接近观察已经建立的通道能否稳定传输。两者可能得出不同感受：某条线路首次响应较慢，但下载保持平稳；另一条线路打开很快，传输一段时间后却出现明显波动。因此，“速度快”必须说明具体指哪种任务，否则连比较对象都不明确，更难判断应该更换协议还是更换路径。

连接复用能够让后续请求沿用已有连接，减少重复建立的成本，却也可能让很多请求共享同一故障点。测试时应区分首次启动、连接已经预热以及长时间空闲后的状态。浏览器缓存、域名缓存和已经建立的目标连接都会改变结果。为了比较而不断刷新同一页面，往往测到的是缓存命中与已有连接，而不是真正的首次连接体验，记录时应把这些条件写清楚。

资源消耗不只来自加密

客户端的处理成本包括加密认证、报文封装、规则匹配、域名解析、虚拟接口转发以及日志输出。高吞吐时，内存复制与用户态处理可能比某个协议头的大小更重要；大量短连接时，连接管理和规则计算可能更突出。设备硬件加速能力、操作系统网络实现与客户端代码路径不同，同一协议在不同平台上的资源表现也可能相反，不能把桌面观察直接套到移动设备。

内存占用也应结合使用阶段判断。订阅中的节点与规则需要存储，域名和连接缓存会随着使用增长，活跃连接还会持有缓冲区。连接结束后，内存未立即下降不一定意味着泄漏，运行时可能保留空间用于后续请求。真正值得关注的是在相似负载下是否持续增长、是否影响其他应用，以及重启后是否只在特定操作中再次出现，而不是截取某个孤立的占用数值。

建立可重复的比较条件

实际比较应先关闭不相关的大流量任务，保持接入位置与目标服务相近，再改变所选节点或协议。不要同时调整分流模式、解析方式与协议，否则即使体验改善，也无法确定是哪项变化起了作用。每次改变后观察相同操作，包括打开页面、持续使用与空闲恢复。如果目标服务本身波动较大，应换一个性质相近的目标交叉验证，而不是不断扩大测速并发。

处理器占用升高并伴随吞吐停止增长时，可以检查是否由虚拟接口、复杂规则或客户端实现造成瓶颈。若设备空闲而所有目标都慢，应更多关注本地接入和线路。若只有单个服务慢，先排除目标侧限流、区域调度或应用重试。不要把协议切换当成唯一排错手段；它可能同时改变入口和出口，从而让真正的问题被暂时绕开，却没有被准确定位。

技术记录最终应该给出条件明确的结论，例如“当前无线网络下，所选节点在持续传输时较平稳，但空闲恢复需重新连接”。这比“某协议最快”更有用，也更容易在网络条件变化后重新检验。涉及流量成本时，参考套餐价格，不要把大量重复测速当作日常维护。测试的目的是支持选择，达到可判断的程度后即可停止，把后续观察放回真实工作负载。

移动端电量与后台行为

唤醒频率可能比协议名称更重要

移动设备的耗电既来自处理器，也来自无线通信模块与屏幕。代理连接需要在后台维持时，保活报文、域名请求、应用推送和失败重试都可能使设备无法长时间休眠。因此，省电不能只比较协议是否“轻量”。某种协议处理开销较低，但如果连接频繁中断并不断重试，整体耗电仍可能更高。稳定的接入网络和合理的后台行为，往往比单独更换协议名称更重要。

保活用于维持中间设备中的连接状态，并帮助发现失效通路。间隔过于激进可能增加后台唤醒，过于宽松则可能让空闲连接在网络设备中提前失效。这里不存在适用于所有接入网络的统一设置。客户端默认值通常是较合理的起点；只有观察到明确的空闲恢复问题，并理解所改选项对应的连接类型时，才考虑调整，不能把任意缩短间隔当成通用修复。

后台限制与网络切换需要分开排查

如果前台使用正常，锁屏后才断开，应先检查系统是否限制了客户端的后台活动，以及客户端是否取得所需的网络权限。若仅在无线与蜂窝网络之间切换后失败，则更可能涉及路径变更、重新认证或旧连接恢复。两类现象可以同时出现，但排查顺序不同。先在固定网络下观察锁屏恢复，再观察主动切换网络，能避免把系统暂停误判为协议迁移能力不足。

低电量模式、数据节省模式及厂商后台策略可能改变联网行为。放宽限制前，应理解它会增加后台运行机会，而不是自动改善线路质量。只为客户端开启与需求相符的权限，保留系统的其他保护设置。若应用自身在后台暂停，代理通道仍在线也无法替它维持所有业务状态。需要判断哪一层中断时，可以观察其他应用是否同步失联，以及客户端恢复后是否需要重新建立连接。

用相似使用负载比较电量

比较耗电时，应尽量保持屏幕亮度、前台应用、网络信号和使用内容相近。视频播放与纯文字浏览的数据量不同，系统更新与相册同步也会引入大量后台流量。系统电量页面有时会把部分网络扩展开销归入其他项目，不能只看客户端名称旁的占比。更合理的观察是整体电量变化、设备温度、连接重试是否频繁，以及同样任务完成后是否出现明显差异。

分流可以减少不需要代理的业务进入通道，但规则是否准确比规则数量更重要。把依赖多个域名的应用拆到不同出口，可能增加重试与认证问题；把所有业务都送入代理，又可能增加不必要的处理和传输。先使用完整、匹配当前客户端的规则，再针对明确异常调整。修改后同时检查应用是否正常、连接记录是否符合预期，不能只以客户端显示“已连接”作为成功标准。

移动端最终应保留一个在常用接入网络中稳定的默认方案，再准备兼容性不同的备选。设备长期发热、锁屏后流量持续增长或日志反复出现重连时，先停止不必要的诊断输出并检查后台任务。客户端获取统一通过用户面板，登录后即可获取订阅；iOS 获取条件以面板显示为准。安装与授权步骤仍以使用指南为主，本章只解释选择与观察方法。

直连、中转与专线拓扑

入口、承载与出口分别看

线路可以按入口、跨网络承载和出口拆开理解。入口决定设备先连接哪里，承载决定数据如何经过后续网络，出口决定目标服务看到的访问来源。地理距离只是其中一项因素，运营商互联、路由策略和链路拥塞都可能改变实际路径。节点名称中的国家或地区常用于描述出口，并不保证入口位于同一地点，因此不能简单把地图距离换算成真实的连接质量。

直连通常表示设备直接连接所选服务端入口，没有另设显式的代理中转环节，但互联网路由仍会经过多个网络设备与运营商。路径较简单时，部署环节可能更少；当本地接入到远端网络的互联质量不佳时，直连也可能出现明显波动。直连不是较低质量的同义词，更不是零中间节点。是否适合，应结合当前接入网络与目标任务观察，而不是根据标签先做判断。

中转优化的是到达远端的方式

中转是在设备与远端出口之间增加转发入口，让数据先到达较合适的接入点，再经过后续承载。多出一个环节可能增加基础等待，却也可能避开质量较差的公共互联路径。因而，中转线路在某些网络下反而更稳定。中转的价值取决于入口可达性、后续承载与出口质量的配合，并不是仅仅“多放一台服务器”，也不能只凭转发层数判断优劣。

IEPL 专线通常指线路承载中采用国际以太网专用连接的部分。对订阅服务使用者来说，它是拓扑信息，不是端到端独占资源的承诺。本地无线网络、设备到入口的接入段、服务端资源以及出口到目标网站的路径仍可能共享或拥塞。即使专线承载段表现平稳，其他环节也会影响最终体验，所以不能把专线标签解释为所有时间、所有应用都保持相同性能。

去程与回程可能不同

网络路由不一定对称。设备发出的数据与远端返回的数据，可能经过不同运营商与互联位置。下载正常而上传异常，或请求发出很快但响应迟缓，都可能与这种差异有关。普通使用者不必据此推断具体故障设备，但应避免用单向观察代表整条链路。需要支持协助时，说明上传、下载或交互中哪一部分异常，比只报告一个延迟读数更有诊断价值。

出口地区也不等于目标服务的内容地区。服务可能结合账户资料、支付信息、设备定位、缓存和出口网络属性进行判断。切换节点后内容没有变化，不一定说明线路没有切换；反过来，出口查询变化也不能保证目标应用按相同地区展示。涉及流媒体或工作账户时，应保持符合目标服务规则的使用方式，并把内容地区问题与网络连接问题分开处理，避免反复切换放大认证干扰。

选线可以先在同类拓扑中比较，再跨类型判断差异。记录常用网络下的默认线路与备选线路，重点看工作时段的真实业务表现。查看IEPL 与线路类型说明时，留意具体线路以面板显示为准，不把示例地区与某种拓扑固定绑定。线路名称适合帮助检索，完整判断仍需要入口可达、持续传输和目标访问这些可重复观察的结果。

丢包与晚高峰拥塞的排查

丢包不一定来自远端线路

丢包可能发生在无线接入、家庭路由器、运营商互联、服务器入口或出口路径。无线信道干扰、设备节电、路由器处理负载以及链路队列溢出，都可能表现为页面停顿或视频缓冲。看到重传增多时，不应立即认定是远端节点故障。先在当前网络观察普通访问是否也出现异常，再换接入方式交叉验证，才能判断问题是否已经存在于进入代理之前。

拥塞意味着某段链路在当前时刻无法及时处理所有到达的数据，报文可能先排队，再因为缓冲区不足被丢弃。排队会增加等待，即使尚未明显丢包，交互也可能已经变慢。持续下载占满本地上行时，正常请求和确认报文也可能受到影响。因此，晚高峰卡顿与家庭网络中的大流量任务可能叠加，停止后台传输后再观察，是成本较低且有解释力的检查方式。

区分小请求正常与大传输异常

若简单网页能打开，较大图片、上传或持续传输却经常停住，应考虑路径报文大小、数据报转发或目标服务处理差异。虚拟接口与隧道会增加封装开销，路径上的报文大小发现如果受阻，可能产生特定类型的卡顿。这不意味着所有类似现象都该修改 MTU。先确认问题可以跨目标重复出现，再按客户端文档或支持建议处理，避免用随意调整掩盖真正的拥塞。

若只有单个应用异常，优先查看其错误提示、账户状态和连接记录。请求被目标拒绝，与代理握手失败是不同问题；域名走错规则，与整条线路不通也不同。若所有应用同时出现问题，再检查本地接入、客户端状态及节点。按影响范围缩小原因，比轮流重装客户端更有效，也能保留现场信息。反复清空配置可能暂时改变症状，却让后续无法确认原始故障条件。

晚高峰比较需要跨路径验证

工作时段正常、繁忙时段变慢，确实可能提示共享链路或出口拥塞，但目标网站的用户高峰也会造成类似现象。可以保持目标服务不变，比较不同入口或承载；再保持线路不变，比较不同目标。若所有线路访问同一服务都慢，而其他服务正常，目标侧因素更值得关注。若同一接入网络的所有外部访问同步变差，应先检查本地与运营商路径，而不是持续切协议。

协议调整主要改变传输如何应对当前路径，不能增加已经耗尽的链路容量。更积极的发送策略可能暂时维持吞吐，也可能造成更长队列与更多丢包；更保守的策略可能牺牲峰值，却让交互更平稳。实际工作需要的是符合任务的表现，不是让测速界面出现更大的读数。对视频画质问题，可继续阅读码率、带宽与画质变化说明，把缓冲与内容选择分开分析。

提交支持请求时，保留接入网络、设备平台、所选节点、问题出现的业务和复现步骤，并说明已经做过哪些对照。日志只截取必要片段，删除订阅地址、用户名及认证信息。支持入口使用用户面板工单。在原因尚未明确时，可以暂用已验证的备选线路维持工作，同时保留原始记录；恢复业务与查明原因可以并行，不必靠不断重启来碰运气。

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

网页、文档与 AI 工具看交互连续性

网页浏览和在线文档更关心首次响应、短请求完成以及长连接能否维持。AI 工具还可能持续返回生成内容，页面能打开不代表后续响应始终顺畅。先选择在常用接入网络中认证正常、空闲恢复可靠的线路，再观察生成过程中是否中断。遇到应用错误时，同时检查目标服务状态与账户条件，不应把所有响应异常都归因于协议，更不能用频繁切换出口代替问题定位。

这类任务适合先使用客户端兼容成熟的默认组合。若首次访问慢，检查域名解析与连接建立；若持续响应中断，检查线路波动、后台限制和连接恢复。基于 QUIC 的方案可以纳入比较，但前提是当前网络支持正常。选择标准应写成“当前设备下请求能稳定完成”，而不是“某名称适合所有 AI 工具”。任务、设备与路径改变后，原有选择也需要重新确认。

流媒体、下载与实时业务关注点不同

视频和大文件更依赖持续可用吞吐与波动情况。短时间传输很快，不能说明整段观看或下载都平稳。播放还受到目标平台编码、内容分发、账户权限与设备解码能力影响。先观察缓冲是否持续增长、画质是否因网络波动反复变化，再比较线路；不应仅因为某条线路带有专线标签就假定内容地区或画质已经得到保证，也不应把应用自动选画质当成纯粹的测速结果。

会议、语音和交互式任务更在意等待波动与数据报处理。平均延迟相近时，偶发的长时间排队也可能明显影响体验。确认客户端是否支持目标业务所需的转发方式，并避免让后台大流量任务占满接入网络。某条线路下载表现突出，不代表它一定适合实时业务。比较时应使用实际会议或应用环境，观察声音连续性、操作响应和切换网络后的恢复，而不是只测文件下载。

技术适配之后，再判断订阅方式

多设备使用时，不必要求所有平台都选择相同协议。桌面设备可以偏重持续传输和工作兼容，移动设备可以偏重后台恢复与电量。VPN94 同时在线不限台数，但不同设备的客户端能力、系统权限及网络环境仍不同。把稳定配置按设备分别保留，比把桌面上的高级选项照搬到移动端更可靠。订阅中的可选组合有变化时，应先更新并核对兼容性，再修改长期使用的默认方案。

技术适配与计费需求应分开判断。VPN94 月订阅为 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB，流量按开通日每月重置，中途升级差价折算成剩余天数。流量包为 ¥158/300GB、¥358/1000GB、¥658/3000GB，用完为止，永久不过期。选择依据是使用节奏与流量需求，不是协议名称；具体说明查看套餐页，不把套餐档位当作未经提供的速度等级。

最后保留一个清晰的决策顺序：先确认平台与协议兼容，再确认接入网络可达，随后比较真实任务，最后决定默认线路和备选线路。VPN94 无需邮箱地址，用户名与密码即可建立账户，提供不记录日志策略与 60 天无理由退款，支持支付宝 / 微信 / USDT。这些服务事实有助于核对订阅条件，但不能代替技术验证。仍不熟悉参数含义时，可阅读订阅、节点与分流名词速查，或返回使用指南按主线完成配置。