功能路径与设置逻辑
本页按实际操作顺序说明 Global Routing、规则、Subscribe、On Demand、Data 与 Settings。每一项分别回答“是什么、在哪里、怎么设、要注意什么”，适合已经完成 App Store 安装并准备整理现有配置的用户。
本页所有导入步骤均以用户已有自己的订阅或服务器信息为前提。购买 Shadowrocket 取得的是客户端使用权，客户端一次性买断 ≠ 线路套餐。应用获取、系统要求与兼容设备信息均以 App Store 产品页 标注为准。
01 / GLOBAL ROUTING
Global Routing 决定连接建立后，网络请求采用规则判断、统一交给 Proxy，还是直接连接。它是整体处理姿态，不等同于某一条规则，也不会替代服务器选择。日常使用前，应先确认当前选中的服务器可用，再选择与目的相符的姿态。
| 中文姿态 | 界面词 | 处理方式 | 适合场景 | 主要注意点 |
|---|---|---|---|---|
| 配置 | Config |
按照当前配置中的规则自上而下匹配，再交给对应策略处理。 | 需要按域名、地址或地区分别使用 PROXY、DIRECT、REJECT 时。 | 结果取决于规则顺序、规则内容、策略名称和当前配置是否生效。 |
| 代理 | Proxy |
请求统一交给当前选定的 Proxy 处理，便于绕开规则差异进行验证。 | 临时判断问题是否来自规则，或短时间要求统一处理请求时。 | 它会跳过细分规则意图，不适合作为所有配置问题的最终处理办法。 |
| 直连 | Direct |
请求采用 Direct，不经过所选 Proxy。 | 核对本地网络是否正常，或暂时验证连接差异时。 | Direct 正常而 Config 异常，通常应继续检查规则、DNS 与服务器状态。 |
在 Home 中找到 Global Routing，可看到 Config、Proxy、Direct 三种姿态。Config 是规则驱动方式；Proxy 是统一使用当前 Proxy；Direct 是直接连接。切换只改变当前处理姿态，不会自动修改 Config 文件，也不会替用户选择另一台服务器。
如果目标是长期按规则使用，通常先在 Config 中确认配置，再回到 Home 选择 Config。若某个网站在 Config 下异常，可以短暂切到 Proxy 和 Direct 分别验证。三个结果之间的差异能帮助判断问题位于规则、服务器还是本地网络。
02 / RULES
规则分流的核心是“从上到下，首条命中即停止”。规则左侧描述匹配条件，末尾策略描述如何处理。具体规则通常位于当前 Config 的 Rule 段，使用时应同时检查关键字、匹配值、策略名和排列位置。
DOMAIN 用于完整域名；DOMAIN-SUFFIX 用于某个域名后缀及其子域名；DOMAIN-KEYWORD 按域名中的关键词匹配。IP-CIDR 与 IP-CIDR6 分别处理地址网段，GEOIP 根据地址归属信息判断，USER-AGENT 则依据请求中的标识匹配。不同类型解决的问题不同，不宜仅因为名称相近就互相替换。
域名规则通常放在较宽泛的 GEOIP 或 FINAL 之前。精确条件应优先于宽泛条件，否则前面的宽规则可能提前命中，使后面的细规则没有执行机会。修改后要保存并确认当前启用的正是刚才编辑的 Config。
PROXY、DIRECT、REJECT 是常见策略。PROXY 将请求交给指定策略或当前代理路径，DIRECT 直接连接，REJECT 拒绝请求。若规则末尾引用的是自定义策略组名称，该名称必须与配置中的定义一致；拼写、大小写或名称不一致都可能导致结果偏离预期。
FINAL 是兜底规则，应放在规则列表末尾。它处理前面所有规则均未命中的请求。排查时先找目标请求命中了哪一条规则，再确认该条规则的策略，不要只看 FINAL。新增规则后，应以少量明确域名进行验证，避免一次改动过多而失去判断依据。
03 / SUBSCRIBE
Subscribe 用于读取用户已有的订阅信息并更新服务器列表；Add Server、Scan QR Code 与 Import from Cloud JSON 用于按不同来源添加已有信息。导入只是把数据写入客户端，实际可用性仍取决于信息本身、网络状态和服务端配置。
从 Home 进入服务器列表后，可使用 Add Server 手动录入，也可根据已有资料选择 Subscribe、Scan QR Code 或 Import from Cloud JSON。手动添加时，协议类型、服务器地址、端口、认证字段和额外参数必须与原始资料一致。常见协议名称包括 Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard 与 Hysteria2。
对于 Subscribe，先核对链接是否完整，再保存并执行更新。更新完成后应查看列表是否发生预期变化，并选择一项执行 Connectivity Test。测试结果只能作为当前时刻的连通性参考，不能单独代表持续使用体验。
订阅更新可能改变服务器名称、排序或现有条目。更新前可先记住当前选中项，更新后重新确认 Home 中的选择。若列表没有变化，依次检查链接是否完整、当前网络是否能访问该地址、订阅是否仍然有效，以及客户端是否显示了明确错误。
多份来源同时存在时，建议使用可辨认的分组与备注，避免重名条目造成误选。删除旧条目前先确认它是否仍被策略组或 Config 引用。服务器信息通常包含敏感字段，展示 Diagnostics、截图或配置片段前应先移除地址、认证内容和完整订阅链接。
04 / ON DEMAND
On Demand 用于根据已设置的网络条件决定是否建立连接。它适合在明确知道触发条件和例外条件时使用。启用前应先完成一次手动连接测试，确认服务器、Global Routing、规则与 DNS 在普通连接下能够正常工作。
在 Settings 中进入 On Demand，按照界面提供的网络条件添加规则。可用条件以当前应用界面显示为准。先从单一、容易验证的条件开始：保存后切换一次对应网络，观察系统连接状态，再逐步增加其他条件。这样能区分是触发条件没有命中，还是连接建立后发生了网络问题。
On Demand 决定“何时尝试连接”，Global Routing 决定“连接后怎样处理请求”，两者职责不同。修改 Global Routing 不会自动改变 On Demand 条件；反过来，On Demand 成功触发也不能证明当前规则、DNS 和服务器一定可用。
05 / DATA
Data 用于查看 Shadowrocket 记录的流量信息，适合辅助判断哪些连接产生了数据、当前会话是否持续传输，以及不同统计周期之间的变化。它是客户端侧观察工具，不应直接当作服务账单或运营商计费依据。
从应用中的 Data 进入统计视图后，先确认界面显示的统计范围和时间区间，再比较上传与下载。若刚建立连接但数据始终没有变化，可同时检查目标应用是否产生请求、系统连接是否仍在、规则是否将请求交给预期策略。仅看到流量增加，也不能证明目标内容已经完整加载。
排查某次异常时，应先记录开始时刻，再复现一次问题，然后对照 Data 与 Diagnostics。这样比观察累计数字更容易定位。若执行清理或重置，应先记录需要保留的信息；具体清理入口和统计口径以当前界面文字为准。
06 / SETTINGS
Settings 集中放置 DNS、Test Method、Today Widget、iCloud 与 Diagnostics 等项目。这些设置会影响解析、测试、系统入口、同步和排查方式。调整前应记录原状态，每次只修改一类设置，并在相同网络条件下复测。
是什么：DNS 负责把域名转换为网络地址。解析结果会影响后续域名规则、地址规则和连接目标，因此 DNS 异常常表现为域名打不开、部分请求超时，或同一地址在不同网络下结果不同。
在哪里与怎么设：从 Settings 进入 DNS 相关项目，同时检查当前 Config 的 General 段是否另有 DNS 设置。优先保持一套来源明确、能够解释的设置，不要同时叠加多组互相矛盾的解析安排。修改后应分别测试域名访问与直接地址连通。
注意什么：如果 Direct 可以访问而 Config 异常，或服务器测试可达但域名访问失败，应重点检查 DNS 与规则之间的关系。切换 Wi-Fi 和蜂窝网络后结果不同，也应记录各自的解析表现再判断。
是什么：Test Method 决定 Connectivity Test 使用什么方式判断连通性。测试值反映特定测试目标与方法下的响应，不等于应用加载、视频传输或长连接的完整体验。
在哪里与怎么设：在 Settings 中找到 Test Method，选择界面当前提供的方法。比较多台服务器时应保持同一 Test Method、同一网络和相近时间，避免把测试条件变化误认为服务器差异。
注意什么：一次超时不宜直接下结论。可以重复测试并结合实际访问、Data 与 Diagnostics 判断。若所有服务器同时异常，先检查本地网络、DNS 与订阅信息，而不是逐个修改服务器参数。
是什么：Today Widget 是系统小组件相关入口，用于在系统允许的区域查看 Shadowrocket 提供的快捷信息或操作。具体可用内容以系统和应用界面显示为准。
在哪里与怎么设：先在 Settings 检查 Today Widget 相关选项，再到系统的小组件编辑区域添加 Shadowrocket。添加后确认组件能读取当前状态，并测试点击行为是否进入预期页面。
注意什么：小组件显示可能受到系统刷新节奏影响，不应仅凭短时间未更新就判断连接失效。需要确认实时状态时，应回到 Shadowrocket 的 Home、Data 或系统连接状态查看。
是什么：iCloud 相关功能用于在符合条件的 Apple 设备之间保存或同步应用数据。它适合用于迁移和恢复，但同步结果仍取决于设备登录状态、iCloud 可用性以及应用当前提供的同步范围。
在哪里与怎么设：在 Settings 检查 iCloud 选项，并确认设备使用预期的 Apple 账户。启用前先整理重复服务器和旧配置；另一台设备完成同步后，核对 Config、服务器名称与当前选择，而不是直接假定两端完全一致。
注意什么：同步冲突时先保留来源明确、时间较新的数据，再逐项核对。配置中可能含服务器地址和认证字段，应按照敏感数据管理，不要把完整同步内容直接展示在公开页面。
是什么：Diagnostics 用于收集连接、解析与请求处理过程中的诊断信息。它的作用是帮助定位失败发生在哪一层，而不是自动替用户修复配置。
在哪里与怎么设：从 Settings 进入 Diagnostics，在复现问题前记下时间、网络类型、Global Routing 姿态和当前服务器。随后只复现一次目标问题，再查看相邻时段的错误、DNS 结果和规则处理信息。
注意什么：分享诊断内容前，应移除完整订阅地址、服务器地址、认证字段、设备标识和与问题无关的访问记录。诊断时保持改动最少，修改一项后重新复现，才能建立设置与结果之间的对应关系。
07 / WORKFLOW
推荐顺序是：先确认本地网络，再检查服务器信息，然后验证 Global Routing，随后检查规则与 DNS，最后启用 On Demand、Today Widget 和 iCloud 等辅助功能。每完成一层都进行一次明确测试。
确认 Subscribe 链接或服务器字段完整，协议类型与原始资料一致。
选择目标服务器，使用统一 Test Method 执行 Connectivity Test。
先用 Config 测试，再通过 Proxy 与 Direct 区分规则和本地网络问题。
查找首条命中规则，确认策略、FINAL 位置和 DNS 设置来源。
手动连接稳定后再配置 On Demand，并从单一触发条件开始验证。
结合 Data 和 Diagnostics 记录时间、网络、姿态与实际结果。