Shadowrocket 协议参考
参数、速度与电量取舍

01 / CONNECTION LAYERS

连接分层：协议、传输与规则分别负责什么

先区分四个不同问题

在 Shadowrocket 中选择协议类型，首先是在回答“客户端应当用什么格式与服务器交谈”。Shadowsocks、VMess、VLESS、Trojan 等类型，规定认证和数据封装的一部分行为；TCP、UDP、WebSocket 则涉及数据如何被运送。TLS 负责建立经过认证的加密通道，规则决定哪些请求进入这条通道。这几层可以组合，但不能互相替代。只把类型改成另一个名字，不会把远端服务器同步转换成对应服务。

例如，已有配置同时包含服务器地址、端口、UUID、WebSocket 路径和 TLS 服务器名称，这不是五种独立协议，而是一条连接在多个层次上的约定。客户端先找到服务器，再按指定方式建立传输，完成必要的安全握手和身份认证，最后转交目标请求。任何一层不一致，都可能表现为同一个“连接失败”。因此，排查前应先记录配置结构，而不是根据错误提示随意切换类型。

速度与电量不能只看协议名称

一次网页打开，包含域名解析、建立连接、握手、传输和应用处理。短请求往往更受往返时间与握手影响，长时间下载则更受可用带宽、丢包和服务器负载影响。某个配置在下载时吞吐较高，不代表它在打开许多小页面时也更快；一次测试数值较低，也不能直接证明该协议不适合当前设备。应使用相同目标、相近时间和相同网络重复比较，保留失败次数而不只保留最好结果。

在 iPhone 与 iPad 上，电量还与无线网络状态密切相关。弱信号下反复重传、连接断开后持续重建、后台任务频繁唤醒，都可能比加密算法本身更明显。Wi-Fi 与蜂窝网络之间切换后，既有连接可能需要恢复；不同传输设计的恢复方式不同，但不能据此给出固定省电百分比。合理的判断是先让连接稳定，再观察相同使用时长下的耗电与发热，而不是寻找一个永远最省电的协议。

选型从可用条件开始

实际选择顺序应是：先看已有服务器提供哪些类型，再确认当前网络是否允许对应传输，最后比较使用体验。如果服务器只提供一种经过确认的配置，直接完整导入通常比手动改成另一类型更可靠。若同时有多种配置，先保留原项，再分别建立可识别的名称；每次只改变一个测试变量。服务器地址与认证信息不同的两项，不能被当成仅比较协议差异的严格实验。

阅读后续章节时，还要区分“协议能够表达什么”与“当前服务器启用了什么”。协议设计中的可选能力，只有两端实现与配置都支持才会生效。订阅可能省略默认值，也可能使用分享格式中的简称；遇到无法识别的字段，应核对配置来源的说明。不要把未知字段自行删除后继续猜测，也不要把包含凭据的完整配置发到公开页面。需要操作顺序时返回快速上手说明，需要错误分类时再看问答。

02 / SHADOWSOCKS

Shadowsocks：加密方法与密码必须成对核对

设计重点是精简的代理封装

Shadowsocks 的设计起点是用相对精简的方式，在客户端和服务器之间转交代理流量。它通常不像完整网络隧道那样先为设备建立虚拟地址和路由关系，而是围绕目标连接进行封装。理解这一点，有助于解释为什么配置中最核心的内容往往是服务器、端口、加密方法和密码，而不是一组隧道网段。它的使用表现仍取决于服务器实现、网络质量以及实际采用的方法，不能仅凭配置较短就推断速度。

常见的现代配置使用带认证的加密方式，使接收端既能解密，也能发现数据被篡改或密钥不匹配。不同方法对密钥材料、数据组织和双方实现有不同要求；名称相近也不意味着兼容。服务器要求哪一种方法，就应在客户端选择相同项目。不要因为某个名称看起来更新，就在原配置上直接替换；替换以后，原密码是否仍符合该方法的格式要求也需要重新确认。

四个核心字段的核对顺序

先检查服务器地址是否包含多余空格、协议前缀或路径。地址字段通常填写域名或地址本身，端口单独填写；把整段分享内容粘到地址字段，不能代替导入。随后核对端口是否属于这项服务，尤其注意同一台服务器可能为不同协议分配不同端口。再核对加密方法与密码，密码中的大小写和结尾字符都应保留，复制时不要顺手删掉看似特殊的符号。

部分较新的方法对密钥格式有专门约束，不能把普通记忆型密码与编码后的密钥当成同一类输入。若服务信息包含多段密钥或额外身份材料，应按提供方的说明导入，不要自行拼接。已有订阅能够正确识别类型时，优先保留其字段关系。手动建立时可先只记录必要参数，确认能连通后再研究可选项，避免同时引入多个未经确认的设置。

还要单独检查 UDP 条件。某些应用会发起 UDP 请求，但服务器是否处理、当前路径是否允许，以及客户端如何转发，都需要对应支持。网页可以打开，只能说明部分 TCP 请求成功，不能据此确认语音、实时互动或其他 UDP 场景正常。反过来，某个实时应用异常，也不能直接证明密码错误；先区分认证失败和特定流量类型失败，排查范围会小得多。

iOS 上如何观察实际表现

在 iOS 上，持续传输时的加密成本与处理器能力、方法实现和流量规模有关。日常阅读页面时，连接建立与无线网络的能耗可能更显著；大文件传输时，加密处理和持续无线活动才更容易被观察。测试时应分别记录短页面访问、持续传输和锁屏后的恢复，不要只测一次下载。若设备发热，应先排除同时进行的备份、媒体处理和应用更新，避免把所有负载归到代理协议。

出现无法连接时，先恢复完整的原始参数，确认系统时间与网络正常，再用同一配置在另一种网络条件下复测。如果所有请求都失败，重点看地址、端口、方法与密码；如果只有部分目标失败，再检查规则、解析与目标本身。不要通过频繁更换加密方法来碰运气，也不要把测试失败后产生的临时副本混进正式订阅列表。为手动项添加清楚的备注，能减少之后选错默认服务器的情况。

适合选择 Shadowsocks 的前提，是已有服务器明确提供匹配配置，而且测试满足实际用途。它的精简参数便于逐项核对，但不意味着每项都可以省略。若配置额外要求插件或其他封装，而当前界面没有对应能力，应先核实是否被支持；不要把缺失部分当作不重要的附加说明。最终应保留一份可复现的有效配置，而不是只记住协议名称。

03 / VMESS & VLESS

VMess 与 VLESS：认证、加密和传输需要分别理解

两种协议不能只靠切换类型互换

VMess 与 VLESS 都经常出现在包含多层传输选项的配置中，但两者不是同一个协议的显示别名。VMess 在协议层包含身份认证和数据保护相关设计；VLESS 采用更精简的协议层结构，常与另外配置的安全传输配合。两者经常使用 UUID 形式的身份标识，因此容易被误认为只需替换类型即可转换。事实上，即使 UUID 看起来相同，服务器也必须运行对应协议并接受相同的传输组合。

UUID 是结构化标识，不是服务器地址，也不是用于验证网站证书的名称。核对时应检查是否完整、是否混入空格以及复制内容是否属于当前服务器。不要把多个配置中的 UUID、端口和路径交叉组合。VMess 的认证还涉及时间条件，设备时钟明显偏离时可能产生失败；应保持系统时间自动设置。这个处理只能修复时间问题，不能弥补错误的身份标识或传输参数。

把传输字段当作一个组合检查

常见配置会在协议之外指定 TCP 或 WebSocket 等传输。选择 WebSocket 时，路径需要与服务器接收位置匹配，斜杠、大小写以及附带参数都可能影响结果。Host 通常参与应用层请求或前端路由，TLS 中的服务器名称则参与安全握手与身份验证；两者可能相同，也可能由部署方式决定而不同。服务器地址、Host 和 TLS 名称是三个角色，不应为了界面整齐而强行填写成同一个值。

如果一个域名背后有多层转发，客户端能够连接到前端端口，并不代表请求已经到达正确的协议服务。错误路径可能得到普通网页响应，错误 Host 可能被分配到其他站点，TLS 名称错误则可能在更早阶段被拒绝。观察到端口可达，只完成了第一层检查。应按地址与端口、TLS、传输路径、协议认证的顺序逐层核对，而不是因为服务器“在线”就排除配置问题。

VLESS 自身不应被当成普遍提供载荷加密的替代品。需要保护客户端到服务器之间的内容时，必须确认实际配置使用的安全层及其验证方式。某些配置还包含专门的流控或握手参数，这些不是通用的加速开关；只有两端都约定相同组合才有意义。如果当前界面不显示某个字段，应先确认该组合是否被支持，不能把未知值放入备注或其他不相关字段来代替。

短连接开销与复用的边界

在 iPhone 上，首次连接的体感可能同时受到网络往返、TLS 握手和额外传输封装影响。把 VMess 或 VLESS 简单排成快慢顺序没有可靠依据：不同服务器距离、传输方式和连接复用策略，足以改变结果。复用可以在某些场景减少重复建立连接的成本，但也会让多个请求共享一个底层通道。出现拥塞时，共享并不一定更顺畅，应依据同一工作负载测试，而不是始终开启所有可选项。

电量观察同样需要控制条件。若某项配置在网络切换后持续认证失败，反复握手可能增加后台活动；修正路径、时钟或认证信息，比换一个听起来更轻量的协议更直接。锁屏后再打开应用，若只有首次请求慢，要区分正常重建连接与不断重试。可记录恢复所需时间、是否需要手动切换以及错误是否重复出现，不必把单次现象扩大为该协议的固定特征。

实际选型时，已有完整 VMess 配置且表现稳定，就没有必要只因另一个类型较精简而迁移。已有 VLESS 配置时，则重点确认安全传输、认证和可选流控的对应关系。维护多个测试项时，用备注标明传输和用途，而不要改写服务器下发的协议字段。若需要了解如何选中默认项并运行 Connectivity Test，可参阅首次连接与验证说明。

04 / TROJAN & TLS

Trojan：把 TLS 身份验证与协议密码分开检查

利用成熟的 TLS 通道承载代理请求

Trojan 的重要设计取舍，是利用 TLS 提供加密与服务器身份验证，再在通道中完成协议认证和请求转发。因此，理解它不能只看密码字段，还需要理解证书、服务器名称和连接目标之间的关系。TLS 是广泛使用的安全传输机制，但协议采用 TLS，并不代表任意 TLS 服务端都能接受 Trojan 请求。客户端仍需要连接到正确端口，并向支持该协议的服务提交正确认证信息。

服务器地址决定客户端向哪里建立连接，端口决定联系哪个服务；TLS 服务器名称用于握手中的名称声明与证书身份核对。证书应覆盖被验证的名称，并处于有效期内，证书链也应能被系统信任。若直接以地址连接但证书签发给域名，就需要按原配置正确指定验证名称。不要把“能够解析到同一台机器”理解为“证书可以验证任何名称”，网络位置相同不等于身份相同。

握手失败不等于密码错误

认证通常发生在安全通道建立之后。如果证书过期、设备时间错误、名称不匹配或服务器无法提供完整证书链，连接可能尚未进入密码验证阶段。此时反复重输密码不会修复 TLS。应先检查系统日期、域名拼写和证书相关提示，再联系已有服务器的维护方核对证书部署。相反，TLS 已经成功但协议认证被拒绝时，才应重点检查密码、服务类型和服务器端权限。

密码应完整复制，大小写、特殊字符和首尾位置都需要保留。若订阅更新后密码改变，旧的手动副本可能继续失败；应确认当前选中的是订阅中的新项，而不是名称相近的历史项。保存密码时也不要把中文注释、引号或换行当成密码内容。排查记录可以写“密码已与来源核对”，但不应把真实密码附在公开截图或日志说明中。

有些配置会额外提供 ALPN 或其他 TLS 协商要求。ALPN 用于协商应用层协议，不是可以随意选择的速度档位；是否需要填写以及可接受的值，要以服务端要求为准。不要为了让表单看起来完整而复制别处的值。若订阅已经带入相关字段，应保留其组合，遇到异常时逐项对照原始说明，而不是一次清空所有安全选项再测试。

iOS 上关注握手与连接恢复

TLS 首次建立需要交换握手信息，网络往返时间会影响这段过程。持续连接建立后，实际吞吐还取决于传输路径、拥塞和服务器负载；不能把首次打开页面的耗时等同于长期速度。会话恢复在条件满足时可能减少后续握手成本，但是否发生由实现与服务器状态共同决定，不应承诺每次都会复用。测试可分别观察首次访问和紧接着的再次访问，避免把缓存效果误认成协议变化。

从 Wi-Fi 切到蜂窝网络后，既有底层连接可能需要重建，短暂等待并不一定代表凭据失效。如果每次恢复都长时间失败，再检查当前网络到服务器端口的可达性及解析结果。电量方面，频繁重建 TLS、连续失败重试和弱信号重传，比一个已经稳定运行的长连接更值得关注。应先消除错误重试，再比较正常使用时的电量，不给单一握手机制贴上固定耗电标签。

适合选择 Trojan 的情况，是用户已有配置明确采用此类型，并且 TLS 名称、证书和认证信息齐全。它的配置检查可以形成清楚顺序：先确认目标位置，再验证安全握手，最后核对密码与业务请求。若网页仍异常而连接测试通过，应继续检查域名解析和规则，不能因为使用 TLS 就跳过后续层次。具体模式选择可结合Global Routing 三种姿态说明阅读。

05 / HTTP & SOCKS5

HTTP 与 SOCKS5：代理接口不等于加密通道

两类通用代理的设计背景

HTTP 代理来自应用层代理需求，能够处理相应的 HTTP 请求，并常通过 CONNECT 方法为其他目标建立字节隧道。SOCKS5 则提供更通用的连接协商方式，客户端向代理声明目标，再由代理建立后续通信。它们都是代理接口，但接口本身不自动说明客户端到代理之间是否加密，也不说明代理是否支持所有请求类型。选择时必须同时查看传输保护、认证方式和服务器开放的能力。

一个常见误区，是看到目标网站使用 HTTPS，就认为到代理的每段信息都受同样保护。目标网站的 TLS 可以保护通道中的业务内容，但普通 HTTP 代理的 CONNECT 协商及代理认证，不会因为目标使用 HTTPS 就自动获得同一层保护。若是通过 TLS 连接代理，则还要单独验证代理证书。应区分“目标网站采用 HTTPS”和“客户端以加密方式连接代理”，这两个判断不能互换。

地址、凭据与解析位置

建立 HTTP 或 SOCKS5 项时，先确认服务器类型，随后核对地址、端口、用户名和密码。服务器可能允许无需用户名的访问，也可能强制认证；留空字段是否有效应由原配置决定。用户名与密码是两项独立内容，不能把带分隔符的整段文本直接填入其中一项。某些部署还会根据来源网络限制访问，此时即使认证信息正确，换到蜂窝网络后也可能被拒绝，需要向已有服务器的维护方核实权限。

解析发生在哪里，也会影响表现。客户端可以先把域名解析为地址再请求代理，协议也可能允许把域名交给代理解析；实际行为取决于客户端设置、协议能力和服务端实现。两种路径得到的地址不一定一致，尤其是目标服务按访问位置分配地址时。出现“域名失败、地址似乎可达”的现象，应检查解析路径和结果，而不是马上更换代理类型。直接使用地址测试 HTTPS 还可能引入证书名称问题，不能作为完全等价的替代实验。

SOCKS5 协议定义了 UDP 关联机制，但并非每个部署都会开放，也不能仅凭类型名称确认当前配置可用。服务器可能只处理 TCP，相关防火墙也可能阻止 UDP 数据返回。HTTP CONNECT 常见用途是建立 TCP 隧道，不应默认它具有与 SOCKS5 UDP 关联相同的能力。如果用途包含实时音视频，应针对所需流量测试，不能只凭一个网页打开成功就判断全部满足。

场景选择与 iOS 使用表现

如果已有单位网络、实验环境或自管服务器提供通用代理接口，HTTP 与 SOCKS5 便于接入现有服务。这里的选择依据是接口匹配，而不是哪个名称更高级。缺少额外加密并不等于适合在所有网络中传送敏感认证；应先明确链路边界和保护方式。不要把网络中的明文认证当作普通排查信息公开，也不要在不清楚访问权限时反复提交凭据。

在 iOS 上，这两类接口的速度同样受到代理距离、连接建立方式及目标响应影响。较少的协议封装未必抵消较差的路径，也不能保证更省电。若出现应用之间表现差异，先区分它们是否使用不同目标、不同传输及不同解析路径。已有 TCP 测试通过但实时功能失败时，优先检查 UDP 条件；只有认证失败时，才集中检查用户名与密码，避免重复修改无关设置。

最终应为每个通用代理记录三个结论：是否保护到代理的链路、支持哪些传输、域名由哪一端解析。三项明确后，才能判断是否符合自己的用途。若只能确认服务器地址和端口，而其他信息缺失，先向原配置来源核实；不要用默认猜测补齐安全条件。这样可以把接口可用与使用合适分开，减少“能连上却不符合预期”的情况。

06 / WIREGUARD

WireGuard：密钥、隧道地址与路由范围一起看

从网络隧道而不是单个代理请求出发

WireGuard 面向加密网络隧道设计，以对等端、公私钥和路由范围建立通信关系。与逐个声明代理目标的协议相比，它更接近让数据包进入一条虚拟网络路径。因而配置常出现隧道内部地址、对等端公钥、端点和允许地址范围。理解这个差别很重要：一个能够发起握手的端点，还不等于已经具备正确的业务路由；密钥正确，也不能代替服务器端的转发与回程配置。

每个对等端持有自己的私钥，并使用另一端的公钥识别对方。客户端私钥应留在自己的配置中，服务器公钥来自服务器配置；两者不能交换填写。可选的预共享密钥是在既有密钥关系上增加一项共享材料，不是私钥的替代名称。若服务端没有配置，客户端单独填入不会增加兼容性，反而会导致认证不一致。导入后应完整保留密钥关系，不要把多份配置中的密钥任意混用。

端点、地址和 AllowedIPs 的不同职责

端点是外部网络中用于联系对等端的位置，通常由域名或地址加端口组成。隧道内部地址则是在加密网络中使用的本地身份和寻址信息，不应填成端点的公网地址。AllowedIPs 同时涉及对等端的地址约束与路由选择，但其在具体客户端中的生效范围仍要结合应用的整合方式理解。它不是一张可以任意扩大、且永远不会影响其他请求的普通白名单。

如果把路由范围改得过宽，原本无需进入隧道的流量也可能被送入；改得过窄，则目标网段可能没有对应路径。服务器端还需要知道如何把响应送回客户端，相关转发、内部网段和访问控制应保持一致。握手成功但目标无法访问时，应先区分是只有某个内部网段失败，还是所有业务都失败，再核对地址范围与回程路径，而不是重新生成密钥。

DNS 也需要单独看待。能够访问隧道内的某个地址，不代表内部域名一定能解析；配置中若指定了内部解析服务器，它本身也需要有可达路径。反过来，域名能够解析，只证明得到了地址，不证明该地址的业务端口可达。排查时分别记录解析结果与目标连接结果，不要把两个步骤合并成一句“网络正常”。涉及 IPv6 时，还应确认对应地址族和路由是否完整配置。

UDP、保活与 MTU 的取舍

WireGuard 使用 UDP 承载隧道，当前网络需要允许客户端与端点交换相应数据。它能在一定条件下适应端点变化，但连接恢复仍受网络映射和服务器可达性影响。某些环境需要持续保活来维持网络地址转换映射；保活会产生周期性数据包，不应为了“更稳定”无条件缩短间隔。在 iPhone 锁屏与蜂窝网络下，额外唤醒可能影响电量，应采用服务配置所需的最小必要行为。

MTU 决定隧道可处理的数据包大小。封装本身占用空间，如果路径无法顺利处理较大数据包，可能出现小请求正常、大内容停滞的情况。但这类症状也可能来自其他原因，不能一看到下载慢就修改 MTU。应保留原值，先确认是否与包大小相关，再根据服务器与路径条件测试调整。多个设备共用配置时，也不要把某台设备的有效数值直接当成所有网络的标准。

在 iOS 上评估 WireGuard，应分别观察持续传输、长时间待机和网络切换后的恢复。它采用精简的密码与握手设计，但设备耗电仍可能被信号质量和保活方式主导。没有周期性后台负载的测试，与持续传输的测试不能直接比较。若用途是访问已有的内部网段，应优先验证网段覆盖与解析；若用途是一般请求转发，则还要理解它与 Shadowrocket 当前规则配置的配合边界。

选择 WireGuard 的依据应是用户已有明确的隧道配置和访问目标，而不是仅凭某次吞吐表现。保存故障记录时，说明端点是否可达、是否完成握手、哪些地址范围失败即可，私钥不应进入公开材料。涉及配置迁移时，也应确认服务端是否允许同一身份的使用方式，避免两个设备同时使用同一份配置造成难以复现的连接变化。

07 / HYSTERIA2

Hysteria2：先确认 UDP 路径，再讨论吞吐优势

围绕 QUIC 与不稳定链路的设计取舍

Hysteria2 基于 QUIC 构建传输，QUIC 本身运行在 UDP 之上，并结合现代安全握手机制。它的设计关注在一定丢包、时延和带宽条件下保持传输效率，同时提供代理请求承载。这个方向不等于任何网络都更快：UDP 是否可达、路径是否限制 UDP 速率、服务器负载和拥塞控制方式，都会改变实际表现。比较协议时，应先确认网络满足基本传输条件，再讨论吞吐。

QUIC 在同一连接中组织多个流，可以减少部分传输层队头阻塞影响，但所有流仍共享实际路径和拥塞预算。无线网络出现严重丢包时，任何可靠传输都需要恢复丢失的数据，协议无法凭空增加可用带宽。持续传输表现较好，也不意味着所有短请求的首次响应都更快。应把“能在某种条件下改善表现”与“保证在任何条件下领先”区分开，避免仅凭协议名称作结论。

认证、TLS 与可选混淆分开核对

建立配置时，服务器地址与端口负责找到端点，认证信息负责确认使用权限，TLS 服务器名称和证书负责验证远端身份。若原配置还要求混淆类型及密码，则需要两端一致。混淆密码不是认证密码的别名，也不应被填入证书名称字段。缺少任何一组必需信息，都应回到已有订阅或服务器说明核对，不要根据其他协议的习惯拼凑。

证书验证的原则与其他 TLS 配置相同：名称应匹配，证书应有效，设备时间应准确。UDP 可达只是底层条件，不代表安全握手与认证已经成功。若切换网络后恢复连接，应关注当前路径是否仍允许相同端口的数据往返；若所有网络都失败，再检查服务器状态与参数。不要因为此协议使用 QUIC，就认为可以跳过证书检查或把握手错误归为普通延迟。

部分部署会要求填写上传或下载带宽信息。这类参数可能参与拥塞控制与发送行为，不是显示给用户看的装饰数字，更不是随意填大就能提速的限制解除项。应依据真实链路能力与服务端说明填写，并注意单位。移动网络可用带宽会随位置与信号变化，过高估计可能增加排队、丢包或与其他应用争用；过低估计又可能限制吞吐，需要在稳定条件下审慎测试。

iPhone 上分别测试速度、发热与切网恢复

评估持续下载时，应选择大小与来源相近的内容，记录完成时间及期间是否发生中断。只看开始几秒的瞬时速度，可能被缓存、突发发送和无线网络调度影响。若背景还有其他传输，结果也不能代表该配置本身。测试后再观察日常页面、消息和媒体请求，不要为了大文件吞吐牺牲实际使用中的稳定性，也不要把一次成功当成长期可用的保证。

在电量方面，较高吞吐可能缩短传输持续时间，但持续高负载也可能增加处理器和无线模块活动，最终结果与工作负载有关。网络较差时频繁重传与重新握手，往往会改变耗电。应比较完成同样任务的用时、发热和电量变化，而不是只比较单位时间发送了多少数据。短时间电量百分比变化较粗，无法支持精确的协议能耗结论，适合用作趋势观察而非测量仪器。

QUIC 具有连接迁移相关设计，但具体恢复效果仍受两端实现、网络映射和路径变化影响。不要把它理解为从 Wi-Fi 切换到蜂窝网络时绝对不中断。可在可控条件下进行一次切换，观察现有业务是否恢复以及新请求是否成功；若只有既有业务中断，需区分业务自身的恢复机制。避免连续快速切换网络，否则很难判断失败发生在哪一次变化。

适合尝试 Hysteria2 的前提，是已有服务器提供匹配配置、当前 UDP 路径可用，并且用途确实需要比较其传输表现。若用途主要是轻量页面访问，稳定性与恢复时间可能比峰值速度更重要。保留一个已知有效的配置作为基线，逐项测试后再决定日常使用项；不要因为某项参数看起来具有性能含义，就在缺少测量依据时同时调整多个值。

08 / VERIFICATION & DIAGNOSIS

选型落地：从协议核对到规则验证的完整顺序

先建立可回退的基线

开始排查前，保留原始订阅项或手动配置副本，记录当前网络、默认服务器和 Global Routing 姿态。确认已有订阅更新成功，并区分订阅原项与历史手动项；相同名称不意味着参数相同。接着在 Home 选择要测试的服务器，按照系统提示完成必要授权，再进行连接测试。一次只选一个明确对象，能够避免修改了某项参数，却实际测到另一项服务器的情况。

Global Routing 的三种姿态分别是配置 Config、代理 Proxy、直连 Direct。Config 按当前配置规则处理请求；Proxy 用于让适用流量通过所选代理路径；Direct 用于直连。它们改变请求的处理方式，不会转换服务器协议。排查中可以临时比较不同姿态，但测试后应恢复原来需要的模式。若 Direct 也失败，应先检查设备网络和目标本身，而不是继续修改代理密码。

把失败定位到最早发生的一层

先判断服务器地址能否正确解析、当前网络是否能够到达相应端口。随后检查 TLS 或其他安全握手，再核对协议认证，最后看目标请求与规则。最早失败的一层，应优先处理；后续层次暂时没有可靠结论。例如证书握手尚未成功时，不能据此判断代理认证有效；代理认证成功时，也不能据此证明某个内部网段已配置正确回程。

Connectivity Test 可以帮助确认所选项的某种连通结果，但测试并不覆盖全部目标、全部地址族或全部应用行为。测试通过而网页异常时，应继续检查解析、目标证书和路由；测试失败时，也应查看实际业务是否同样失败，避免把单个测试目标的问题扩大成协议故障。正确的结论应说明测试范围，而不是把一个成功结果写成所有功能正常。

规则验证与协议验证分开进行

以下片段用于说明 Shadowrocket 配置文件中的规则结构，不包含服务器、认证或可直接使用的订阅。域名使用示例值；实际部署前应按自己的用途检查每条规则。规则按顺序匹配，前面的命中会影响后面的处理，末尾 FINAL 负责处理此前未命中的请求。这里的 PROXY 与 DIRECT 是处理动作，不是服务器协议名称，也不是把连接转换成另一种协议的指令。

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

如果 Proxy 姿态下目标可访问，而 Config 下失败，应重点检查该目标被哪条规则处理、是否得到预期解析结果，以及配置选择的代理路径。不要立即替换协议，因为两次测试可能根本没有走同一条路径。GEOIP 依据地址归属数据库进行匹配，不能直接代替精确域名意图；域名规则与地址规则同时存在时，应检查顺序和解析条件，而不是只看某个关键字是否出现。

最后按场景选择：一般网页关注首次响应和稳定性，持续传输关注完成时间与重传，实时业务关注 UDP 条件和时延波动，内部网络访问关注路由范围与解析。只有已有服务器提供多个可用方案时，比较协议才有意义。不存在适合全部网络和用途的固定排名，也不应把短期测试转化成对某种协议永久优劣的判断。

需要求助时，整理协议类型、传输方式、发生问题的网络、错误阶段与已经做过的单项测试。隐藏密码、UUID、私钥和订阅中的身份信息，仅提供解决问题所需的结构。常见现象可继续查阅问答；需要重新梳理从导入到连接的操作，则返回使用说明。形成一份能够回退、能够复现的有效配置，比反复试遍所有类型更有用。