本页以 iPhone、iPad 上的操作逻辑为主。不同设备与应用版本的入口布局可能不同，设置名称和可选值以应用内实际显示为准；系统要求以 App Store 页面标注为准。第一次使用时，先完成已有服务器信息的导入和连接授权，再调整下面的选项。
客户端一次性买断 ≠ 线路套餐。Shadowrocket 是付费闭源商业应用，唯一获取入口为 App Store。本文以用户已有自己的订阅或服务器信息为前提；订阅链接请从你的服务商处获取。本站不提供、不销售、不推荐节点或订阅。
01 / ROUTING
Global Routing：配置、代理与直连
Global Routing 决定请求采用哪一种总体处理方式。在 Home 中打开 Global Routing，可以选择配置（Config）、代理（Proxy）或直连（Direct）。这里的选择不是服务器协议，也不是连接是否开启的替代开关：服务器参数决定如何连接，Global Routing 决定流量按什么方式处理。
| 姿态 | 处理逻辑 | 适用场景 | 检查重点 |
|---|---|---|---|
| 配置（Config） | 依照当前生效配置中的规则与策略处理请求。 | 日常按域名、地址等条件分流。 | 当前配置、规则顺序、匹配策略与 FINAL。 |
| 代理（Proxy） | 以代理方式处理受客户端接管的请求，具体仍受相关排除项影响。 | 短时检查所选服务器是否可以承载目标请求。 | 所选服务器、协议参数与代理相关设置。 |
| 直连（Direct） | 以直连方式处理受客户端接管的请求。 | 对照当前网络的直连表现，缩小故障范围。 | 本地网络、解析结果与目标服务状态。 |
日常使用先核对 Config
如果已经有可信的配置文件，先到 Config 确认使用的是哪一份文件，再回到 Home 选择 Global Routing → Config。只把文件导入列表，并不等于该文件已经生效。规则里的 PROXY 也不一定永远代表同一台服务器：如果配置使用策略组，还需要检查组内选择。
把 Proxy 与 Direct 用作对照
出现“某个网站打不开”时，可以保持其他条件不变，分别观察 Proxy 与 Direct 的结果。如果 Proxy 可以访问而 Config 不行，优先检查规则是否把该请求交给了错误的策略；如果两种方式都失败，再检查 DNS、当前网络和目标服务。测试后回到原先的使用姿态，避免把临时排查设置留作长期配置。任何姿态都不意味着所有系统流量必然走同一路径，也不能代替实际连接记录的核对。
02 / RULE
规则分流：匹配条件与执行策略
规则是在 Config 中描述请求处理方式的条件列表。使用 Global Routing → Config 时，规则通常按从上到下的顺序匹配，命中后采用对应策略。因此，规则“写了什么”和“放在哪里”同样重要。可以在 Config 中查看当前配置的规则，也可以在配置文本的 [Rule] 段核对具体条目；编辑前先保留原文件副本。
| 关键字 | 匹配对象 | 使用注意 |
|---|---|---|
DOMAIN | 完整域名。 | 用于明确指定的单个主机名。 |
DOMAIN-SUFFIX | 域名本身及其子域。 | 比逐条列出子域更适合处理同一域名范围。 |
DOMAIN-KEYWORD | 域名中的关键词。 | 匹配范围可能较宽，避免使用过短或含义模糊的词。 |
IP-CIDR / IP-CIDR6 | IPv4 / IPv6 地址段。 | 域名解析结果和解析时机会影响地址类规则的判断。 |
GEOIP | 地址数据库中的地区归属。 | 数据库归属不等于服务内容所在地，边缘地址可能变化。 |
USER-AGENT | 可获得的 User-Agent 信息。 | 依赖流量类型与可见信息，不能作为通用的应用识别方式。 |
FINAL | 未命中前序条目的请求。 | 通常放在规则列表末尾，承担兜底处理。 |
PROXY、DIRECT、REJECT 各表示什么
PROXY 指向代理策略，DIRECT 表示直连，REJECT 表示拒绝请求。它们是处理动作，不是域名或服务器协议。下例只用于说明顺序和写法，示例域名不是实际服务入口；复制前应理解每一行的目标与范围。
[Rule]
DOMAIN,ads.example.net,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY精确的例外规则宜放在更宽泛的规则之前。若一个域名已被前面的 DOMAIN-SUFFIX 命中，后面的 DOMAIN 条目就可能没有机会生效。修改后检查实际请求记录，确认命中的是哪条规则；不要只凭网页能否打开判断全部配置正确。远程配置更新还可能覆盖本地修改，长期维护时应分清自己的规则与远程文件的边界。
03 / SERVER
Subscribe 与 Add Server：订阅和服务器管理
服务器条目保存连接所需的参数，订阅则用于批量取得和更新这些条目。二者都不等于 Config 规则文件。Home 中的服务器列表用于选择连接对象；通过 Add Server 可以添加单条服务器，也可以按应用提供的 Subscribe 入口导入已有订阅。不同布局下入口位置可能调整，应以页面中的实际名称为准。
先分清订阅链接与单条连接信息
从你的服务商处获取订阅链接后，在对应 Subscribe 或 URL 输入位置粘贴完整地址，保存并执行更新，再检查是否生成了预期条目。如果拿到的是单条服务器参数，则在 Add Server 选择相应 Type，逐项填写地址、端口与认证信息。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 的字段不同，不能只换协议名称而保留上一种协议的全部参数。
TLS、SNI、传输方式等字段要与服务端要求一致；WireGuard 的 Address、Endpoint 与密钥字段也各有用途。字段没有依据时先保留既有值，不要用猜测补齐。完整的导入操作可参照首次连接教程，WireGuard 字段含义可参照WireGuard 参数说明。
更新不等于全部配置都被替换
订阅更新通常用于刷新其管理的服务器列表，不应把它理解成一定会更新当前 Config、切换 Global Routing 或选中最佳服务器。更新后核对条目名称、当前选择与测试结果；订阅管理的条目可能在下一次更新时重新生成，本地手动修改应先备份。删除订阅前也应确认是否还需要其下的服务器记录。
04 / ON DEMAND
On Demand：按网络条件触发连接
On Demand 用于依据设定的网络条件触发 VPN 连接行为。它解决的是“什么时候尝试连接”，不是“请求走哪个策略”。在应用提供的 On Demand 页面中查看条件与动作；路由分流仍由 Global Routing 和当前配置控制。
设置时先确认手动连接已经正常，再逐条增加按需条件。例如，如果需要根据 Wi-Fi 环境区别处理，应核对条件中的网络名称、匹配范围以及对应动作，并分别在匹配和不匹配的网络中验证。某个条件的名称看起来正确，并不代表当前网络一定满足它；不要一开始就叠加多条含义接近的条件。
启用后，系统可能在条件满足时再次发起连接，因此手动断开后重新连接不一定是异常。需要做一次完整的停用测试时，先检查 On Demand 是否仍启用，再查看系统 VPN 状态。网络切换、系统调度和设备权限都可能影响触发时机，按需连接不承诺每次切换都立即完成。设备上已有其他 VPN 配置时，也应确认当前实际使用的是哪一项。
05 / DATA
Data：流量统计与请求线索
Data 用于观察应用记录的流量统计，并为排查提供线索。进入 Data 后，先看清当前页面的统计对象、时间范围和单位，再比较上传与下载变化。不同页面可能展示连接期间或其他统计范围的数据，不能把某个数字直接解释成账单用量或某一应用的全部流量。
验证一个目标请求时，可先记下 Data 中的计数，单独执行一次目标操作，再返回观察变化。如果计数没有变化，应继续确认连接开关、Global Routing 以及请求是否进入了客户端处理范围；如果计数增加却加载失败，也不能由此认定服务端正常，还需结合解析、连接和响应阶段检查。
客户端的计数口径可能包含连接开销，也可能与服务商按账户、周期或计费方向统计的方式不同，因此 Data 不能代替服务商的用量记录。需要清零或重置时先阅读确认提示，保留排查所需的数据再操作。流量大小与请求成功率是不同维度，数字增长并不证明页面内容已完整加载。
06 / SETTINGS
Settings 常用项：解析、测试与同步
Settings 中的选项影响范围各不相同，有些与当前 Config 共同决定最终行为。下面按用途说明，不把某一组数值作为所有网络的固定推荐。默认值、可选项和入口以应用内显示为准；调整前记录原值，一次只改变一个影响因素。
DNS：先确认解析路径
DNS 把域名转换为地址，解析失败可能表现为连接超时，也可能让地址类规则无法按预期判断。检查 Settings 中可见的 DNS 相关项，同时核对当前 Config 是否包含 DNS 设置。不要假设修改 Settings 的某一项就一定覆盖配置文件中的所有行为。
设置前先说明目标：是解决解析超时、核对地址结果，还是调整解析请求的路径。若服务商提供了相应要求，应按要求填写；否则先保留可工作的现有方案，再逐项测试。加密解析只描述解析请求的传输方式，不会自动改变所有应用流量的路由。网页异常时也要区分“域名未解析”和“地址已得到但连接失败”，避免反复更换 DNS 掩盖真正的问题。
Test Method：测试结果必须在同一口径下比较
Test Method 用于选择连接测试方式，在 Settings 中核对后，再通过 Home 的 Connectivity Test 检查已有服务器。不同方法触及的环节不同：有的方法偏向传输层连通性，有的方法还依赖测试目标的响应。具体方法和目标以当前版本显示的选项为准。
比较服务器前，保持测试方法、测试目标和本地网络一致。较小的延迟数字不等于较高吞吐量，也不保证长连接稳定；超时同样可能来自测试目标暂时不可达。先测试少量条目，再用实际需要的服务验证，避免把一次结果当作永久排序依据。
Today Widget：快捷入口不代替主界面核对
Today Widget 提供系统允许范围内的快捷展示或操作。先在 Settings 中检查相关配置，再到系统对应的编辑入口添加可用组件。组件形式与可用操作受系统版本及应用支持情况影响，不应照搬其他设备上的布局。
通过组件操作后，回到 Home 确认当前服务器、连接状态与 Global Routing。组件显示可能受刷新时机影响；若展示没有立即变化，先核对主界面和系统 VPN 状态，而不是连续触发开关。需要暂停自动连接时，还要同时检查 On Demand。
iCloud 同步：同步前保留本地副本
iCloud 同步用于在支持的设备间传递应用允许同步的内容。先确认设备已登录预期的 Apple 账户，并允许应用使用 iCloud，再在 Settings 检查同步相关选项。哪些对象会同步、何时触发同步，应以应用内说明为准，不能默认服务器、配置、统计和所有开关都会完整复制。
首次启用或更换设备前，先备份需要保留的配置。两台设备上分别做了修改时，避免同时反复保存，先确认要以哪份内容为准，再观察另一台的结果。同步完成也不代表连接已经建立，新设备仍需检查当前配置、服务器选择和系统 VPN 授权。购买记录与配置数据是两个层面，恢复已购应用不等于恢复全部本地设置。
Diagnostics：按发生阶段收集线索
Diagnostics 用于辅助检查解析、连接和请求处理等环节。可在 Settings 中查找 Diagnostics 或对应诊断入口，先确定要检查的目标，再运行与问题相关的项目；具体项目名称以当前界面为准。诊断工具的成功结果只证明它覆盖的环节，并不代表所有目标请求都能成功。
记录问题发生时的网络类型、Global Routing、所选服务器和错误提示，再结合可用的 Log 信息判断失败阶段。需要更详细的记录时，短时启用并复现一次即可，完成后恢复适合日常使用的记录级别。日志可能包含域名、地址及连接参数，对外提供前先做脱敏；不要把完整配置当作排查截图发送。
07 / CHECK
设置变更后的检查顺序
同一次排查里同时改规则、服务器、DNS 和测试方法，会让结果失去可比较性。按下面的顺序检查，每完成一步记录一次结果；如果新设置没有改善，先恢复原值，再进入下一项。
- 确认连接基础。检查 Home 的连接状态和系统 VPN 授权，确认所选服务器属于已有订阅或自行配置的有效条目。
- 确认 Global Routing。在 Config、Proxy、Direct 之间做短时对照，区分规则问题与连接路径问题，测试后恢复原姿态。
- 确认当前 Config。核对生效文件、规则顺序、策略组选择及 FINAL，避免编辑了未使用的文件。
- 确认解析与测试口径。检查 DNS 结果，保持 Test Method 和测试目标一致，再观察 Connectivity Test 与真实请求。
- 确认自动化与同步。检查 On Demand 是否重新触发连接，iCloud 是否带来了另一设备的更改，然后用 Data 和 Diagnostics 复查。
需要逐项查看设置的作用范围时，继续阅读Settings 设置项参考；如果是单个服务器连接失败，可按节点超时检查顺序核对协议参数与系统时间。保留可重复的测试步骤，比频繁更换整份配置更容易定位原因。