Shadowrocket 功能与常用设置

Global Routing：选择流量处理模式

Global Routing 决定连接启用后，流量是交给配置中的规则判断，还是主要使用统一的 Proxy 或 Direct 路径。它不等同于服务器选择，也不等同于 Home 的连接开关。先在 Home 找到 Global Routing，确认当前选项，再根据目的选择 Config、Proxy 或 Direct。

日常需要分流时，通常使用 Config。操作前先到 Config 确认实际启用的文件，而不是只确认文件已经导入。文件存在与正在使用是两个状态；编辑了未启用的文件，当前连接行为不会因此自动按该文件变化。

出现某个目标访问异常时，可以保留原设置记录，再用 Proxy 与 Config 做短时对照。如果 Proxy 可访问而 Config 不可访问，接下来应查看该请求的规则命中与策略去向；这只是排查线索，不是对故障原因的最终判定。测试结束后恢复所需模式，避免把临时排查姿态留作日常配置。

规则分流：条件、顺序与策略

规则分流是把请求的域名、目标地址等信息与规则逐条比较，再交给对应策略处理。在 Config 中打开当前使用的配置，检查规则列表；Global Routing 选择 Config 时，这份配置才是分流检查的主要对象。修改前先保留原文件，避免覆盖后失去可对照的基线。

每条规则通常由类型、匹配内容、策略组成。规则从上往下判断，第一条命中后停止继续匹配。因此，某个域名的特殊例外应放在覆盖它的范围规则之前，FINAL 通常放在末尾接住此前没有匹配的请求。规则数量多，并不意味着优先级合理。

PROXY 表示交给代理路径，DIRECT 表示直接连接目标，REJECT 表示拒绝请求。规则也可能引用配置内定义的策略组名称，这时还要继续确认组内当前选择，而不能只看规则末尾的文字。以下片段仅展示排列关系，example.com 是说明用域名，不应整段替换用户已有配置。

DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,10.0.0.0/8,DIRECT
FINAL,PROXY

这段示例把精确例外放在后缀规则之前，否则 ads.example.com 会先被较宽的规则接住。排查时先定位实际命中的规则，再决定是否调整顺序；不要只在末尾追加一条希望生效的规则。完整原理见规则匹配顺序与 FINAL 说明。

Subscribe 与服务器管理

服务器记录保存具体连接参数，Subscribe 用于根据用户已有订阅维护一组服务器；Config 则主要承载规则及相关配置。这三者有关联，但不是同一种内容。已有链接应按其实际类型导入，不能因为同样是网址，就把配置地址与订阅地址互换使用。

在 Home 使用添加入口进入 Add Server，按已有信息选择 Type。手动添加时，逐项核对 Address、Port 和协议所需的认证字段；例如 Trojan 与 Shadowsocks 所需字段并不完全相同。参数必须与服务器端一致，不能靠更换 Type 来修复一份不匹配的参数。需要了解字段含义时，可查阅协议技术参考。

导入已有订阅时，在 Add Server 的 Type 中选择 Subscribe，并在 URL 等对应字段填入自己的订阅信息。保存后返回 Home，确认订阅下的服务器列表已出现，再选择所需记录。若使用 Scan QR Code，应先核对识别出的内容类型与来源，保存后仍需检查参数，而不是把扫码成功等同于连接成功。

更新订阅会重新获取列表内容，适合处理服务方已经调整的地址或参数。更新后应复核当前所选服务器是否仍然存在、名称是否变化，以及原有策略是否还引用有效记录。对订阅生成的记录直接做临时编辑，后续更新可能覆盖这些改动；重要调整应先确认配置的保存方式。

Connectivity Test 可帮助比较当前测试条件下各记录的响应情况，但结果受 Test Method、测试目标、网络与服务器状态共同影响。列表中有响应，不代表所有目标都可访问；没有响应，也应先确认测试方式是否适用于当前服务，再决定是否修改服务器参数。

On Demand：按条件触发连接

On Demand 负责在符合设定条件时让系统发起 VPN 连接。它回答的是“何时建立连接”，而不是“某个域名应该使用什么策略”。连接建立后，流量如何处理仍取决于 Global Routing 与当前 Config，不能把 On Demand 当作另一套分流规则。

先在 Home 手动完成一次连接验证，确认已有服务器和配置正常，再进入 Settings 查找 On Demand。按实际界面提供的网络条件逐项设置；若配置中涉及 Wi-Fi 名称等条件，应核对拼写，并确认设备确实连接到了对应网络。不要在手动连接尚未成功时同时加入多个自动触发条件，否则不易判断问题发生在哪一层。

设置后可通过切换实际使用的网络环境，观察系统是否按预期建立连接，并回到 Home 核对连接状态。测试既要覆盖“应该触发”的情况，也要覆盖“不应该触发”的情况；仅在当前 Wi-Fi 下测试一次，无法证明其他网络条件也配置正确。

如果原本计划停止连接，却发现它再次出现，应先检查 On Demand 是否仍启用以及触发条件是否满足。需要暂时停止自动行为时，先关闭相关触发，再检查连接开关。系统对网络切换、后台活动的处理也会影响观察结果，因此不应承诺在所有环境下都以同样时机触发。

Data：查看流量与请求线索

Data 用于查看应用记录的流量统计与可用的请求信息。它适合回答“连接期间是否有数据经过”“某次测试前后记录有何变化”等问题，不是服务方计费账单，也不是完整的速度测试。统计口径、保留范围与界面显示应以设备上的实际选项为准。

进入 Data 后，先看统计范围、时间和可用分类，再进行一次单一目标的访问测试。对照测试前后的变化，比仅观察一个累计数字更有意义。若界面提供连接详情或请求记录，可结合域名、目标地址及策略信息确认处理路径；字段缺失时，不应凭空推断请求一定走了某条规则。

需要重新观察时，可先记录必要信息，再使用界面提供的重置或清理操作。清理统计与更改服务器参数不是一回事，也不会自动修正错误规则。测试期间尽量减少其他应用的后台活动，以免累计数据混入更新、同步等流量，影响判断。

Data 中出现数据增长，只说明记录范围内存在传输，不代表目标业务已经成功；应用可能仍处在重试或下载其他资源。相反，某次测试没有明显变化，也可能与连接状态、当前模式或统计范围有关。排查时应同时核对 Home、Global Routing 与实际访问结果，而不是只根据统计数字作结论。

Settings：常用选项的设置边界

Settings 主要提供应用级选项、测试偏好、同步与辅助工具；Config 中也可能保存与解析、连接有关的设置。修改前先判断参数属于应用级还是配置级，记录原值，并保留当前启用文件。界面未显示的项目不要按其他教程中的位置强行寻找，应以设备实际提供的入口为准。

DNS：先确认解析设置的来源

DNS 把域名转换为地址，是连接前的重要环节。先在 Settings 查看相关入口，再检查当前 Config 中是否指定 DNS；不要假设修改一处就覆盖了所有配置。设置时使用自己确认可用的解析服务与应用支持的写法，保存后重新测试同一个域名。若刚改过解析设置，应考虑缓存影响，必要时按界面提供的方式清理后复测。

域名解析成功不等于后续连接成功。遇到域名失败而地址连接表现不同的情况，可以把 DNS 作为排查方向；但直接替换为目标地址可能改变 TLS 校验和请求行为，不能把这种对照当作长期解决方案。也不建议在同一次测试中同时调整 DNS、Global Routing 和协议字段。

Test Method：统一测试方式再比较

Test Method 决定 Connectivity Test 使用的测试方法。进入 Settings 找到该项，按当前界面提供的选项选择，并核对相关测试目标。不同方法检查的连接阶段不同，因此结果不能直接混为一组比较。更改方法后，应重新测试需要对照的记录，而不是将新结果与旧列表中的结果直接排序判断。

测试目标能响应，仅证明所选方法对应的链路环节有响应，不能保证所有应用与网站都正常。排查时保留“方法、目标、网络环境”三个条件，使用真实业务访问补充验证，不把某一个响应数值作为服务质量或稳定性的承诺。

Today Widget：用于便捷查看与操作

Today Widget 提供系统小组件相关的便捷入口。先在 Settings 检查应用提供的相关选项，再到系统的小组件编辑界面确认是否能够添加，以及当前设备提供哪些操作。系统版本和组件支持情况可能影响展示，具体以设备界面为准。

组件用于减少进入应用的操作，不替代配置检查。通过组件执行连接操作后，若状态显示与预期不一致，应回到 Home 核对，并检查 On Demand 是否正在参与连接触发。不要仅凭组件上一次显示的状态判断当前连接已经建立。

iCloud：同步前先保留配置副本

iCloud 相关选项用于在符合条件的设备间同步应用支持的内容。进入 Settings 查看 iCloud 设置，同时确认系统已允许 Shadowrocket 使用 iCloud。首次启用前，先备份重要 Config，并记录当前选中的服务器和模式；同步范围以界面说明为准，不应假定所有临时状态、统计和凭据都被完整同步。

换机后先等待内容同步，再逐项确认文件、服务器与策略引用。同步不是连接验证，也不等于历史记录完整恢复。两台设备同时编辑同一份配置时，应检查保存结果，避免用较早内容覆盖已调整的规则。具体迁移顺序可参考配置备份与迁移说明。

Diagnostics：围绕一次明确的故障取证

Diagnostics 用于获取应用提供的诊断信息。进入 Settings 查找该入口，按实际界面选择需要的诊断方式。先记下故障发生时的网络、Global Routing、所选服务器与操作步骤，再复现一次问题，通常比收集长时间、混合多种操作的记录更容易定位。

诊断结果是分析线索，不是自动修复。分享前检查是否包含订阅 URL、服务器地址、账号信息或访问目标，并进行脱敏；不要直接公开整份记录。完成排查后恢复临时调整的记录选项，按需清理不再使用的诊断资料。

常用设置的检查顺序

配置较多时，按固定顺序核对能减少重复改动。建议先保留可恢复的基线，再一次只改变一个变量；每次保存后使用相同目标验证，并记下结果。这样可以区分参数错误、规则去向和自动触发条件之间的差异。

1. 确认输入内容。在 Home 检查当前服务器，核对已有订阅是否完成更新，手动记录的 Type、Address、Port 与认证参数是否一致。
2. 确认处理模式。在 Global Routing 查看当前选项；使用 Config 时，进入 Config 确认真正启用的文件，再检查策略引用与 FINAL。
3. 完成手动验证。开启连接并访问一个明确目标；结合 Data 与可用记录查看结果，不将 Connectivity Test 单独视为成功标准。
4. 再调整辅助设置。需要时逐项核对 DNS、Test Method 与 Diagnostics，保留原值，避免同时修改多个连接环节。
5. 最后启用自动行为。手动连接验证完成后，再配置 On Demand、Today Widget 和 iCloud，并分别测试触发、操作与同步结果。

如果仍无法确定问题属于哪一层，先阅读疑难解答；首次使用尚未完成导入与授权时，应从快速上手开始，而不是先调整大量高级选项。保留一份已验证可用的配置，通常比不断叠加临时修改更便于后续维护。