Shadowrocket 协议参考

协议选型的四个层次

先分清协议、传输、加密和路由

在 Shadowrocket 中选择协议，实际是在确定客户端如何与已有服务器通信，而不是给连接挑一个速度等级。完整连接至少涉及四个层次：协议规定请求和认证的格式，传输负责把数据送到另一端，加密保护链路中的数据，路由决定哪些请求进入这条链路。四者有关联，但不能互相替代。选中正确的协议类型后，服务器地址、端口、凭据和传输参数仍须逐项一致；只凭名称相同，并不能证明两端可以通信。

例如，VLESS 是一种请求与认证格式，WebSocket 是一种承载方式，TLS 负责相应连接的加密和身份验证，而 DOMAIN-SUFFIX 决定一个域名是否使用代理策略。同一协议可以搭配不同传输；同一传输也可能承载不同协议。服务端给出的整组参数才是配置单位，不能把一个配置的认证信息与另一个配置的传输方式拼在一起。导入后看到不同名称时，应先检查这些名称分别描述哪个层次。

明确正在比较的使用目标

网页浏览往往由许多短请求组成，首次建立连接的时间、域名解析和连接复用会影响体感。大文件传输更容易暴露持续吞吐、拥塞控制和服务器出口限制。语音、互动应用则更在意往返时间波动、丢包与 UDP 可用性。因此，“打开网页快”和“持续传输快”是两项不同结论；把一次下载结果推广到所有应用，容易选错后续排查方向。先写明目标，再选择能够反映该目标的测试。

在 iPhone 和 iPad 上，还应把使用时段与网络条件一起记录。静止使用的 Wi-Fi 与移动中的蜂窝网络，可能面对不同的地址变化、无线重传和后台调度。协议增加的封装、加密与保活会产生开销，但屏幕亮度、无线信号强度和持续传输量也会显著影响电量。没有控制这些因素的比较，只能说明某次使用经历，不能形成固定的协议耗电排名，更不能据此认定名称较新的协议一定更省电。

建立可以回退的选择顺序

实际选型首先受已有服务器能力约束。只有一组完整配置时，按资料选择对应类型，不必为了比较而改写协议。已有多个可用配置时，先确认每个配置独立连接成功，再比较同一目标的首次访问、重复访问和持续使用。保留原配置副本，每轮只改变一个变量，并记下当时使用的网络。这样即使某次调整没有改善，也能回到已知状态，而不是在连续修改后失去参考基线。

最后再考虑维护成本：参数较多的连接需要保存更完整的资料，证书、域名和传输路径也可能有各自的变更周期。一个暂时快一些、但缺少明确参数来源的配置，未必适合长期使用。优先选择信息齐全、符合当前用途且便于验证的已有配置。协议参考的作用是解释差异和边界，不是替代服务端配置，也不把某种协议描述为对所有网络都成立的唯一答案。

Shadowsocks、HTTP 与 SOCKS5

Shadowsocks：简洁的加密代理

Shadowsocks 的设计重点是以较简洁的协议承载代理流量，通过约定的加密方法和密钥材料处理两端通信。它通常不需要像复杂传输组合那样同时填写多层路径参数，但这不代表所有配置都可以互换。不同加密方法对应不同的密钥要求和报文处理方式，服务端支持范围也可能不同。选型时应先确认已有资料中的方法与客户端可选项相符，再核对服务器、端口和认证材料。

密码与加密方法必须成组理解。有些配置使用普通密码文本，有些方法对密钥编码及长度有明确要求；把编码后的材料当成普通密码，或者仅凭“看起来更强”更换加密方法，都可能让认证直接失败。使用订阅导入时优先保留导入值；手动添加时逐项照资料填写，不自行补充未提供的扩展。若配置涉及额外承载方式，应继续核对其独立参数，不能假定服务器默认接受。

从 iOS 使用体验看，较少的封装层有利于降低额外处理，但真实速度仍受到服务器资源、链路质量与目标站点限制。现代设备的加密性能通常不是唯一瓶颈，不能把某个算法名称直接等同于耗电等级。若只在持续传输时发热，应先比较相近传输量下的表现；若空闲时也明显耗电，则检查重连、网络信号与保活，而不是立即更换加密方法。协议参数错误通常不会靠更长等待自行恢复。

HTTP：区分代理连接与目标连接

HTTP 代理最初围绕网页请求转发形成，既可以转发普通 HTTP 请求，也可以通过 CONNECT 为相应目标建立隧道。这里要区分两段连接：设备到代理服务器，以及代理服务器到目标站点。目标网站使用 HTTPS，并不自动说明设备到 HTTP 代理这一段也采用 TLS。若服务端明确提供加密的代理入口，还须按其资料配置对应连接方式，不能仅凭目标地址以 HTTPS 开头判断整段链路的性质。

HTTP 代理常见字段包括地址、端口以及可选的用户名和密码。认证方式与服务端配置有关，空白凭据和错误凭据也可能得到不同结果。CONNECT 是否允许某个目标端口，取决于服务端策略；能访问普通网页而无法连接某项业务，未必是客户端协议实现故障。排查时先使用已知允许的目标，再核对该业务实际使用的端口和传输类型，避免把权限限制误认为速度不够。

SOCKS5：通用转发不等于自带加密

SOCKS5 面向较通用的连接转发，定义了认证协商、连接请求和 UDP 关联等机制。协议本身并不提供通用的链路加密保证；用户名和密码的存在，也不等于数据已经通过加密通道传输。它适合与已有受信网络环境或另行提供的安全承载配合使用。选择之前应明确服务端的访问范围和保护方式，不能将 SOCKS5 与带加密机制的协议仅按字段多少作简单等价比较。

SOCKS5 的 UDP 支持还需要两端实现、服务端允许以及中间网络可达同时成立。TCP 连接成功，不能证明 UDP 关联也正常；网页正常而实时业务失败时，应单独验证该业务路径。域名由哪一端解析，也会影响解析结果和访问行为，不能只看服务器地址一栏。维护已有配置时，保留认证、解析与 UDP 相关设置的原始信息，再按实际需求逐项验证，比随机切换开关更容易找到问题。

VMess 与 VLESS 的设计取舍

VMess：把认证与协议处理一起核对

VMess 的设计包含用户认证与协议层的数据处理机制，常用 UUID 标识用户信息。它经常与其他传输方式组合，因此一条配置可能同时包含 UUID、协议安全选项、传输类型及外层 TLS 字段。看到 UUID 并不意味着整个连接已经配置完成：地址和端口决定连接到哪里，认证决定是否被服务端接受，而外层参数决定请求如何到达实际服务。任一层不一致，都可能表现为连接超时或被关闭。

手动核对时先检查 UUID 是否完整，尤其留意复制时混入的空格、换行和缺失字符。接着核对服务端要求的安全选项，最后才检查传输相关字段。不同历史配置可能包含额外参数，不能用一份资料的取值覆盖另一份；应以当前已有服务的明确说明为准。若认证阶段与时间有关，设备时间明显偏差也可能影响连接，先恢复准确时间，再继续判断凭据是否需要更新。

VLESS：精简协议不等于省去安全层

VLESS 侧重较精简的认证与请求封装，通常使用 UUID，但不以协议本身提供通用的数据加密层作为设计重点。实际部署需要结合所采用的安全与传输机制理解，不能把“字段少”解释成不必验证远端身份。UUID 是认证材料，不是替代证书校验的凭据；传输方式、TLS 设置以及服务端指定的其他参数，仍然属于完整连接的一部分，应一并保存。

某些已有配置还会指定特定的流处理选项。这类字段与服务端处理方式及可用传输有关，并不是提升速度的通用开关。资料没有提供时，不应根据网上另一组配置补填；资料明确要求但客户端当前可选项不匹配时，也不应换成名称相近的值。先确认应用能力和服务端条件，再决定是否使用该组配置，比反复尝试可能建立错误假设的组合更可靠。

WebSocket 与其他承载要成组匹配

WebSocket 常见的核对对象包括请求路径与 Host。路径可能参与服务端分流，大小写、前导斜杠及其他组成部分都可能有意义，不能随意删除。Host 用于相应请求的路由，不必然等于实际建立网络连接的地址，也不必然等于 TLS 的 Server Name。服务端通过不同层次区分请求时，这些值可以各有用途；把所有域名统一改成一个地址，反而可能破坏原本正确的组合。

如果采用其他传输方式，也应按照该方式的字段核对。例如涉及服务名称时，名称与路径不能仅因都属于文本就互相代用。外层连接已建立但请求仍失败，可能说明请求到达了入口，却没有被转交给正确的后端。此时应把传输参数和服务端分流条件放在一起看，而不是重新生成 UUID。更换认证材料无法修正一个写错的路径，反之亦然。

怎样比较在 iPhone 上的实际开销

VMess 与 VLESS 的体感差异不能脱离所搭配的传输和服务器讨论。TLS 握手、连接复用、额外封装与服务端负载，可能比两种协议格式本身更影响首次访问。若一个使用简单连接，另一个经过额外转发层，即使速度不同，也不能把差异全部归到协议名称。对比时应尽量保持地址所在网络、目标、传输条件与测试时间接近，并分别记录首次连接和后续请求。

长期使用还要观察网络切换后的恢复，而不是只记录刚连接时的结果。设备从 Wi-Fi 转到蜂窝网络后，原有连接可能需要重新建立，具体表现受传输机制和系统调度共同影响。若仅在切换时失败，先测试关闭再连接能否恢复，并记录是否所有业务都受影响。这个结果有助于区分连接存续问题与静态参数错误，避免把可以复现的网络条件误判成协议永久不可用。

Trojan 与 TLS 参数核对

Trojan 的外层安全连接

Trojan 把代理请求与认证放在 TLS 连接内部，设计上利用成熟的安全传输机制承载业务。对用户而言，密码、服务器地址与 TLS 身份核对是同时成立的条件，而不是三种可以择一使用的验证办法。即使密码正确，连接到不匹配的服务器名称、收到不被信任的证书或选择了错误端口，仍然不能形成正确连接。排错应沿外层连接到内层认证的顺序进行。

TLS 不只负责加密，还通过证书链和名称匹配帮助确认远端身份。握手阶段的失败发生在业务数据正常转发之前，因此“网页没打开”只是最终现象，不能据此判断密码错误。先确认网络可以到达入口，再核对证书相关条件；只有安全连接已经成立，才有必要继续检查内层认证与目标请求。这样的顺序能减少同时修改多个字段导致的重复劳动。

连接地址、Server Name 与 Host

服务器地址回答的是“向哪里建立网络连接”，Server Name 则用于 TLS 握手中的服务器名称指示及相应身份核对，具体字段名称以当前界面为准。已有配置可能使用一个网络地址连接，却使用另一个明确提供的域名进行名称验证。这不是可以凭外观纠正的差异。若把 Server Name 改成连接地址，证书可能不再匹配；若只改地址而未核对服务端入口，也可能连接到完全不同的服务。

Host 属于相应应用层请求时，承担的任务与 Server Name 不同。只有实际使用包含该字段的传输方式时，才需要按资料填写，不能为没有该字段的连接自行增加含义。遇到同时给出多个域名的配置，应把每个值与所属层次对应记录。最容易排查的资料不是只保存一个“服务器域名”，而是明确写清连接地址、TLS 名称和请求路由各使用什么，以及哪些字段保持默认。

证书错误不要用跳过验证处理

证书问题通常可以沿三条线索核对：设备时间是否准确，配置名称是否与证书覆盖范围相符，服务端是否提供完整且受信任的证书链。证书过期、链不完整和名称不符不是同一种故障，处理方式也不同。客户端仅能检查本地参数与时间，服务端证书部署问题则需要由已有服务的管理方处理。反复更改密码不会修复证书链，也不能代替对错误原因的确认。

跳过证书验证会改变身份确认条件，不应作为日常排错的默认步骤。若连接在关闭验证后才成立，这只能说明原先的身份验证环节存在问题，不能证明该服务器已经可信。应保留原始配置并查明具体不匹配之处，再恢复正常验证。对需要额外信任材料的已有服务，也应先确认材料来源和适用范围，不把从其他连接复制来的证书设置随意应用到当前配置。

TLS 开销与长期连接

TLS 的连接建立涉及额外往返和计算，但后续请求可能复用连接，实际影响取决于应用行为和网络条件。频繁断开重连的小流量场景，与持续保持连接的大流量场景，不能直接用一次首次打开时间比较。弱信号下的重试还可能放大握手成本，使电量变化看起来像协议固定属性。测试时应区分首次连接、连续访问与空闲恢复，观察差异出现在哪一个阶段。

Trojan 配置中的 UDP 能力也不能只凭外层 TLS 正常就认定可用，应结合服务端支持和实际业务检查。若网页正常但某项实时业务异常，可先核对路由，再单独验证 UDP 路径。有关证书、域名和传输的排查方法也适用于其他采用 TLS 的协议，但不能因此把不同协议的密码或请求格式互换。公共层次可以共用判断思路，内层协议仍须保持自身的参数一致性。

WireGuard 的密钥与路由

它与请求代理的比较边界

WireGuard 以 IP 层隧道为设计对象，使用公钥机制识别对端，通过 UDP 承载加密数据。它与按目标请求建立代理连接的协议，观察和配置的层次并不完全相同。放进 Shadowrocket 的使用场景后，还要同时考虑客户端如何把流量交给该连接，以及远端如何转发收到的数据。隧道能够建立，并不意味着目标路由、名称解析和返回路径都已经正确，必须继续验证实际业务。

其设计取舍包含较明确的密码学组合与相对精简的协议状态，减少了让用户自行拼装算法组合的空间。但精简不等于所有字段都可以留空：本地地址、密钥、远端入口和允许的地址范围仍承担不同任务。服务端需要认识当前客户端的公钥，并为其安排相符的网络条件。把一套配置中的私钥换掉，却不更新远端对应信息，通常会使原本的身份关系失效。

Private Key、Public Key 与 Endpoint

Private Key 属于本地身份秘密，应只在受信的配置存储中使用；Public Key 用于对端识别，不承担相同的保密职责。填写远端 Public Key 时，应使用资料中明确标注的对端公钥，而不是把本地公钥再复制一次。有些配置还包含预共享密钥，它是额外的安全材料，不是任意文本备注。不能因为名称里都出现 Key，就认为这些字段可以交换或通过删除其中一项简化配置。

Endpoint 描述远端入口地址与端口，并不等同于隧道内部使用的本地地址。前者用于在当前网络中找到服务器，后者用于隧道内的数据通信。地址前缀长度也有明确的网络含义，不能把它看成装饰字符去掉。若导入后提示字段不完整，应回到原始资料确认，而不是用设备当前 Wi-Fi 地址代替。物理网络地址与隧道地址属于不同层次，混用会使排错更加困难。

Allowed IPs、DNS 与 MTU

Allowed IPs 在 WireGuard 语义中与对端可接收的目标范围及接收来源校验有关。客户端具体暴露哪些选项、如何与自身路由结合，应以当前界面与已有配置为准。它不应被当作 Shadowrocket 规则列表的另一种写法随意改动。只允许某个内部网段的隧道，不会因选中了它就自然具备完整互联网访问能力；还要看远端转发、出口和返回路由是否支持相应目标。

DNS 决定名称如何得到地址，隧道路由决定得到地址后如何到达，两者需要分别核对。能访问已知地址而域名失败时，可先检查解析路径；域名能解析却不能连接，则继续看目标范围和远端转发。MTU 影响封装后数据包的大小，过大时可能出现小请求正常、大响应停滞的现象。但不能因此随意填入某个通用数字，应先保留原值，确认症状后再按服务端建议做单变量测试。

移动网络中的保活与恢复

持续保活用于在特定环境下维持网络映射，不是越频繁越好。它可能帮助某些需要空闲后仍接收入站数据的场景，也会增加周期性通信和无线唤醒。是否需要、如何设置，应结合服务端角色、网络映射超时和实际业务需求，而不是为了让界面看起来持续活动。若只是主动发起普通访问，不能把缩短保活间隔当作提升所有业务速度的通用技巧。

WireGuard 的对端识别机制允许在相应条件下处理入口地址变化，但设备切换网络后的恢复仍受系统、服务端和当前 UDP 可达性影响，不能承诺全程不断开。测试应包含空闲后首次访问与网络切换后的实际请求，并确认目标确实经过该隧道。分享诊断记录时隐藏 Private Key、预共享密钥和内部网络细节，只保留必要的现象、字段名称与错误类别，避免用完整配置换取排错便利。

Hysteria2 的网络适用条件

从丢包与拥塞问题理解设计

Hysteria2 基于 QUIC 构建代理通信，QUIC 运行在 UDP 之上，并结合安全握手、流管理与拥塞控制等机制。其设计关注点之一，是在不同质量的网络路径上调整传输行为。这个方向不等于消除物理链路的限制：无线信号差、服务器出口不足或中间网络不允许相应 UDP 流量时，仍然会出现失败或吞吐下降。先确认承载条件成立，才有意义继续讨论它在当前网络中的表现。

QUIC 的多流机制可以减少不同流之间因传输层顺序交付产生的某些相互阻塞，但链路带宽、拥塞和共享服务器资源仍然是共同约束。不能把它理解成任意请求都不再等待，也不能据此保证游戏或语音延迟降低。互动业务对排队与丢包敏感，而持续传输更关心稳定吞吐；同一组设置可能改善其中一项，却没有改善另一项，测试时必须分别记录。

认证、名称与混淆参数

配置时先核对服务器地址、端口与认证信息，再核对 TLS 名称与证书验证。认证文本需要完整保留，不能因其看起来像备注而截短。与其他采用 TLS 的连接一样，实际连接地址与用于身份验证的名称可以承担不同任务，应按已有资料填写。若客户端尚未成功完成安全连接，先检查外层可达性与名称匹配，而不是直接判断认证材料已经失效。

某些服务会提供额外的混淆设置，只有服务端明确采用相同机制与参数时才应启用。它不代替身份验证，也不是单独提升速度的开关。客户端与服务端一边开启、一边关闭，或密码不一致，都可能导致数据在进入正常协议处理前就无法被识别。导入后应保留整组值；手工修改前保存副本，不从另一条配置复制看似相似的选项来补齐当前资料。

带宽参数是条件，不是速度承诺

已有配置若包含上行与下行带宽字段，应先分清方向和单位，并理解它们可能影响拥塞控制行为。把数值设得远高于当前链路能力，并不会增加可用带宽，反而可能造成排队、丢包或与其他业务争用。移动网络可用能力会随位置和时段变化，因此一个固定估计值并不总能适用。先保留服务端建议或客户端合理默认，再用持续测试判断是否存在调整需要。

当网页首开正常而大流量传输波动明显时，可以比较不同网络下的结果，同时观察其他业务是否也受影响。若开始传输后语音卡顿，可能是链路排队或资源竞争，不一定是认证或 TLS 配置问题。减少测试并发、暂时停止其他大流量任务，再复测同一目标，能够判断当前现象是否主要来自负载。不要用反复提高带宽字段的办法掩盖一个尚未确认的瓶颈。

UDP 可达性与电量边界

某个网络允许网页访问，并不能证明它也允许连接到所需 UDP 端口。Hysteria2 在一个网络可用、换到另一个网络失败时，应优先保留配置，检查差异是否发生在底层可达性。反复改密码可能破坏原本正确的配置，却无法解决承载被限制的问题。若已有其他完整可用配置，可以在同一网络交叉验证，但结论应限定为该网络条件，不推广为所有场景的协议优劣。

在 iPhone 上，较高吞吐意味着短时间内可能处理更多数据，也可能带来更明显的无线和处理器负载。持续运行时间、总传输量与空闲重连行为，都会影响电量结果，不能仅用屏幕上的瞬时速度作判断。网络切换后也应重新验证业务是否恢复，而不是只看连接开关。遇到频繁失败时先降低测试强度、记录现象并回到已知配置，再逐项定位承载、参数或服务端条件。

参数核对与规则分流

导入成功不等于服务验证成功

通过 Subscribe 导入已有订阅，首先证明客户端能够读取并解析相应资料，不等于其中每条连接都已通过认证或具备相同能力。导入后应查看一条目标配置的类型、地址、端口及必要的传输字段，确认与资料描述一致。名称只是便于识别的标签，不能作为协议类型的判断依据。若标签写着某种协议，而实际类型不同，应核对原始资料，不按标签手动猜改。

二维码与分享文本同样属于配置载体，编码、转义和字段映射会影响解析结果。复制时缺少字符、把说明文字一起选中，或者读取了不完整内容，都可能产生异常。先检查原始资料是否完整，再决定手动补填。订阅更新还可能覆盖本地改动，因此测试调整前应保留独立副本并记录来源，避免把一次临时修正误认为后续更新仍会长期保留。

Global Routing 决定规则是否参与

Global Routing 的 Config、Proxy、Direct 分别对应按配置处理、以代理方式处理及直连方式处理的整体姿态。日常按网站分流时，应先确认使用 Config，再检查当前启用的配置文件。Proxy 适合在已理解影响范围的情况下辅助验证代理路径，但不能代替完整的规则核对；Direct 则不能拿来证明代理协议已经正常工作。姿态、当前服务器和当前配置是三项不同状态，都应记录。

规则通常自上而下检查，前面命中的条目可能使后面的精确规则没有机会执行。DOMAIN 匹配完整域名，DOMAIN-SUFFIX 匹配相应域名及子域名，DOMAIN-KEYWORD 按域名关键词匹配；IP-CIDR 面向地址范围，GEOIP 按相应地址地理分类处理，FINAL 为前面的规则未命中时提供兜底。匹配对象不同，不能因都能写域名或地址就互相替换，解析条件也会影响部分地址类判断。

[Rule]
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,DIRECT

这段片段展示的是规则顺序，不包含服务器信息，也不是可直接建立连接的完整配置。精确的 REJECT 放在较宽的 DOMAIN-SUFFIX 前，避免先被后者命中；PROXY 需要结合当前可用的代理连接理解；FINAL,DIRECT 表示其他未命中的请求直连。示例域名仅用于解释语法。已有配置若使用自定义策略名称，应检查对应定义，不能把陌生名称一律替换为 PROXY。

用实际连接记录闭合判断

一项业务可能同时访问页面、静态资源、认证与实时通信等多个域名。主页面打开不代表全部请求都命中同一策略，反过来某个组件失败也不能直接说明协议整体失效。验证时查看实际连接所使用的目标与策略，区分规则未命中、连接未建立和目标返回错误。不要为了修复一项资源就把所有规则都删掉，那会失去原配置的用途，也难以判断真正起作用的改动。

需要进一步理解匹配对象，可查阅规则关键字说明；只让指定网站使用代理的思路见指定网站分流配置方法。涉及 REJECT 时，还应阅读REJECT 的适用边界。协议决定连接如何建立，规则决定何时使用它；先把两者分别验证，再组合使用，排错记录才有明确含义。

速度、电量与故障定位

先建立同条件测试记录

比较已有配置时，固定设备、网络、目标和 Global Routing，暂停其他明显的大流量任务，并尽量在相近时段进行。每轮记录首次连接、重复访问和持续传输，不把三类结果混在一起。Connectivity Test 可以辅助观察可达性，但测试目标、连接方式与真实业务未必一致，单个结果不能替代业务验证。测试完成后恢复原有路由姿态，避免临时验证设置继续影响日常连接。

电量比较应关注相近使用时间和相近总传输量，并控制屏幕、信号与后台活动。系统电量页面反映的是应用活动与系统统计口径下的结果，不是独立测出的协议能耗。一次短测试尤其容易受启动、缓存和无线状态影响。若设备持续发热，应先停止高负载测试，检查是否有大量传输或反复重连；在原因未明时继续增加并发，只会使比较条件更加不稳定。

按失败阶段分支，而不是随机换参数

完全无法建立连接时，先确认当前网络正常、入口地址和端口正确，再核对协议类型。采用 UDP 承载的连接，须另外确认该路径可达；采用 TLS 的连接，继续核对名称、设备时间与证书条件。外层已经成立但认证被拒绝时，再检查密码、UUID 或密钥。每次只修改一项并保留原值，若没有改善立即回退，避免把原本正确的字段也变成新问题。

连接显示正常但业务失败时，应先检查实际流量是否进入预期策略，然后区分解析、目标连接与业务响应。已知地址可达而域名失败，提示优先看 DNS；只有某个目标失败，提示检查目标本身或服务端访问条件；只有大响应卡住，则可以继续观察 MTU、丢包与链路质量。它们都是排查线索而非单凭现象就能下的结论，需要下一步验证来排除其他可能。

网络切换或空闲后才失败时，记录发生条件、等待时间和重新连接后的变化。若手动重连恢复，说明静态参数至少曾经可用，应重点观察连接恢复、网络映射与服务端会话处理，而不是立即重填全部凭据。On Demand 会依据设置影响连接行为，也应纳入记录，但它不会修复错误的认证或缺失的远端能力。先在手动连接下得到可重复结果，再调整按需连接条件。

按场景缩小选择范围

普通网页查阅可优先考虑已有配置中稳定、参数清晰且首开与重复访问表现一致的一组；需要实时通信时，先验证 UDP 和时延波动；访问受控内部网段时，关注路由范围、地址冲突与 DNS；持续大流量任务则关注吞吐稳定性及对其他业务的影响。这里的建议是测试顺序，不是协议排名。只有服务端实际支持的能力，才有资格进入对应场景的比较。

维护记录应包含协议类型、外层传输、使用网络、Global Routing、失败目标类别与可复现步骤。分享给已有服务的管理方之前，隐藏订阅地址、认证材料、私钥及其他敏感值；截图也只保留排查所需区域。首次连接涉及系统权限时，参考添加 VPN 配置提示说明。常用字段含义可回查术语表，完整操作顺序则回到快速上手教程。