Shadowrocket 功能与设置

在 Home 找到 Global Routing，进入后查看 Config、Proxy、Direct。选择前先确认 Home 的 SERVER 区域已有你自己的可用服务器，且当前使用的 Config 内容符合预期。切换路由姿态不会替你添加服务器，也不会修改原有规则；它改变的是请求经过规则判断的方式。需要长期按域名、地址分别处理时，先从 Config 开始，再核对实际命中的规则。

一次排查只改一个变量：先记录原来的姿态，再切换到 Proxy 或 Direct 做对照，完成后切回 Config。若 Config 与 Proxy 的结果不同，应查看规则是否把目标交给了 DIRECT、REJECT，或命中了与预期不同的策略；若两者都无法连接，则应先检查服务器信息、当前网络和连接状态。界面显示为已连接，只表示系统连接已经建立，不等于每个目标都走了相同路径。

规则分流位于 Config：条件描述要匹配的请求，末尾的策略描述匹配后如何处理。常见策略有 PROXY（使用所选代理服务器）、DIRECT（直接连接）和 REJECT（拒绝请求）。Global Routing 设为 Config 时，才适合按这套规则观察结果。编辑前先确认当前启用的是哪份配置；改动另一份未启用的配置，不会改变当前连接的处理方式。

域名规则中，DOMAIN 匹配指定域名，DOMAIN-SUFFIX 匹配指定后缀，DOMAIN-KEYWORD 按域名中的关键词匹配。地址规则中，IP-CIDR 与 IP-CIDR6 分别用于相应的地址段；GEOIP 使用地址归属信息，匹配结果依赖解析和地址信息。USER-AGENT 按请求标识匹配，但并非每个请求都能提供适用的标识。选择规则类型时，应以实际能够观察到的目标信息为依据，而不是把域名写法直接当成地址写法使用。

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

这些是解释语法的示例，不代表适合直接覆盖你的现有配置。规则按配置中的匹配逻辑工作，较具体的条件应与兜底策略配合检查；FINAL 是前面的规则未命中时采用的最终策略。若把 FINAL 改为 DIRECT，未被前面规则处理的请求就会采用直连；若设为 PROXY，则需确保所选服务器可用。修改后先用少量已知目标验证，再逐步扩大使用范围。目标行为不符合预期时，优先查命中的条件与策略，不要同时大幅改动规则、DNS 和服务器。

服务器条目记录连接所需的类型、地址及认证等参数；订阅则用于导入并更新一组由你的服务商提供的服务器信息。它们与路由规则是两个层面：有规则但没有可用服务器，PROXY 策略无法按预期工作；有服务器但选择了 Direct，也不能据此判断服务器是否正常。在 Home 的 SERVER 区域查看当前选中的条目，再根据手中已有的信息决定手动添加还是导入订阅。

手动填写时，进入 Add Server，选择与你已有资料一致的类型，再逐项核对地址、端口和认证字段。界面可能提供 Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard、Hysteria2 等类型；协议名称应与服务商给出的信息一致，不能仅靠更改类型使一组参数自动适配另一种协议。保存后返回 SERVER，明确选中要使用的条目，再进行连接检查。

已有订阅链接时，可在相应的 Subscribe 导入入口填写从你的服务商处取得的地址。订阅更新用于重新读取服务商提供的内容，不等于保证其中每个条目都能连通。更新前后可核对条目名称与当前选中项，避免误把列表变化理解为应用已经自动选好服务器。若导入失败，先核对链接是否完整、当前网络是否可访问订阅地址，以及服务商提供的链接是否仍有效；不要在公开页面粘贴含访问凭据的完整地址。

管理多条服务器时，给自己的使用记录留一个可辨认的名称，并区分“条目已存在”“条目已选中”“请求已按规则交给该条目”这三个状态。Connectivity Test 可辅助观察连接表现，但一次测试的结果会受当前网络、测试目标和测试方式影响。出现异常时，把所选条目、路由姿态和测试方式一起记录下来，比反复切换大量设置更容易定位问题。

On Demand 用于依据设定的网络条件决定何时建立连接，适合需要在不同网络环境间切换的使用方式。它处理的是“何时连接”，不是“连接后每条请求走哪条规则”；后者仍需结合 Global Routing 与 Config 检查。先在应用内找到 On Demand 的设置入口，阅读当前界面给出的条件选项，再根据自己实际使用的网络环境配置。界面选项以所安装应用内显示为准。

设置前先手动连接一次，确认所选服务器与当前规则在常用网络下工作正常。然后只加入你能明确验证的条件，例如针对熟悉的网络环境决定连接行为。完成后分别在对应网络环境下观察 Home 的连接状态，并检查请求是否仍按预期分流。如果条件没有触发，应先检查设备当前使用的网络是否确实符合该条件，再看系统 VPN 配置权限与应用内的 On Demand 开关。

需要暂时排查连接问题时，可以先停用 On Demand，改用 Home 手动开关复现；这样能将自动触发条件与服务器、规则问题分开。恢复自动连接后再测试一次网络切换，不要只凭先前的手动连接结果判断条件已经生效。持续连接和按需连接的取舍取决于使用场景，Data 中观察到的流量变化也应结合实际连接时段理解。

Data 用于查看 Shadowrocket 记录的连接相关流量信息。在应用的 Data 页面查看统计时，先辨认界面显示的是当前连接、某段时间还是其他汇总口径，再核对对应的上传与下载数值。它可帮助你观察某次操作后客户端处理的流量是否变化，但不应直接当作服务商的计费记录；两边统计的范围、时间窗口和计算口径可能不同。

比较前后变化时，建议先记下当前显示值，再进行单一操作，例如打开一个已知目标，随后回到 Data 查看增量。若数值没有按预期变化，先确认 Home 的连接状态、Global Routing 是否为 Config，以及目标是否命中了 DIRECT 或 REJECT。走 DIRECT 的请求与经所选服务器处理的请求不能简单等同。切换服务器或网络后也应重新确认统计所对应的时间与连接范围，避免用不同条件下的数值直接推断某条规则是否生效。

Data 更适合做使用观察，不适合单独诊断协议参数。想确认服务器连通性，应结合 Connectivity Test 与 Diagnostics；想确认分流路径，应回到 Config 核对规则和策略。将这几处信息合在一起，才能解释“已有流量但目标仍打不开”或“连接正常但统计变化不明显”等现象。

DNS：先确定解析从哪里发生

DNS 负责把域名解析成地址，相关选项可在 Settings 或当前 Config 的对应设置中查看。系统 DNS、自定义 DNS 与 DNS over HTTPS 的区别在于解析服务及传输方式；选择前先确认当前配置是否已经指定解析项，避免同时修改多个位置后无法判断是哪一项影响了结果。若在 Config 中编辑 DNS，具体字段写法应以应用内支持的配置格式为准。更改后用一个已知域名测试解析与连接；域名访问异常而直接使用已知地址时表现不同，才有理由优先检查 DNS。不要把所有连接失败都归因于解析。

Test Method：理解测试结果的范围

Test Method 决定连通性测试采用的方式，可在 Settings 中查看当前选择，并结合 Home 的 Connectivity Test 使用。测试通过表示该方法下的检查获得了响应，不保证所有目标和所有协议场景都相同；测试未通过也需要结合当前网络、目标和服务器信息分析。比较两条服务器时先保持 Test Method 一致，避免因测试方式改变而把结果误认为服务器性能变化。完成测试后再用实际要访问的目标验证规则路径。

Today Widget：查看入口，不代替状态核对

Today Widget 是系统提供的便捷入口；在 Settings 中确认应用内相关设置后，还需按设备系统界面的提示管理小组件。小组件能帮助查看或操作连接，但最终状态仍应以 Home 显示及实际连接检查为准。如果小组件显示与预期不同，先打开应用确认当前选中的 SERVER、Global Routing 和连接开关，而不是仅依据桌面上的一次显示判断规则已生效。系统界面和可用操作可能随设备环境变化，应以当前设备显示为准。

iCloud 同步：辨认同步内容与当前启用项

iCloud 同步相关选项可从 Settings 查找，用于在符合条件的 Apple 设备间管理应用支持的同步数据。启用前先在原设备确认需要保留的配置，并注意订阅地址、服务器认证信息属于敏感资料。同步完成后，应在目标设备逐项检查配置是否出现、当前启用的是哪份 Config，以及 SERVER 里选中的是哪条服务器；“数据已出现”不等于“当前连接已使用该数据”。同步范围、可用性与系统要求以应用内选项及 App Store 页面标注为准。

Diagnostics：按现象缩小范围

Diagnostics 用于辅助检查连接相关问题，可在 Settings 中查找对应入口。使用时先记录问题发生的网络、所选服务器、Global Routing 姿态和目标，再查看诊断信息。若 Home 无法建立连接，先查服务器参数与系统 VPN 配置权限；若连接已建立但特定域名异常，优先查 DNS、规则命中与 FINAL；若只有 On Demand 场景异常，则先用手动连接排除服务器问题。诊断内容可能涉及地址或配置细节，向他人求助前应移除个人凭据。

当多个功能一起使用时，按依赖关系检查，比在各页面之间反复试开关更有效。先确认已有服务器或订阅信息已正确导入，在 Home 的 SERVER 里选中目标条目；随后确认 Global Routing 是要按规则运行的 Config，还是用于短时对照的 Proxy、Direct。只有这两项前提明确，后续观察才有参照。

1. 在 Home 核对连接状态与所选 SERVER；若连接不能建立，先检查服务器信息和系统 VPN 配置权限。
2. 需要分流时，把 Global Routing 设为 Config，检查具体规则的条件、策略和 FINAL，并用少量已知目标验证。
3. 特定域名异常时，检查 DNS 与规则命中；测试服务器时固定 Test Method，并对照 Connectivity Test 的结果。
4. 手动使用正常后，再验证 On Demand 的触发条件；观察 Data 时保持统计口径和测试时段一致。
5. 使用 iCloud 同步或 Today Widget 后，返回 Home 核对当前启用的配置与实际连接状态；必要时再查看 Diagnostics。

每完成一项改动就验证一次，并记下原设置，便于回退。若还没有完成首次导入与连接，可先按教程建立最小可用配置；若需要核对应用来源、开发者与应用 ID，请查看App Store 正版核对说明。本页描述的入口和选项以实际应用内文案为准。