Shadowrocket
协议与参数参考

协议分层：先区分连接的四个问题

协议、传输、安全与路由不是同一层

在 Add Server 中选择协议类型，回答的是客户端用什么格式向服务器表达目标地址、认证身份并交换数据。传输方式回答这些数据怎样承载，例如使用 TCP 字节流、WebSocket 或基于 UDP 的机制。安全层回答通信如何加密、怎样确认远端身份；路由层则回答某个请求是否交给这条连接。把四个问题混在一起，会出现更换协议却没有修复错误域名、修改规则却没有解决认证失败的情况。

连接资料至少要能够说明服务器地址、端口和认证方式。某些组合还需要传输路径、TLS 的服务器名称以及其他协商参数。服务器地址是实际拨号的目的地，目标网站地址是用户希望访问的资源，两者不是同一个概念。端口也只是入口编号，不能仅凭常见端口推断一定启用 TLS。导入后应先检查类型是否正确，再检查附加选项；不要因为几个字段看起来相似，就把一组资料移到另一种协议下面。

速度需要拆成握手、吞吐与稳定性

打开短网页时，域名解析、建立连接和安全握手可能比正文传输更耗时；连续传输大文件时，拥塞控制、服务器出口和远端站点能力更重要；语音或交互任务则更在意抖动、丢包和连接恢复。一次延迟测试只能覆盖其中一部分。测试数值更低，并不必然意味着下载更快；带宽更高，也不保证弱信号下的交互更稳定。比较时必须固定目标、接入网络和大致时段，否则测到的变化很可能与协议无关。

iOS 上的电量取舍不能只看加密名称

电量消耗来自处理器计算、无线收发、后台唤醒和失败后的重复尝试。现代加密算法的成本只是其中一项，弱信号下的重传、持续探测和频繁重建连接往往更值得检查。比较电量时，应尽量保持屏幕亮度、使用内容和网络信号一致，并给系统足够的观察时间。不能把某次电量下降直接归因于协议，也不能认为增加保活就一定更稳定；保活可能减少重建，却同时增加空闲时的通信。

实际选型的第一步不是列出速度排名，而是确认服务器能够提供什么、当前网络允许什么，以及你主要使用什么任务。已有资料只支持一种类型时，正确导入和可靠验证比寻找另一种名称更重要。需要比较多种已有配置时，先保留原始记录，逐次只改变一个变量，并记录失败发生在解析、连接、认证还是目标访问阶段。这样得到的结论才可以在下一次网络变化后复用。

协议类型是双方约定，不是客户端的单方面偏好。服务器没有对应入口时，在 Shadowrocket 中切换类型不会让两者自动兼容。

Shadowsocks：共享密钥与较精简的承载

设计背景与需要匹配的字段

Shadowsocks 的基本思路是以预共享凭据建立加密代理通道，把目标地址与后续数据交给服务器转发。它不以网页会话或完整的网络接口为核心模型，基础参数相对集中，因此常见资料会围绕地址、端口、密码和加密方法展开。字段少并不意味着可以省略核对：双方使用不同加密方法、不同凭据，或服务端入口本身不是该协议，都会在建立有效通信之前失败。

加密方法必须按服务器资料原样填写。不同方法涉及不同的密钥派生、数据格式和认证方式，名称近似也不表示互通。采用认证加密的配置会同时校验数据完整性，错误密钥可能表现为连接后很快断开，而不是出现一个清晰的密码提示。不要把所有认证错误都理解成线路不稳定。部分较新的协议变体对密钥格式有专门要求，此时不能把普通口令的填写经验直接套用，应该以该条资料的字段定义为准。

基础协议与附加传输要分开核对

若已有资料还包含插件或其他外层承载信息，需要确认 Shadowrocket 中对应选项与服务器实际配置一致。基础协议、外层传输和入口端口共同构成连接条件，缺少任何一层都可能导致超时。尤其是迁移旧记录时，不应只复制地址和密码而忽略附加说明。反过来，没有提供附加传输的记录，也不应为了“更完整”随意打开额外功能；客户端发送的格式一旦改变，服务器就可能无法识别。

TCP 与 UDP 的可用性也要分别验证。网页能够打开，只说明相应请求的路径可以工作，不代表依赖 UDP 的任务同样可用。服务器是否接受 UDP、接入网络是否允许相关流量、当前配置是否承载了该请求，都可能影响结果。发现某一类任务失败时，应先确认任务所用的传输方式，再检查对应链路，而不是立刻替换密码。对不同协议都采用同一套目标测试，才能避免把目标站点自身的差异算到协议上。

速度、电量与故障定位

在网络质量较好、服务器负载适当的情况下，较精简的封装有利于减少额外处理，但实际速度仍由路径容量和服务端性能共同决定。某个加密方法在一台设备上的表现，不能直接代表另一台设备；硬件加速、实现方式与任务大小都会影响结果。对于移动使用，更有意义的观察是连续浏览是否顺畅、切换网络后是否能恢复，以及空闲时是否发生重复重连，而不是只比较一次启动所需的时间。

排查时先核对地址和端口能否到达，再核对加密方法与凭据，最后处理附加传输。若所有目标都失败，优先检查共同入口；若只有某个站点失败，则检查规则命中、域名解析和远端响应。某些失败不会返回易懂的认证信息，因此“没有提示密码错误”并不能证明凭据正确。可以重新从原始记录导入一份用于对照，但应避免同时保留大量同名条目，以免实际选中的并不是刚修改的那一项。

这一类型适合已有服务器提供相应入口、希望参数结构相对直接的场景。它不是 TLS 证书配置的替代说法，也不意味着所有安全行为都与 TLS 相同。需要判断远端身份和管理凭据时，应理解该协议依赖的信任来源；拿到资料后，使用者仍要保护其中的密码和密钥。向他人描述故障时，可以提供类型、报错阶段及经过隐藏的字段结构，不应公开完整认证信息。

先核对加密方法，再核对密码。随意更换加密名称通常不是兼容性修复，反而会使原本正确的资料无法使用。

VMess：身份认证与外层传输分别检查

理解协议承担的任务

VMess 把用户身份认证、目标表达和数据保护组织在自己的协议结构中，并可以与不同外层传输组合使用。它的出现体现了一种设计取舍：不把所有功能都交给外层，而是在协议内部保留会话和认证机制。对客户端使用者而言，这意味着需要同时理解协议参数与承载参数。仅看到一个 UUID，并不足以重建完整连接；缺少传输类型或安全设置时，即使用户身份正确，也可能完全无法通信。

UUID 是身份字段，不是服务器地址，也不是 TLS 证书里的名称。复制时应保留完整格式，避免混入空格或不可见字符。部分历史资料可能出现与旧认证机制有关的字段，这类字段不能仅凭经验补成某个数值，应核对服务器当前要求。导入链接通常比手工拼接更能保留字段，但导入成功只表示客户端读懂了数据结构，并不代表远端认证、证书和传输路径已经验证通过。

WebSocket、Host 与路径的不同角色

使用 WebSocket 时，连接需要经过相应的升级过程，路径和请求中的主机信息可能参与服务器的入口选择。这里的路径是服务端约定的入口，不是随意填写的网站目录。路径大小写、前导斜杠或附带查询内容的差异，都可能让请求落到不处理该协议的位置。服务器返回普通网页或错误页面时，底层连接看似建立了，实际的代理会话却没有形成，因此不能把“地址能够打开”当作配置正确的证据。

当 WebSocket 与 TLS 同时使用时，还要区分拨号地址、TLS 服务器名称以及 HTTP 层的 Host。三者有时相同，有时由部署方式决定而不同。客户端首先连接某个地址，随后在安全握手中确认名称，再通过应用层请求进入指定服务。任何一层不匹配都可能失败。不要把服务器管理记录中的某个域名同时复制到所有字段；应明确每个字段的作用，再按原始资料填写。

时间与认证错误的边界

VMess 的认证过程涉及时间相关校验，因此设备时间明显偏离实际时间可能造成连接问题。排查时可检查系统日期与时间设置，但不应把所有失败都解释成时钟错误。TLS 证书有效期也受时间影响，两者属于不同的验证环节：认证失败与证书失败可能有相似的外部表现，却需要不同的修复动作。先读取能够获得的错误信息，再判断应检查设备时间、用户身份还是服务器证书。

在性能方面，额外承载通常增加一定的握手或封装成本，但并不存在所有网络都一致的损耗比例。长时间传输时，这些成本可能被摊薄；频繁打开短连接时，建立会话的开销更容易被感知。移动端还需要观察网络从 Wi-Fi 切换到蜂窝数据后的恢复行为。旧会话失败后是否及时重建、服务端是否仍保留状态，会影响体感，不能仅用静态延迟数字判断一整天的使用体验。

建议按“身份字段、传输方式、入口信息、安全参数”的顺序做核对记录。若同一服务器的其他已有条目可用，应先比较字段差异，而不是整组重填。若只有启用某种外层承载的条目失败，则重点检查入口路径及其服务端映射。更换网络后恢复也只是提供了定位线索，不能直接证明原网络屏蔽了某个协议；解析结果、地址族、入口可达性都可能随接入网络改变。

VMess 的 UUID、WebSocket 路径和 TLS 服务器名称各司其职。一个字段正确，不能抵消其他层级的错误。

VLESS：轻量协议与安全层的组合边界

减少协议负担，不等于省略安全核对

VLESS 的设计将身份与目标传递保持得较为精简，不在基础协议中承担通用的数据加密职责，因此通常需要结合合适的安全层使用。这里的“轻量”描述协议分工，不是速度保证，也不是可以忽略服务器验证的理由。理解它时，应该同时问两件事：用户身份如何被远端接受，以及传输中的数据由哪一层保护。只看到 VLESS 名称就判断连接的安全属性，信息是不完整的。

已有资料中的 UUID、地址、端口依然需要准确匹配，此外还要核对传输类型、安全方式和相关附加字段。不要把 UUID 当作 TLS 的替代物：身份认证证明请求是否具备服务端认可的凭据，而安全握手涉及会话保护和远端身份，两者不是同一过程。错误身份可能在安全连接建立后才被拒绝；错误的服务器名称则可能更早失败。按阶段区分，能减少没有方向的反复修改。

TLS、REALITY 与 flow 参数

使用 TLS 的资料需要核对服务器名称与证书验证条件。若已有资料指定 REALITY，则必须确认客户端对应能力、服务端设置与所需公钥等参数一致；它不是给任意 TLS 入口增加的通用选项。不同安全方式所要求的字段不能互相填补。缺少关键信息时，应从用户自己的原始资料补全，不应在网上寻找一组看似能用的值，因为这些值与特定服务器配置存在对应关系。

某些组合还包含 flow 等限制具体数据处理方式的参数。这个字段不能理解成自动加速开关，也不应为了追求速度而随意添加。服务器是否支持、所选传输是否适用，以及客户端实际实现的条件，都影响组合能否工作。最稳妥的方式是保留导入资料中的原值，并在需要手填时逐项对照。对于无法识别的选项，应先确认应用内可用字段，而不是把它塞入含义相近的其他输入框。

对速度与电量应作条件化判断

协议本身少承担一些工作，不意味着整个连接链路必然更省电。实际使用仍包含安全握手、外层传输、拥塞控制和无线通信，长连接是否复用也会改变成本。对持续观看内容的任务，稳定吞吐可能比首次握手更重要；对间歇访问的任务，唤醒和连接建立可能更突出。比较两条资料时，如果服务器位置、带宽或安全组合不同，就不能把结果单独归因于 VLESS 与另一协议的差异。

出现“测试有结果但网站打不开”时，应检查测试目标与实际请求是否走了相同路径。某些测试只涉及入口可达或一个特定目标，而网站还需要解析域名、建立新的连接并获取多个资源。也要确认 Global Routing 是否为预期模式、所选配置是否使用刚核对的服务器。可以用一次受控访问配合连接记录定位，不应通过关闭所有验证来追求一个表面上成功的结果。

适用场景应从已有资料出发：服务器明确提供完整组合，客户端能够表达全部必要参数，而且你能完成远端身份核对时，才有讨论性能取舍的基础。若资料只有零散字段，先补齐说明比反复切换安全方式更有效。需要把订阅重新导入时，可参照订阅导入四种入口，但导入步骤本身不会补出服务器没有提供的信息。

Trojan、HTTP 与 SOCKS5：认证和加密分开理解

Trojan 依赖的 TLS 条件

Trojan 的常见设计以 TLS 连接承载代理协议，在安全通道内完成认证并传递目标信息。它选择利用成熟的安全层，而不是让每个字段都承担加密职责。对使用者而言，密码正确只是必要条件之一，服务器证书、名称与入口同样需要正确。若域名证书有效但实际连接落到另一个入口，仍然无法完成代理会话；若入口正确但证书验证失败，也不能把错误简单归为密码问题。

服务器名称用于安全握手和身份核对，与用户准备访问的网站名称无关。证书应覆盖需要验证的名称，设备时间应处在合理范围内。某些部署还会涉及应用层协议协商等选项，这些选项应按已有资料填写，不应随意添加。遇到证书报错时，先检查名称拼写、设备时间和服务器端证书链，再联系自己的服务器管理方确认；跳过验证会削弱身份检查，不能作为常规修复方案。

HTTP 代理不是自动带有 TLS 的连接

HTTP 代理通过相应的请求形式或 CONNECT 方法处理目标访问。它常见于已有代理网关的环境，优点是语义直接、部署资料容易识别，但“HTTP 代理”这个名称本身并不保证客户端到代理之间已经加密。若目标网站使用 HTTPS，网站内容可能受到端到端 TLS 保护，而代理仍可能看到目标及连接元信息。这与客户端先通过 TLS 连接到代理，是两个独立的安全边界。

配置时应明确代理入口是否要求安全连接、是否使用用户名和密码，以及是否允许所需的目标端口。部分网关只允许有限的访问方式，因此某个网页可用不能推出所有任务都兼容。认证失败、目标端口被拒绝和上游无法到达，也属于不同问题。出现失败时，保留错误阶段和状态信息比单纯重复测试更有效；不要把网站自身返回的登录或拒绝页面误当作客户端协议认证失败。

SOCKS5 的协商能力与安全边界

SOCKS5 提供目标地址与认证方式的协商，并定义了不同的请求能力，但基础协议不负责为整个链路提供加密。用户名和密码认证不能被等同于加密通道。若用户已有的网关要求在某种安全承载中使用，应遵循其完整条件；否则需要充分理解接入网络与远端入口之间的信任关系。选择类型时，应按服务端实际提供的接口，而不是把 HTTP 与 SOCKS5 当作可以互换的名称。

SOCKS5 的域名处理与 UDP 能力还取决于请求表达方式、客户端行为以及服务端实现。协议定义某种能力，并不代表当前入口一定开放该能力。尤其是在实时通信场景，应实际测试任务所用的流量，而不是仅凭网页浏览成功做结论。域名究竟在哪一侧解析，也不能单凭协议名判断，需要结合客户端 DNS 设置与请求路径核对；否则可能在排查远端连接时遗漏本地解析问题。

在速度与电量方面，应该比较实际承载而不只是名称。安全握手、连接复用和网关响应时间会影响短请求，持续流量则受入口容量与网络质量限制。若只是访问已有 HTTP 或 SOCKS5 网关，按其接口填写通常比额外套上不受支持的组合更可靠。对身份验证有明确要求的场景，先确认安全边界再讨论少一次握手的收益，不能用轻微的启动差异替代必要的身份检查。

WireGuard：从目标代理转向网络层隧道

设计模型决定参数含义

WireGuard 面向网络层隧道，通过公钥身份与加密数据报承载 IP 流量。它与只表达某个目标连接的代理协议有不同的模型，因此参数里会出现接口地址、对端公钥、端点和允许的地址范围。它采用较固定的密码学组合以减少协商复杂度，但简单的算法选择并不等于简单的网络配置。使用者仍需要理解地址如何分配、哪些目的地可以交给对端，以及返回流量怎样到达设备。

私钥用于证明本端身份，公钥用于识别对应一方；填写时不能颠倒。端点描述实际联系对端的地址和端口，接口地址则是隧道内部使用的地址，两者不应混淆。预共享密钥若被要求，也必须由双方一致配置。导入后不应在不同设备间随意复制整组身份与内部地址，因为服务端可能把它们映射到固定对端，重复使用可能带来会话竞争或返回路径异常。

AllowedIPs、路由与 MTU

AllowedIPs 参与对端的地址关联与流量选择，不能简单理解成一个网站白名单。在客户端集成环境中，它还需要与应用的路由策略共同理解：一层决定请求是否进入相应连接，另一层约束隧道中哪些地址与对端相关。填写过窄可能使需要访问的地址没有可用路径，填写过宽又可能偏离原本的访问范围。应该保留服务器资料的网络规划，不凭经验把所有地址范围扩成最大。

MTU 描述适合在相应接口上传输的包大小上限。外层封装会占用空间，如果底层路径无法顺利处理较大的包，可能出现小请求正常、大响应停住的现象。但这只是可能原因之一，不能一遇到页面加载不完整就立即调整 MTU。应先排除目标服务、DNS 和丢包问题，再在可重复的测试中做小幅调整，并记录原值；盲目改得过小也会增加分包和处理开销。

网络切换与保活并非同一件事

WireGuard 的设计支持在通过认证的数据交换中识别对端地址变化，这对移动网络具有意义，但实际恢复仍受接入网络、地址转换状态和服务器可达性影响。手机从 Wi-Fi 切换到蜂窝数据时，旧映射可能失效，新的数据需要重新建立可用路径。不能据此承诺所有切换都连续不断，也不应仅凭一次切换失败就判断密钥错误。先观察静态网络是否稳定，再检查切换后的恢复。

PersistentKeepalive 的用途是通过周期性通信帮助维持某些地址转换映射，不是加速开关。空闲时持续发送会增加无线活动，而完全不保活又可能让特定网络环境中的入站恢复变慢。是否需要以及采用什么间隔，应依据自己的服务器资料和网络条件判断。若应用在有业务流量时正常、长时间空闲后首次请求失败，才值得沿着映射与保活方向检查，而不是对所有配置一律启用。

性能优势必须放在任务条件中评估。固定的加密设计和较精简的数据路径有利于形成可预测的开销，但 UDP 的可达性、路径丢包和服务器转发能力仍可能成为瓶颈。只看一次大文件传输，无法说明后台空闲时是否省电。对移动设备，应同时观察连续任务、短时间待机以及多次网络切换，并避免在同一测试期间修改多个隧道参数，否则难以判断改善来自何处。

不要公开私钥，也不要把完整隧道资料当作普通截图分享。排错记录只保留字段名称、隐藏后的地址范围和失败阶段。

它更适合已有完整隧道规划、能够明确管理内部地址和对端身份的场景。若拿到的资料只是普通代理地址与口令，不应尝试把它转换成 WireGuard 配置。反过来，已经能够握手也只证明一部分条件成立，仍需验证目标地址的路由、DNS 和服务端返回路径，才能确认实际访问完整可用。

Hysteria2：QUIC 承载与带宽配置的取舍

先确认 UDP 与安全握手条件

Hysteria2 采用基于 QUIC 的承载思路，QUIC 运行在 UDP 之上，并在其连接机制中结合安全握手与流管理。该设计为不稳定链路上的传输提供了不同于传统 TCP 组合的取舍，但它并不能消除无线信号差、路径拥塞或服务器容量不足。客户端是否能联系到 UDP 入口，是进一步比较速度的前提。如果当前网络对相关数据报的处理不理想，换成这种协议并不一定改善体验。

需要核对的资料通常涉及地址、端口、认证、安全名称以及可能存在的其他附加条件。Hysteria2 与名称相近的早期协议不能凭同一个标签视为兼容，导入后应确认实际类型。即使入口端口看起来与常见网页服务相同，也不能推断传输方式相同。排查时要明确测试的是 TCP 可达性还是 UDP 上的真实握手，前者成功不能替代后者，也不能用网页能否打开来证明该入口可用。

带宽字段是行为输入，不是测速结果

部分配置涉及上行、下行带宽等参数，这些数值应结合客户端所用模式和服务端限制理解。它们可能参与发送或拥塞控制策略，并不是把数值填得更大就能获得相应容量。真实容量受接入网络、共享链路、服务器和目标共同限制。如果把期望值误当作可持续容量，可能增加排队、丢包和重传，最后出现下载看似积极、交互请求却更慢的情况。

上传与下载应分别考虑，尤其是上行容量较小的接入网络。大量上传占满上行后，其他连接的确认或控制数据也可能排队，影响整体体验。遇到这种现象，应先减少并发任务，观察空载与有载状态的差异，再核对带宽设置。不要一边更改服务器、一边提高多个带宽值，同时又改变目标文件；那样即使结果改善，也无法知道哪项修改真正有效。

弱网表现需要同时观察吞吐与抖动

在存在丢包或时延波动的链路上，QUIC 的流管理和连接机制可能表现出不同的恢复特点，但“适合弱网”应当是一项待验证的条件判断。连续下载能否维持吞吐，与短请求能否及时得到响应不是同一个指标。测试时可先进行轻量交互，再加入稳定的连续任务，观察同时使用时是否明显增加等待。只有接近实际用途的测试，才有助于判断该组合是否适合当前网络。

对电量的影响同样需要谨慎解释。数据报重传、持续发送、加密处理和无线模块活跃时间共同参与消耗。更快完成相同任务可能缩短活跃时间，但高强度传输或频繁失败也可能增加耗电。不能因为底层使用 UDP 就认定一定省电，也不能因为设备发热就立即归咎于协议。屏幕、媒体解码、后台同步和信号变化都应尽量控制，观察应覆盖足够长且可重复的使用过程。

如果握手失败，先核对地址、端口和 UDP 可达条件，再检查认证和安全名称。若能建立连接却在传输后变得不稳定，检查带宽参数、并发量和接入网络的容量变化；若只有某个网站失败，则回到 DNS 与规则路径。某些资料还带有专门的混淆参数，只有服务端要求并提供一致信息时才应填写，它们不是用于弥补错误认证或错误证书的万能选项。

Hysteria2 的比较重点是当前链路下的真实任务表现。带宽字段写得更大、测试条目返回更快，都不能单独证明持续访问更稳定。

适合尝试的前提是用户已有对应服务器信息、完整的安全参数以及允许相关 UDP 通信的接入环境。若这些条件无法确认，先使用已有且已经验证的连接完成基线测试。保留一份可恢复的原始资料，再对单个参数做受控修改，通常比反复重新导入后凭印象比较更可靠。

DNS、规则与场景选型：把结论变成可复验步骤

域名解析决定后续连接的起点

DNS 把域名转换为可连接的地址，它既影响目标访问，也可能影响代理服务器自身的拨号。两者需要分开检查：目标网站解析失败，并不必然代表服务器入口不可达；服务器地址使用域名时，入口解析出错又可能让所有请求都失败。配置加密 DNS 也不等于后续网站请求一定经过代理，解析通道和访问通道仍受各自设置与路由条件影响。应从实际路径出发，而不是仅根据一个 DNS 名称判断结果。

DNS 还涉及引导依赖：若解析服务器本身使用域名，它也需要可用的初始解析或连接路径。配置不当可能形成依赖循环，表现为一启动就所有域名都不可用。不要一次替换所有解析设置；先保留当前能够工作的基线，再核对所选配置如何处理服务器域名和目标域名。IPv4 与 IPv6 返回结果也可能走不同路径，出现部分目标超时时，应观察地址族与实际可达性，不要仅凭有解析结果就结束排查。

Global Routing 决定是否进入所选连接

配置模式对应 Config，代理模式对应 Proxy，直连模式对应 Direct。Config 按当前配置的规则选择策略；Proxy 用于让适用流量采用代理路径；Direct 用于直接连接。这里的路由选择不改变服务器要求的认证和安全参数，也不能修复错误证书。比较协议前，应确认两次任务都进入预期路径，否则一次直连、一次代理的结果没有可比性。Scene 的使用还涉及场景配置，不应与这三个基本姿态混为一谈。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

上面的片段只说明规则语法：示例域名使用 PROXY，匹配相应地址归属的请求使用 DIRECT，其余由 FINAL 处理。它不是完整配置，不能代替已有服务器资料。规则通常按配置的匹配顺序产生结果，因此宽泛规则的位置会影响更具体规则是否有机会命中。需要仅让指定网站使用代理时，可阅读DOMAIN-SUFFIX 与 FINAL,DIRECT 的写法，并在 Config 模式下核对实际命中。

按场景建立选择顺序

日常浏览优先关注启动等待、解析稳定性和网络切换恢复；持续传输关注可持续吞吐、并发时的排队以及服务器容量；实时交互关注抖动、丢包和任务所需的 UDP 支持；长时间移动使用则加入空闲通信与电量观察。已有 HTTP 或 SOCKS5 网关时，应首先满足其接口与安全条件；已有 WireGuard 网络规划时，先保证地址与返回路由正确；其他协议也都应从完整匹配开始，而不是先按名称排名。

建议建立一张简单测试记录，写下接入网络、目标任务、所用条目、Global Routing、是否发生网络切换以及失败阶段。先用稳定环境完成短请求和连续任务，再在可控条件下切换网络。每次只改变一个字段，失败后恢复原值。Connectivity Test 用于发现问题线索，不代表所有应用的体验；完整操作可参照连接验证步骤，常见疑问可查阅新手十问。

保留资料与排查证据的边界

订阅更新可能改变服务器条目和部分参数，修改前应区分哪些来自订阅、哪些属于本地配置。手工修正的字段若在更新后被覆盖，需要回到资料管理方式检查，而不是以为协议自动变化。向自己的服务商反馈时，说明首次失败的阶段、是否只影响特定目标以及更换网络后的结果，隐藏密码、UUID、私钥和完整订阅地址。可复验的现象比一张只有“连不上”的截图更有助于定位。

选型结论应写成条件句：在这组已有资料、这个接入网络和这类任务下，某个组合更合适。网络与服务器条件改变后，需要重新验证，而不是永久沿用一次测试的排名。