协议与线路
技术参考

连接分层：先区分协议与线路

一次访问并非只有一条连接

打开网页时，浏览器先确定目标地址，再依据系统与应用的代理设置决定请求走向。客户端可能接收系统代理流量，也可能通过虚拟网络接口接收符合规则的数据；随后才由选中的出站协议，把请求送到远端服务。远端继续访问目标网站，并把响应传回。页面显示缓慢，可能发生在这条链的任意环节，不能只归因于节点名称。

这里至少要区分应用请求、代理连接和线路路径。应用请求关心目标网站是否响应；代理连接关心身份验证、加密与转发；线路路径关心数据经过哪些网络、是否拥塞及如何抵达出口。相同协议放到不同路径，体验可能明显不同；相同路径换成不同协议，也不一定改变最主要的瓶颈。比较时应明确究竟替换了哪一层。

订阅、规则与 DNS 各自做什么

订阅是客户端取得节点和相关设置的入口，不是通信协议本身。导入订阅后，客户端仍须读取可支持的字段，建立可用的出站配置，并通过规则决定哪些连接使用它。名称相同的节点，在不同客户端里可能因传输字段、DNS 策略或规则解释不同而表现不同。排错前先确认配置已成功载入，而不是只看到列表中出现名称。

DNS 负责把域名解析成地址，但解析发生在哪里，取决于客户端模式、规则与应用行为。浏览器可能使用自己的加密 DNS，系统也可能保留旧缓存。于是出口已经改变，部分域名却仍采用另一套解析结果。这种情况应先核对解析路径与分流规则，再决定是否换协议；反复切换节点可能只是暂时绕开缓存，没有处理根因。

把“能连接”拆成可观察的阶段

客户端显示已连接，通常只说明代理进程、虚拟接口或某条会话处于工作状态，不等于目标服务已接受请求。应继续确认出口位置、域名解析和实际应用访问。若网页正常而桌面软件失败，优先检查该软件是否使用系统代理；若所有应用都失败，再检查本地入口、远端握手与订阅状态。这样可以避免在错误的层面反复调整。

同样，“速度慢”也需要具体化。首次打开等很久，可能是解析或握手；页面骨架出现后图片迟迟不来，可能是不同域名走了不同规则；文件开始很快随后下降，可能是拥塞或目标限速。把现象写成可复现的过程，比记录一个笼统的速度评价更有用，也更便于后续对照线路变化。

建立不混淆变量的比较方法

建议保留当前可以工作的配置，另选待比较的出站，使用相同设备、接入网络和目标应用进行观察。每轮只改变协议或节点之一，同时注明客户端模式。若同时打开虚拟接口、替换 DNS、切换地区又修改协议，结果即使变好，也无法判断哪项有效。恢复原配置后问题能否重现，是检验推断的重要步骤。

本页后续比较讨论协议的一般设计，不承诺某种实现总是更快。VPNFine 的实际可选项以面板和订阅内容为准；地区与线路资料可到服务器页核对。想确认流量是否真正经过预期出口，可继续阅读出口 IP、DNS 与分应用验证，再带着观察结果查阅对应章节。

常见协议：加密、认证与传输的边界

Shadowsocks：结构直接，仍需看具体实现

Shadowsocks 面向加密代理转发，常见实现分别处理流式连接与数据报。它没有把所有功能都放进统一的网页式会话，而是围绕代理转发建立较直接的结构。实际安全属性取决于采用的加密方法、密钥管理和实现质量，不能只凭协议名称判断。导入时需要确认客户端能识别订阅中的方法与参数，不应为了消除报错而随意改写它们。

结构较直接，不等于任何设备上的资源占用都最低。操作系统的加密加速、客户端核心、数据复制方式和并发连接规模都会影响结果。数据报转发是否可用，也依赖客户端、服务端与接入网络共同配合。若网页能访问而语音应用异常，应检查数据报支持和应用分流，而不是根据网页成功就判定整条连接没有问题。

VMess：认证与加密需要完整配置配合

VMess 是带有身份认证与数据保护机制的代理协议，可以配合不同的底层传输。节点字段不仅涉及服务器地址，还可能包含用户标识、传输类型及相应参数。历史配置格式与不同实现之间存在差异，因此更适合通过完整订阅导入，避免手工拼接。系统时间异常也可能影响认证判断，出现握手问题时应把时间同步纳入检查。

比较 VMess 时要把协议本身与外层传输分开。例如加入 WebSocket 或 TLS 后，连接建立路径、封装开销与中间设备要求都会改变。看到同为 VMess 的节点表现不同，并不矛盾。需要核对是否使用相同传输、是否经过不同入口，以及客户端有没有忽略不认识的字段；仅对比协议标签无法得出有效结论。

Trojan 与 VLESS：不要混淆认证和加密

Trojan 通常借助 TLS 建立受保护的传输，并在其中执行代理认证与转发。证书校验和服务器名称因此是重要组成部分。若连接失败，应先核对设备时间、证书链及订阅提供的服务器名称，而不是关闭校验来追求连通。关闭校验会改变身份验证的可信边界，也可能掩盖地址错误或连接到非预期服务的问题。

VLESS 的基础设计偏重认证和转发，本身不提供完整的数据加密，需要合适的安全传输配合。评估 VLESS 节点时，必须继续看它外面使用的保护方式与传输设置。把“协议字段简单”理解成“无需加密”，或者把 VLESS 名称直接等同于某种安全传输，都不准确。客户端是否支持订阅实际提供的组合，比单独支持这个名称更重要。

兼容性往往比名义开销更先影响体验

桌面与移动客户端可能使用不同核心，对同一订阅字段的支持也可能不一致。若导入后缺少节点、名称显示正常却无法连接，应先查看客户端给出的解析与握手错误，确认是否有字段未被接受。不要用另一套协议的参数填补缺失项，更不要把证书名称当作服务器地址随意替换。参数之间的对应关系通常需要由服务端一起确定。

实际选型应先找到兼容、能稳定验证的组合，再比较资源与响应表现。对普通网页和办公应用，成熟实现与合适路径往往比追求协议新旧更重要。VPNFine 使用“军工级加密”作为服务信任表述，但技术判断仍需落实到正确的加密配置、可信的软件来源和有效的身份验证；任何标签都不能代替这些具体检查。

QUIC 协议：Hysteria2 与 TUIC 的取舍

先理解 UDP、QUIC 与可靠传输

UDP 提供数据报传输，不自行保证有序到达和重传。QUIC 则在 UDP 之上组织安全连接、流与可靠传输，把过去常由传输层和安全层分别处理的工作放在更紧密的机制中。因此，“走 UDP”不等于应用只能接受丢失的数据，也不代表所有流量都被原样作为裸数据报发送。判断可靠性，要看上层协议如何管理各类数据。

QUIC 可以在同一连接中管理独立的流，使某条流的数据丢失不必像单条有序字节流那样阻塞所有其他流的交付。但它仍共享路径容量和拥塞反馈：出口拥堵、无线干扰或目标响应慢，不会因为采用 QUIC 就消失。对于代理场景，应用连接如何映射到流、数据报如何封装，还要结合具体实现分析。

Hysteria2：发送策略需要与真实链路相符

Hysteria2 基于 QUIC 提供代理传输，其拥塞控制与发送策略是理解使用体验的重要部分。在支持相应设置的实现中，带宽参数可能参与发送行为的判断。把参数填得越大越好，容易让数据在瓶颈前排队，表现为下载仍在进行，但网页交互、语音和其他设备明显变慢。配置应遵循订阅与客户端的说明，而不是复制陌生截图。

它在部分丢包或路径变化环境中可能表现较好，但前提是网络允许所需的 UDP 通信，设备也能承担相应处理成本。若连接建立失败，应先确认同一网络下 UDP 是否可达，再排查证书、认证和地址。仅凭另一个基于 TCP 的节点能使用，不能推断 UDP 路径也正常；两者可能受到不同的网络策略与资源调度影响。

TUIC：复用与转发方式共同影响结果

TUIC 同样使用 QUIC 构建代理通信，涉及连接复用和数据报转发等设计。它与 Hysteria2 不能因为底层相同就视为可互换配置。认证字段、客户端支持、数据报处理方式和拥塞控制选项可能不同。比较时应使用各自完整且有效的节点配置，避免把一种协议的客户端参数套到另一种协议上，造成难以解释的失败。

对于需要同时维护多个请求的应用，连接复用可以减少重复建立外层连接的工作，但复用并非没有代价。外层连接异常会影响其承载的活动，单条路径的拥塞也依然共享。若观察到多个应用在同一时刻停顿，应考虑外层会话与路径状态；若只有某个目标异常，则更应检查该目标、分流规则或出口兼容性。

为什么不能承诺它们总比 TCP 快

接入设备、运营网络和公共无线网络可能对 UDP 设置不同的限制。有的路径上数据报容易丢失，有的路径则存在较短的空闲状态保留时间。为了维持连接，客户端可能需要发送保活；若网络持续丢弃这些包，应用会经历重建与重试。这时更换到稳定的 TCP 路径，可能比继续调整 QUIC 参数更有效。

另一方面，网络质量良好且目标交互简单时，协议间的差别可能被目标服务器响应时间掩盖。不能用某次文件下载结果推断所有场景，更不能用吞吐表现替代首字响应、长连接持续性和移动端耗电。选择前应分别观察这些现象，记录在哪种接入网络下出现，而不是给协议贴上永久的快慢标签。

普通用户适合保留能够稳定工作的配置，再把 QUIC 类节点作为可比较的选项。进阶用户则应优先理解客户端对发送参数、空闲超时与数据报模式的定义。没有明确依据时保持订阅提供的设置，不随意关闭安全校验，也不把技术科普中的协议名称误读为本站对所有平台和所有线路的支持承诺。

连接与资源：响应、吞吐和内存分别看

首次响应慢，不一定是持续速度慢

用户感觉到的“打开慢”，可能包含 DNS 查询、本地代理接收、远端握手、目标连接和应用处理。刚启动客户端、刚切换节点或连接空闲后重新访问，通常涉及更多建立工作；已有可复用连接时，路径又不同。比较协议前应明确是冷启动还是持续使用，否则把不同连接状态放在一起，容易得出相反结论。

TLS 会话恢复与连接复用可以减少部分重复工作，但是否生效取决于服务端、客户端和会话状态。不能根据协议说明就假定每次访问都能恢复，也不应手动清空缓存后拿结果与另一条已建立会话的线路比较。更合理的做法，是先分别记录启动后的首次访问与连续访问，再判断差别集中在哪个阶段。

吞吐量需要足够连续的工作负载

小网页主要受到请求往返和服务端响应影响，大文件则更容易暴露持续吞吐瓶颈。文件下载快，不代表网页交互也快；网页打开顺畅，也不能推断长时间传输没有排队。目标服务的分发策略、文件缓存与出口位置都会改变结果。想比较线路，应固定目标内容，避免一次下载缓存文件、另一次却从源站重新生成。

并发也会改变观察。多个下载任务可以占满链路，让单个任务看起来更慢；部分应用会自动开启多连接，另一些则只使用单条连接。若没有区分这一点，可能把应用行为误当作协议差异。比较期间暂停后台同步、应用更新和其他大流量任务，同时保留正常的网络环境说明，结果才有可解释性。

CPU、内存与缓冲区如何互相影响

客户端要做加解密、规则匹配、数据复制和连接管理。设备支持的加密加速、核心实现及系统调度，可能让相同协议在不同设备上出现不同负担。观察资源时，应看代理进程是否持续占用、设备是否发热，以及前台应用是否同时繁忙。浏览器渲染或视频解码造成的耗用，不应全部计入代理协议。

内存会被规则、DNS 缓存、连接状态与传输缓冲区占用。缓冲区较大可以暂时吸收速度差，却可能在拥塞时延长排队；缓存较多能减少重复工作，也会增加驻留内存。因此内存较高并不自动意味着实现低效，较低也不证明交互更好。需要结合持续增长、连接关闭后能否回落，以及系统是否发生内存压力来判断。

调参应能解释，也应能恢复

复用、缓冲和连接超时属于相互关联的设置。启用复用可能减少握手，也可能改变故障影响范围；延长超时可容忍暂时中断，也可能让失效连接保留更久。没有日志或稳定复现条件时，不宜同时修改这些选项。保留修改前的配置，写明预期改善的现象，再用同样操作验证，未改善就恢复。

桌面端可以通过系统任务管理工具观察代理进程与应用进程，不必为了测量安装来源不明的软件。Windows 用户还应注意系统代理与虚拟接口模式的差异，具体取舍可读Windows 全局代理与规则分流说明。测量的目的不是给协议评分，而是找到设备、路径或应用中的主要限制。

移动端电量：看唤醒、重连与后台活动

协议只是耗电链条中的一环

移动设备使用代理时，电量不仅消耗在加解密，还会消耗在无线通信、后台唤醒、应用刷新与重试。屏幕亮度、信号质量和视频播放都可能掩盖协议带来的差别。只看系统电池页面中某个客户端的占比，也不能直接推断它实际多耗电，因为系统可能把通过虚拟接口转发的部分工作记到该客户端名下。

接入信号较弱时，设备维持通信本身的代价就可能上升。频繁切换无线网络和移动网络，也会触发路径变化与会话恢复。此时持续重连的配置可能比稳定连接的配置更耗电，即使它在静态桌面测试中处理开销更低。评估移动表现时，应同时记录接入方式、信号情况和是否处于移动过程中。

保活不是越频繁越稳定

保活用于维持网络设备中的会话状态，帮助发现连接是否仍有效。发送得过于频繁，会增加通信与唤醒；间隔过长，又可能在某些网络上让空闲状态被清除，下一次请求需要重建。合理设置依赖接入网络与客户端实现，没有适用于所有设备的固定答案。普通用户应先使用订阅和客户端提供的默认行为。

如果待机后经常出现首次请求超时，应先区分系统暂停后台运行、网络状态失效和目标服务断开。前台立即恢复正常，可能与系统调度有关；所有应用都需要重新连接，可能涉及外层会话；只有单个聊天或办公应用异常，则要检查该应用自身的后台限制。直接提高保活频率，未必能解决这些不同原因。

系统后台策略会改变连接状态

Android 的后台运行限制会因系统与设备设置而不同，iOS 的网络扩展也受系统生命周期管理。桌面客户端能长期保留的状态，移动客户端未必能完全照搬。应通过系统提供的相关页面检查客户端是否被限制，避免同时启用相互冲突的网络工具。下载与订阅请走用户面板客户端入口，具体获取条件由面板按账户状态处理。

Wi-Fi 与移动网络切换后，有些基于 QUIC 的实现可以利用连接迁移相关能力，但不能把底层能力直接等同于应用请求永不中断。代理实现、服务端策略和系统网络扩展都可能影响恢复过程。已有的应用 TCP 会话也未必能在外层变化后继续工作。真正需要观察的是切换后的恢复和应用报错，而不是只看图标是否保持开启。

怎样做更公平的电量比较

选择相似的使用过程，保持设备、亮屏情况、接入网络和前台应用尽量一致。分别观察主动使用与待机恢复，不把视频播放与纯文本阅读放在同一组比较。记录是否发热、是否频繁重连、系统是否提示后台限制。若只是电池统计占比变化，而总使用过程不同，不能据此判断协议优劣。

当稳定连接与低耗电发生取舍时，先减少无必要的后台传输、重复订阅刷新和多个网络工具并行，再考虑更换协议。持续重试通常比一次成功连接更值得排查。VPNFine 不限设备台数，因此可在不同设备分别保留适合自身网络的配置；这不意味着所有设备必须使用同一协议，也不意味着家庭接入带宽不再共享。

线路拓扑：直连、中转与专线

出口地区与真实路径不是同一件事

出口地区描述目标网站看到的网络出口位置，不完整描述从设备到出口之间的路径。选择香港出口，不代表数据一定直接到达香港；选择较远出口，也可能先经过本地附近的入口。节点名称常把入口、出口或产品分类压缩在一起，阅读时应结合线路说明。地理距离是影响因素，但不能单独解释网络往返与稳定性。

路径还可能不对称：请求与响应经过的网络未必完全相同。路由策略、互联关系和临时调度都会改变传输体验。某段时间表现很好，只能说明当时路径适合该场景，不能推出永久不变的结论。比较线路时应记录接入网络和目标地区，并把路径资料与实际应用体验相互印证。

直连：路径简单，质量取决于互联

直连通常指设备直接连接远端代理入口，不额外经过服务方设置的中转节点。它可以减少额外转发与管理环节，但公共网络的互联质量仍是关键。接入网络到远端入口的路由合适时，直连可能表现很好；遇到跨网拥塞或绕行，也可能出现较大波动。“环节少”是结构描述，不是稳定性保证。

直连失败时，应区分入口不可达、端口通信失败和目标出口异常。如果换成同地区其他入口恢复，问题可能在入口路径；如果所有入口都只能访问部分网站，应继续查出口到目标的连接。不要把目标网站的访问策略误认为直连线路本身失效，也不要在未确认故障层面前反复更改本地 DNS。

中转：多一个环节，可能换来更合适的路径

中转先把数据送到入口，再由入口转发到出口。增加转发并不必然更慢，因为原本不理想的公共路径可能被更合适的互联替代。与此同时，中转增加了需要维护的连接与资源；入口负载、转发容量或中转到出口的链路异常，都会影响体验。它解决的是路径组织问题，而不是让物理距离或容量限制消失。

诊断中转线路时，可以根据现象区分入口段与后续路径。若同一入口下多个出口同时异常，入口或共享链路值得优先检查；若只有某个出口访问特定目标失败，则继续看出口与目标的兼容情况。用户未必能直接观测全部内部路径，因此应把可复现现象提交给支持人员，而不是仅凭名称推断内部故障点。

专线：明确承载范围，不把标签扩大

IEPL 专线通常用于描述路径中采用专用承载的部分，有助于减少部分公共互联的不确定性。但用户接入到入口，以及出口到目标网站，仍可能经过公共网络；具体边界需要以服务资料为准。专线不等于端到端每一段都独占，也不等于所有内容服务都接受该出口，更不能替代设备与应用端的正确配置。

因此选线应从接入网络、目标地区和使用过程出发。对交互应用关注往返与抖动，对持续传输关注稳定吞吐，对地区内容关注出口位置及平台规则。VPNFine 覆盖 90+ 国家 / 150+ 线路，具体可选地区与类型请查服务器页。覆盖规模帮助提供选择，但无法单独证明某条线路对当前设备一定最合适。

丢包与晚高峰拥塞：按现象定位

丢包、延迟与抖动需要分开理解

延迟描述数据往返所需的时间，抖动描述这种时间的变化，丢包则表示部分数据没有按预期抵达。对可靠传输，丢失数据通常需要重传，因此用户未必看到明显错误，却可能感到停顿。语音和实时交互更容易暴露抖动；文件下载则可能通过缓存与重传掩盖短暂波动。不能只凭页面最终打开，就判断路径质量稳定。

无线干扰、接入设备排队、跨网互联拥堵和远端资源不足，都可能造成相似现象。中间路由设备还可能降低诊断报文的响应优先级，使探测看起来有丢包，而实际业务转发正常。因此路径探测只能作为线索，应结合目标应用的持续表现。某个中间节点没有回复，不足以证明那一段正在丢弃业务数据。

晚高峰为什么更容易出现波动

晚高峰意味着共享资源的需求增加，可能涉及家庭接入、无线信道、公共互联、代理入口或目标服务。只要某一处到达容量边界，后续流量就会排队或被丢弃。此时线路名称、出口地区甚至协议都可能没有变化，但可用容量和排队状态已经不同。单次非高峰测试不能代表高峰表现。

判断拥塞应观察时间相关性和影响范围。若本地常用服务也变慢，先检查接入与家庭网络；若仅代理流量异常，继续比较不同入口和路径；若只有某个内容平台缓慢，应核对目标服务状态与出口兼容。改变地区后恢复，只能说明新路径或新出口绕开了当前问题，不能立即判定原协议存在缺陷。

排队造成的慢，可能被下载任务放大

当上行或下行被持续占满，路由器和网络设备中的缓冲区可能积累数据。下载看似仍然很快，网页点击和语音却开始拖延，这通常是排队问题的重要信号。协议若采用积极的发送策略，也可能让瓶颈前的队列更长。遇到这种情况，应暂停大流量任务观察交互能否恢复，再评估发送设置，而不是继续增加并发。

家庭共享场景尤其要注意上行同步。云端备份、照片上传或文件共享可能在后台持续占用接入容量，影响同一网络中的其他设备。VPNFine 不限设备台数，但共享网络的容量仍然有限。设备数与带宽是不同维度，关于多人使用的口径，可参考家庭共享与设备数说明，不要把多设备支持理解为每台设备都有独立接入资源。

一套可复现的排查顺序

先保留故障发生时的客户端状态，注明接入方式、目标应用、节点与代理模式。随后验证不经代理的日常网络是否正常，再确认订阅与账户状态。若本地网络正常，使用相同目标切换到另一条已知可用的路径；若仍失败，查看客户端日志是解析、握手、认证还是目标连接报错。日志中的阶段通常比笼统的超时提示更有价值。

对于疑似 UDP 路径问题，可比较有效的 TCP 配置；对于疑似入口拥塞，比较不同入口而不只是更改出口名称；对于仅某个应用失败，检查该应用代理支持与规则。测试完成后恢复非必要修改，避免留下全局 DNS 或系统代理残留。需要提交工单时，通过用户面板工单入口描述复现过程，不公开订阅地址、认证信息或包含个人数据的完整日志。

如果问题只在休眠后发生，优先回看移动端与系统恢复章节；如果始终是首次请求慢，则回看解析与连接建立；如果传输开始后逐渐拖慢交互，则回看排队与共享带宽。把现象对应到明确分支，可以减少没有依据的切换，也能让支持人员更快理解问题范围，而不是依赖无法复现的主观评价。

场景选型：把协议放回实际使用

网页与办公：先保证规则和出口一致

网页浏览和日常办公优先考虑可靠建立连接、正确分流与目标兼容。浏览器成功并不代表会议软件、邮件客户端或桌面编辑器已经使用代理。先确认应用接入方式，再比较节点；没有经过代理的应用，无法通过更换远端协议得到改善。办公环境若有组织提供的网络要求，应以其安全与访问规定为前提，不随意替换既有配置。

涉及登录和长时间工作的服务，稳定出口往往比频繁追逐瞬时速度更重要。频繁切换地区可能触发目标服务的额外验证，也可能使已有会话失效。找到表现合适的出口后，保留可工作的配置，并准备另一条兼容路径用于故障对照。备选的意义是恢复与诊断，不是让客户端持续轮换出口。

AI 工具：区分连接、流式响应与服务资格

ChatGPT、Claude、Gemini 及编辑器中的 AI 功能，可能涉及网页、接口与流式连接。页面能加载，不代表生成过程可以持续完成；生成中断，也可能是应用超时、目标服务状态或账户权限问题。应先观察是登录失败、请求无法发出，还是响应开始后中断，再选择相应的排查分支，避免把所有报错归结为线路速度。

对于 Cursor 等桌面工具，还要确认应用是否读取系统代理，以及接口请求是否匹配正确规则。出口位置需要符合目标平台的地区与账户要求，代理连接不会改变这些规则。适合该场景的配置，应同时满足应用兼容和连接持续性；进一步的场景说明可读AI 加速专题，不要仅凭协议标签判断服务可用性。

流媒体与实时应用：关注点并不相同

流媒体更看重持续传输和出口地区，但内容目录、清晰度与播放权限还受平台账户、版权地区和设备能力影响。协议成功建立连接，不能证明平台接受这个出口。先核对账号与内容地区，再观察播放是否稳定；画面卡顿若来自设备解码或本地无线网络，换成专线也未必改善。具体地区访问应结合流媒体专题与实际线路资料确认。

语音、会议和实时交互则更在意抖动、丢包与双向通信。平均延迟看起来合适，仍可能因偶发排队影响对话；持续下载优秀，也不意味着语音数据报转发正常。应在实际应用中测试接收与发送，确认所用配置支持需要的流量类型。若网络不适合 UDP，应优先寻找应用支持的兼容方式，而不是强行套用不匹配的参数。

订阅选型与协议选型分别决策

协议选择回答“怎样连接”，套餐选择回答“需要多少流量、如何计费”。VPNFine 月订阅为 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB，流量按开通日每月重置，中途升级差价折算成剩余天数。月订阅适合按持续使用需求评估，不应仅因某协议的宣传而选择更大的流量档位。

流量包为 ¥158/300GB、¥358/1000GB、¥658/3000GB，用完为止，永久不过期。服务支持支付宝 / 微信 / USDT，提供 30 天无理由退款；账户无需邮箱地址，用户名与密码即可创建。完整计费说明请查套餐页，长期使用的判断方法可读长期订阅与按月付费的取舍，技术名词不能代替计费规则。

最后保留一份自己的判断依据

选定配置后，记录设备平台、接入网络、客户端模式、协议与线路类型，以及验证过的应用。Windows / macOS / iOS / Android / Linux 的后台与路由行为不同，不需要追求配置完全相同。发生变化时先复现，再按照本页从应用、解析、连接到路径的顺序检查。可靠的选择不是某个永远第一的协议，而是知道当前组合为何适合，以及故障时如何恢复。