本文适合已经在 Shadowrocket（小火箭）中添加连接配置、但还不确定 Global Routing 应该选什么的用户。先区分 Config 的按规则处理、Proxy 的统一代理与 Direct 的统一直连，再按固定步骤核对新请求的实际去向。日常使用通常从 Config 开始；Proxy 和 Direct 用来临时改变路径、隔离故障原因，不能代替服务器参数与规则本身的检查。
一、先分清连接开关、Global Routing 与当前配置
Home 中的连接开关决定是否建立 Shadowrocket 的 VPN 连接，Global Routing 决定接管后的请求如何选择路径；Config 中选用的配置则提供规则等设置。这三项有关联，但不能互相替代。只把 Global Routing 改为 Proxy，并不等于已经打开连接；看到系统 VPN 标记，也不能据此认定每个请求都经过代理服务器。
本文所说的“统一代理”与“统一直连”，指进入 Shadowrocket 处理范围的流量，不是对设备上所有通信的绝对保证。路由排除、局域网设置、DNS 处理和既有连接都可能影响观察结果。切换后应发起新请求核对，而不是只看状态栏。
二、Config、Proxy、Direct 的路径与适用场景
日常需要同时访问直连资源和代理资源时，优先使用 Config，但前提是当前配置的规则符合需求。Config 不等于“部分请求自动直连，其余自动代理”的固定模板；具体域名怎样处理、最终如何兜底，都由实际加载的规则和策略决定。
Config：按当前配置匹配
推荐请求按规则顺序匹配，命中项指定 DIRECT、PROXY 或配置中的其他策略；前面没有命中时，由 FINAL 等兜底设置决定去向。选择 Config 后，还要确认 Config 中启用的是预期文件。
适合：已有明确规则、需要长期按目标分流的日常使用。
Proxy：统一使用代理路径
接管范围内的普通请求统一使用代理路径，不再依靠常规分流规则逐项选择 DIRECT 或 PROXY。仍需有可用的代理服务器；姿态切换不会修正错误的地址、端口或认证信息。
适合：短时验证代理是否可用，或判断失败是否与规则分流有关。
Direct：统一使用直连路径
接管范围内的普通请求不经代理服务器发出。它改变请求的出口选择，并不等于断开 Shadowrocket 的 VPN 连接，也不保证 DNS 等其他处理与关闭连接时完全一致。
适合：核对当前网络直连能力、测试局域网资源或临时排除代理路径影响。
Proxy 与 Direct 更适合作为对照条件，而不是“更快”或“更稳定”的等级。代理路径是否可用取决于服务器与网络；直连是否成功取决于当前网络到目标的连通性。同一个网页在两种姿态下表现不同，是排查线索，不是对整套配置的结论。
三、Config 怎样匹配：从具体规则到 FINAL
在 Config 姿态下，常规规则按配置顺序检查，首条命中决定该请求使用的策略。因此，范围较小的例外通常应放在范围较大的规则之前。下面仅演示规则语法与顺序，不是完整的连接配置；保留地址与示例域名不代表可用服务。
[Rule]
DOMAIN-SUFFIX,intranet.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY| 关键字 | 在示例中的作用 | 检查重点 |
|---|---|---|
DOMAIN-SUFFIX | 匹配指定域名及其子域名。 | intranet.example.com 的例外必须放在更宽泛的 example.com 规则前。 |
IP-CIDR | 按目标 IP 所在网段匹配。 | no-resolve 表示不为这一条匹配主动触发域名解析；已有目标 IP 仍可参与匹配。 |
GEOIP | 按 IP 地理归属数据匹配。 | 归属判断依赖 IP 数据，不能当作域名用途或内容属性的判断。 |
FINAL | 承接前面未命中的请求。 | 示例使用 PROXY，所以不能把 Config 的剩余流量一概理解为直连。 |
域名规则需要可用于匹配的域名信息；只有目标 IP 时，不能期待每条 DOMAIN-SUFFIX 都有机会命中。检查问题时应同时看记录中的目标、规则和最终策略，而不是只在配置文件中搜索一个域名。若规则引用了策略组，还需继续核对策略组当前选中的出口。
四、切换姿态后的验证步骤
验证时只改变一个变量：固定网络、固定目标、固定代理服务器，依次测试 Config、Proxy、Direct。浏览器旧标签页可能继续使用已有连接，页面也可能来自缓存；切换后刷新一次并不足以证明路径已经改变。应结束旧请求、重新发起访问，并检查对应时间的新连接记录。
- 记录起点。在 Home 确认当前服务器和连接状态，在 Config 确认启用文件。记录一个你有权访问的目标及测试时间，避免把不同请求的结果混在一起。
- 先测 Config。进入 Home → Global Routing → Config，发起新访问。在连接记录中核对目标、命中规则与策略；若显示 DIRECT，先判断这是否符合当前规则，而不是马上更换服务器。
- 再测 Proxy。进入 Home → Global Routing → Proxy，保持服务器与目标不变，再发起请求。若此时成功而 Config 失败，应重点检查规则命中、策略组选择和 DNS 差异。
- 最后测 Direct。进入 Home → Global Routing → Direct，重新请求同一目标。若 Direct 成功而 Proxy 失败，检查代理连接参数、服务器状态与代理路径上的解析问题。
- 恢复日常设置。完成对照后回到 Config，并再次确认规则结果。只把能重复出现的现象写入排查记录，不以一次成功或一次超时作最终判断。
普通网页 HTTPS 常使用 TCP 443，HTTP/3 则可能使用 UDP 443；它们是目标服务端口，不是要求你把代理服务器端口改为 443。浏览器可能在不同传输方式之间回退，因此测试延迟成功也不一定代表两条传输路径都正常。服务器端口、协议和认证字段应按你已有配置核对。
两组对照：先查规则，还是先查代理路径
Config 失败，Proxy 成功
- 检查 Config 当前启用的文件是否正确。
- 查找同一目标的新记录，核对命中项和最终策略。
- 检查较宽规则是否提前命中，以及 FINAL 是否符合预期。
Proxy 失败，Direct 成功
- 确认 Home 选中的服务器与测试前一致。
- 核对地址、端口、认证信息与协议相关字段。
- 使用同一网络重试，记录错误类型，避免同时修改 DNS 与规则。
对照结果用于缩小范围；若三种姿态都失败，应回到网络连通性、DNS、目标服务状态与连接记录继续检查。
五、Global Routing 不负责哪些设置
Global Routing 解决“请求选择哪条路径”，不负责生成连接参数，也不负责提供连接服务。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 是协议名称，与 Config、Proxy、Direct 所在的决策层次不同。某个协议配置错误，切换姿态不能补齐缺失字段。
- 订阅导入与更新：订阅从你的服务商处获取。更新主要用于取得服务商发布的连接信息；不要假设更新订阅后，本地正在使用的分流规则和 Global Routing 也会自动变成期望状态。
- On Demand：在 Settings → On Demand 检查自动连接条件。它影响何时触发连接，不等于选择 Config 或保证所有请求走代理。测试手动断开时，应同时留意是否被自动连接条件再次触发。
- DNS：域名解析与出口策略有关联，但不是同一个开关。更改姿态后仍解析失败，应单独检查 DNS 配置，不要只反复切换 Global Routing。
- 客户端购买：客户端买断 ≠ 线路套餐。Shadowrocket 是 Apple 平台的闭源商业应用，唯一获取入口是 App Store；商店价格、系统要求与购买适用范围以 App Store 页面标注为准。
首次连接还需按系统提示允许添加 VPN 配置。这个授权属于系统连接权限，不代表当前代理可达，也不代表规则已经经过验证。先完成授权并确认连接，再按上一节的方法逐项测试，才能区分权限问题、参数问题和分流问题。
六、切换时常见的四个问题
选了 Config，为什么某个网站还是直连？
先在 Config 确认启用文件，再检查该网站新请求的命中规则。可能是 DOMAIN-SUFFIX、GEOIP 或 FINAL 指向 DIRECT，也可能经策略组选择了直连。只看到 Global Routing 显示 Config，并不足以确定网站应该走代理。
改成 Proxy 后能打开，是否说明规则一定写错了？
这说明两种姿态下的路径有差异，但还不能直接判定某一行语法错误。保持同一服务器和网络，再比较 Config 下命中的规则、策略组出口与解析结果。先找到差异，再改具体设置。
Direct 下还有 VPN 标记，是不是没有切换成功？
VPN 标记表示系统隧道仍建立着，不表示出口一定经过代理服务器。Direct 是路由姿态，关闭 Home 连接开关才是断开操作；若断开后又自动连上，再检查 Settings → On Demand。
切换以后旧网页没变化，该怎么确认？
先停止旧页面的请求，再重新发起访问，查看相同时间的新连接记录；必要时断开后重新连接，以排除长连接影响。测试时只改 Global Routing，不同时更换服务器、规则文件和 DNS，避免失去可比较的条件。
日常操作可以归纳为一个顺序：先确认连接与配置，再用 Config 运行；出现异常时，用 Proxy 和 Direct 建立对照；找到问题后恢复 Config，并用新请求验证具体规则。这样保留了分流设置，也能避免把临时排查姿态长期遗留在设备上。