Shadowrocket 功能与设置

Global Routing：配置、代理与直连

是什么：Global Routing 决定客户端处理流量时采用的整体姿态。配置姿态对应 Config，代理姿态对应 Proxy，直连姿态对应 Direct。这里的 Config 是模式名称；底部用于管理配置文件的 Config 则是页面入口，两者需要区分。

在哪个界面：在 Home 查找 Global Routing，点入后查看当前选中项。切换之前先记下原来的姿态、选中的服务器和配置名称，避免排查结束后忘记恢复。

怎么设：需要规则分流时选择 Config，并到配置页面确认正在使用的文件。若只有某个目标访问异常，可以在同一网络、同一服务器条件下，短暂切到 Proxy 做对照；检查完恢复原姿态。只改一个变量，测试结果才有比较意义。

注意什么：姿态不是服务器，也不负责补全服务器凭据。选择 Proxy 不代表服务器必然可用；选择 Direct 也不等于关闭系统中的 VPN 配置。系统保留流量与应用接管范围存在边界，不应把“全局”理解成设备每一个系统请求都具有完全相同的路径。

规则分流：匹配条件与处理策略

是什么：一条规则通常由类型、匹配内容和策略组成。类型决定“用什么条件识别请求”，策略决定“识别后怎样处理”。DOMAIN 匹配完整域名，DOMAIN-SUFFIX 匹配域名后缀，DOMAIN-KEYWORD 按域名中的关键字匹配。IP 类规则包括 IP-CIDR、IP-CIDR6 与 GEOIP。

在哪个界面：进入 Config，确认当前配置后再查看或编辑其中的规则。阅读规则时同时检查其前后的条目，而不是只搜索目标域名；较早命中的条目可能已经决定了处理方式。

怎么设：先明确目标应该直连、代理还是拒绝，再选择尽量准确的匹配条件。DIRECT 表示直连，PROXY 表示代理策略，REJECT 表示拒绝请求；使用自定义策略组时，名称必须与配置中的定义一致。以下只是规则语法示例，不是供所有网络直接套用的完整配置。

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

示例第一行让匹配 example.com 及其子域名的请求采用 PROXY；第二行根据 IP 地理数据库结果决定是否直连；最后一行 FINAL 处理此前均未命中的请求。域名解析结果与地理数据库会影响 IP 类规则的判断，不能只凭域名文字预测全部结果。

注意什么：规则一般按顺序匹配，将更具体的条件放在较宽泛条件之前。USER-AGENT 依赖请求信息是否可见，不适用于所有加密请求。REJECT 拒绝的是命中条件的请求，不能区分同一域名下所有内容的用途。出现误伤时先停用刚新增的一条规则复测，不要同时重写整份配置。

订阅与服务器：导入、更新与整理

是什么：Subscribe 用于维护通过已有订阅获取的一组服务器信息，手动添加则由用户逐项填写连接参数。订阅更新是刷新远端提供的条目，不等于更新应用，也不一定包含规则配置。服务器、订阅和配置文件属于不同层次，应分别确认。

在哪个界面：在 Home 查看服务器列表，通过 Add Server 添加信息；已有订阅可在添加入口选择 Subscribe 类型。二维码可使用 Scan QR Code，剪贴板导入则以应用实际出现的提示或操作入口为准。

怎么设：添加订阅前核对链接完整性，包含的查询参数不能遗漏。手填服务器时先选类型，再依据已有信息填写地址、端口、密码或其他认证字段；例如 Trojan 与 VMess 的认证结构不同，不应照抄另一种类型的表单内容。Shadowsocks、VLESS、Hysteria2、WireGuard 等也需按各自参数填写。

导入后先检查条目名称和数量是否符合预期，再选择其中一个进行测试。整理多个订阅时，可按自己能辨认的用途命名，并保留订阅归属，避免把来自订阅的条目误当作独立手填记录。更新前后若条目发生变化，应以订阅返回的内容为线索核对。

注意什么：订阅更新可能覆盖远端管理的字段，直接修改这些字段未必长期保留。删除订阅或批量清理前先做好自己的备份。订阅链接、二维码及分享链接可能包含认证信息，不要放入公开截图或日志。完整的更新、排序、删除和备份操作见订阅与服务器管理手册。

On Demand：按条件触发连接

是什么：On Demand 利用系统的按需机制，根据设置的网络条件决定连接行为。它回答的是“何时连接”，而 Global Routing 回答的是“连接后怎样处理流量”。两类设置相互配合，但不能替代。

在哪个界面：在 Settings 中查找 On Demand，查看当前可配置的条件和动作。若界面要求更新系统 VPN 配置，应先读清系统提示，再确认是否允许变更。

怎么设：先关闭自动触发，手动连接并验证当前服务器和配置可用，再添加一个明确的条件。例如，需要区分不同 Wi-Fi 环境时，先核对网络名称与条件匹配方式；如果有多条条件，逐条确认动作和匹配关系。保存后切换到对应网络，观察实际连接状态，再验证一个已知目标。

注意什么：启用按需连接后，手动断开可能被条件再次触发，看起来就像“刚关闭又连接”。排查这类现象时，先检查 On Demand 而不是反复删除服务器。按需机制不能恢复失效的凭据，也不保证每次网络切换都没有中断。停用后应核对应用状态与系统 VPN 状态是否一致。

Data：流量观察与统计口径

是什么：Data 用于查看客户端提供的流量统计。它适合观察一段操作是否产生流量、排查请求是否经过客户端，以及比较同一统计口径下的变化；它不是连接服务的账单页面。

在哪个界面：打开 Data，先阅读各项计数旁的标签，确认显示的是哪个范围、方向或时间段。不同设备和界面提供的统计项目可能不同，不应把当前页面没有显示的维度自行推算出来。

怎么设：排查前记录当前计数和时间，在尽量减少后台活动的条件下只做一次访问，再回到 Data 比较变化。若使用重置统计功能，先保存需要的历史信息，再从新的计数起点开始观察。测试过程中保持姿态、服务器和网络不变。

注意什么：上行和下行均可能产生数据，连接维护、后台应用与协议封装也可能带来额外开销。客户端记录与服务商计费口径、设备蜂窝网络统计不一定相同；剩余用量应向自己已有服务的管理界面核对。计数增长只能说明产生了相应流量，不能单独证明目标内容已成功返回。

Settings：解析、测试、快捷入口与同步

Settings 汇集应用运行行为相关的选项。建议先保留一组已经验证可用的设置，每次只改一项，并记录修改原因。若当前配置文件也定义了相关参数，需一并查看配置，避免只检查页面上的一个值。

DNS：先确认解析链路

是什么、在哪个界面：DNS 负责域名到地址的解析，相关入口可在 Settings 和当前配置的 DNS 设置中核对。解析成功与代理连接成功是两个不同环节；域名不能解析时，服务器延迟正常也不代表目标能打开。

怎么设、注意什么：先确认当前使用的解析设置及其来源，再按自己的网络需求调整。使用加密解析方式时，解析服务本身也必须可达。修改后用同一个域名重新测试，留意缓存与已有连接可能影响结果。不要把随机更换 DNS 当作所有故障的通用处理；若只有个别域名异常，应同时检查规则与返回地址。

Test Method：读懂测试结果

是什么、在哪个界面：Test Method 决定服务器测试采用的方式，在 Settings 中查找该项，再通过服务器列表提供的 Connectivity Test 执行测试。结果反映的是所选测试方法对应的路径，不是所有应用请求的综合表现。

怎么设、注意什么：比较服务器前固定测试方法；若该方法需要目标地址，也保持目标相同。单次较低的延迟不等于更高吞吐量，超时也可能由测试目标或当前网络导致。先重复测试，再用真实业务请求交叉验证，避免只按一次数字排序就判定连接质量。

Today Widget：快捷操作的系统入口

是什么、在哪个界面：Today Widget 提供与系统快捷展示或操作入口相关的设置，可在 Settings 中核对当前设备是否显示该项。系统侧能否添加、显示哪些内容，以当前系统和应用实际提供的组件为准。

怎么设、注意什么：若该入口可用，先在应用内确认服务器和姿态，再到系统提供的组件管理界面添加对应组件。添加后验证一次操作是否与应用状态一致。快捷入口用于减少操作步骤，不代替首次 VPN 配置授权，也不会单独配置服务器认证字段。

iCloud：同步范围与覆盖关系

是什么、在哪个界面：iCloud 相关选项用于在支持的范围内同步应用数据。先在 Settings 核对同步入口和说明，再检查系统中该应用的 iCloud 使用权限；具体同步对象以界面列出的范围为准。

怎么设、注意什么：跨设备操作前先备份，确认两端使用自己的同一 Apple Account，并给同步留出完成时间。不要在两台设备上同时批量删除或重命名同一批记录。若内容缺失，先核对同步开关与网络，而不是立即重复导入。同步不等于完整备份，应用购买记录、订阅状态和连接凭据也不能相互替代。

Diagnostics：按层定位连接问题

是什么：Diagnostics 用于辅助检查连接状态与错误线索。诊断的目的不是一次性“修复所有设置”，而是区分当前问题发生在本地网络、域名解析、服务器连接，还是规则选择与目标响应阶段。

在哪个界面：在 Settings 查找 Diagnostics 或对应诊断入口，按实际显示的工具与日志项目检查。阅读记录时先对齐时间，确认观察到的错误与刚才的测试属于同一次操作。

怎么设：先暂时停用自动触发行为，建立可重复的测试条件，再按下列顺序收集结果。每完成一步就记录结果，已经验证正常的层次不必反复重设。

1. 确认设备当前网络可用，并检查系统时间是否准确。
2. 核对服务器地址、端口、认证字段及已有服务状态。
3. 执行 Connectivity Test，记录采用的 Test Method。
4. 访问一个明确目标，对照 Config 与短暂使用 Proxy 时的结果。
5. 查看同时段的诊断线索，分别判断解析失败、连接失败或策略选择异常。
6. 恢复原来的姿态与按需设置，再次验证日常使用场景。

注意什么：分享诊断材料前，应移除订阅链接、认证字段、二维码与能够关联个人活动的信息。不要直接公开整份配置。只有规则姿态下失败时优先查配置；所有姿态都异常时，先检查共同依赖的网络与服务器条件。更多具体情形可查阅常见问题，不熟悉的关键字可通过术语表逐项核对。