Shadowrocket配置与规则分流

Rules 用来决定请求采用哪一种策略。使用前先在 Home 的 Global Routing 选择 Config，再进入 Config 核对当前启用的文件。规则通常按顺序匹配，具体域名应放在宽泛条件之前；DOMAIN-SUFFIX 对应域名后缀，IP-CIDR 对应地址范围。PROXY、DIRECT、REJECT 是不同处理方式，FINAL 用来处理前面未命中的请求。修改后应通过实际访问与记录核对结果，不要仅凭服务器延迟判断分流是否正确。

配置姿态 Config 按当前文件的规则处理请求；代理姿态 Proxy 与直连姿态 Direct 适合对照排查。测试结束后确认是否需要切回 Config，避免把临时测试状态当作长期配置。

On Demand 用于根据设定条件管理连接，入口在 Settings。建议先用手动开关完成一次正常连接，确认已有服务器和 Config 都能使用，再检查按需连接条件。设置时区分 Wi-Fi、蜂窝网络及具体网络条件，避免把连接触发条件与请求分流规则混为一谈。若发现关闭后又重新连接，应回到 On Demand 检查条件，并核对系统中的 VPN 状态。调整后分别测试网络切换与重新进入应用的结果，每次只改一项，便于确认原因。

On Demand 解决何时连接；Rules 解决连接后如何处理请求。右侧规则说明局域网地址采用 DIRECT，并不代表已经设置某个 Wi-Fi 下自动连接。

Shadowrocket 支持 Shadowsocks、VMess、VLESS、Trojan、WireGuard 等协议。手动添加时从 Add Server 的 Type 开始，随后按用户已有服务器资料核对地址、端口、认证信息与相关传输设置。不同协议的字段不能直接互换，启用 TLS 时还应检查名称与资料是否一致。遇到失败先确认字段和协议对应关系，再看连接记录；不能只改一个协议名称就期待原信息继续可用。具体可选项以当前应用界面为准，规则中的 PROXY 也不代表某个固定协议。

协议描述客户端怎样连接服务器，策略描述请求走向。先让服务器信息可用，再检查该请求是否命中 PROXY；把 DIRECT 改成 PROXY 不会补全缺失的认证字段。

Subscribe 适合管理用户已经持有的订阅信息。导入前确认链接来自自己的服务商，复制完整内容，避免把说明页面地址当成订阅地址。导入后先查看分组与服务器条目，再选中其中一项进行测试；更新订阅只是重新获取其内容，不等于当前 Config 的规则同步变化。多个订阅应使用可辨认的名称，清理重复条目前先确认来源，手动保存的信息也要单独备份。链接可能含有个人凭据，提交故障描述时应遮去完整地址和认证内容。

服务器条目更新后，仍需确认当前选中项；Config 则决定规则与相关设置。右侧示例是规则文件内容，并不是订阅地址，也不能用它生成服务器信息。

Config 管理规则及相关配置。先确认当前启用的文件，再打开编辑页面核对 General、Rule 等分段；保留原文件副本后再修改，避免覆盖可用设置。使用 iCloud 同步时，应检查自己的 iCloud 状态与应用中的同步设置，并在另一台设备上核对实际到达的内容，不把同步当作连接成功的保证。服务器资料、配置文件和购买记录属于不同层次，恢复其中一项不代表另外两项已恢复。若要定位问题，先回到已知可用的配置，再逐项加入改动。

编辑完成后确认保存成功，并返回检查当前选中的 Config。文件存在于列表中，不代表它已参与当前请求处理；同时还需确认 Global Routing 使用 Config。

Connectivity Test 用于检查服务器连接表现，Settings 中的 Diagnostics 可辅助定位故障，Data 则用于查看应用记录的流量情况。测试有结果并不等于所有网页请求都正常，仍需分别检查 DNS、规则命中与目标连接。建议记下出现问题时使用的网络、Global Routing 姿态和当前服务器，再复现一次请求。比较记录前尽量保持其他条件一致；Data 的统计范围以界面说明为准，不应直接代替服务商的用量记录。对外提供记录前应移除个人域名、地址与凭据。

先确认设备网络，再核对服务器字段、DNS 与规则。右侧片段可用来理解特定域名与最终策略的区别，不应在尚未确认问题所在时直接覆盖原有配置。