本文适合已经在 Shadowrocket 中添加自己的连接资料、想确认 Global Routing 应该如何选择的用户。Config、Proxy、Direct、Scene 是四种不同的路由姿态：Config 按配置规则分流，Proxy 与 Direct 用于统一指定流量去向，Scene 则依据已设置的场景工作。下文提供设置入口、选择方法、验证步骤和恢复思路；测试时请固定连接与网络，一次只改变一个条件。
四种 Global Routing 模式：先看流量如何决定去向
Shadowrocket（小火箭）的 Global Routing 用来决定交给应用处理的流量怎样选择出站路径。它不是服务器列表，也不是连接开关。Home 中选中了某个连接资料，只能说明当前选定对象；最终请求是按规则、统一代理、直连还是场景条件处理，还要看 Global Routing 当前选项。
四种模式中，日常按规则分流通常从 Config 开始。它会结合当前生效配置中的规则选择策略，例如命中 DIRECT 的请求走直连，命中 PROXY 的请求走代理路径；如果配置使用策略组，则还要看策略组当前选择。没有命中前序规则时，结果取决于配置末尾的 FINAL 等兜底规则，不能默认所有未匹配请求都会直连或代理。
| 模式 | 请求去向 | 适合用途 | 优先核对 |
|---|---|---|---|
Config | 依据当前配置中的规则与策略决定 | 日常按目标分流 | 当前启用的配置、规则顺序、策略组与 FINAL |
Proxy | 将受处理的流量统一交给代理路径 | 短时对照代理路径是否可用 | Home 中选定的连接、连接状态及目标可访问性 |
Direct | 将受处理的流量按直连路径处理 | 检查本地网络直连情况 | 当前网络是否能直接访问目标 |
Scene | 按当前已配置的场景行为处理 | 已有场景配置并需要按条件切换 | 场景选择、场景条件及对应行为 |
特别要区分两个同名词：Home 的 Global Routing 选项 Config，是路由姿态；底部或侧边的 Config 页面，则用于管理配置文件。进入 Config 页面并不会自动启用 Config 路由姿态；反过来，选择 Config 姿态也不代表选中了正确的配置文件。排查时应分别记下这两项。
结论：先确认要验证的是规则还是连接
要检查规则有没有把不同目标分流到预期策略，使用 Config 并确认配置文件；要暂时对照统一代理路径或直连路径，再短时切换 Proxy 或 Direct。Scene 只适合已知场景行为的用户，不应仅凭名称猜测它当前会怎样处理请求。
按使用目标选择：日常分流、临时排查与场景切换
选择模式前，先写清本次要回答的问题。若问题是“某个域名有没有命中规则”，应固定连接与网络，在 Config 下检查规则；若问题是“当前代理连接能否访问目标”，可用 Proxy 做短时对照；若要判断目标在当前网络能否直连，则使用 Direct。一次测试同时改变模式、服务器和 Wi-Fi，会让结果难以归因。
根据任务选姿态：日常使用与故障对照
日常按规则使用
- 选择 Global Routing → Config。
- 在配置管理页面确认当前启用的文件。
- 核对目标域名对应的规则与策略组。
- 检查未匹配请求由哪条兜底规则处理。
临时定位流量问题
- 保持同一个连接和测试目标不变。
- 用 Proxy 检查统一代理路径，再用 Direct 检查直连路径。
- 每次切换后发起新的请求，不沿用旧页面连接。
- 定位完成后恢复原来的日常姿态。
Proxy 与 Direct 是对照手段，不是永久替代规则核验的方法；恢复时以原先记录的 Global Routing 选项为准。
Config 更适合作为已配置规则用户的常用选择，但前提是配置确实符合预期。规则通常按配置中的顺序判断，较宽泛的规则若排在具体例外之前，可能先匹配请求。遇到“某个站点没按预期走”时，不要先把整个模式改成 Proxy；先查该目标的请求记录、规则顺序、策略组选择及 FINAL。
Proxy 可以帮助区分“规则选择错误”与“代理路径本身不可用”。如果 Config 下某个请求失败，而 Proxy 下同一目标成功，问题可能与规则匹配或策略选择有关；但这只是定位线索，不足以证明配置中的所有规则都有问题。若 Proxy 下也失败，还应检查连接状态、已有连接资料、网络状况和目标服务响应。
Direct 适合在短时间内检查直连条件。Direct 下不能访问某个目标，并不自动说明 Shadowrocket 配置损坏；目标可能要求不同网络路径，或当前网络本身无法完成连接。测试结束后若忘记切回 Config，原有规则仍在配置里，却不会按预期参与当前流量选择，这是“规则看起来不生效”的常见原因之一。
Scene 不是一个可以脱离配置解释的固定策略。它的实际行为取决于当前选择的场景及其条件和设置；不同场景可能对应不同的处理安排。启用前先进入相关场景设置，确认场景名称、触发条件和预期路由，再通过相同目标做一次新请求验证。如果并未设置或不了解场景内容，先不要把 Scene 当作默认的自动分流模式。
设置入口与操作步骤：保存选择后立即验证
在 iPhone 或 iPad 上，先打开 Shadowrocket 的 Home 页面，找到 Global Routing 并选择目标模式。具体控件外观可能随界面版本或设备布局变化；以页面上显示的英文项目为准，不要把服务器条目选择误当作路由模式。选择后返回 Home，再确认当前显示的模式与预期一致。
-
记录原状态
在 Home 记下当前 Global Routing、选中的连接资料，以及当前使用 Wi-Fi 还是蜂窝网络。若准备检查规则，再到 Config 页面确认实际启用的配置文件。
-
选定测试目标
准备一个自己平时会访问、结果容易判断的目标。测试期间不要同时更新订阅、切换连接资料或更换网络，以免测试条件发生变化。
-
切换路由姿态
返回 Home → Global Routing，选择 Config、Proxy、Direct 或已配置的 Scene。选择 Config 时，确认配置文件也已启用；选择 Scene 时，先核对对应场景设置。
-
发起新请求
切换后重新打开目标页面或应用，产生一个新的连接请求。已有长连接可能继续沿用先前路径，因此不要只观察切换前已打开的页面。
-
核对请求结果
结合 Home 的连接状态与 Data 中可查看的连接记录或流量变化，检查请求是否按预期完成。记录模式、目标、网络和结果，再决定是否继续调整。
连接开关与 Global Routing 也要分别理解。连接开关控制是否建立或维持 VPN 连接；Global Routing 选择连接建立后请求如何处理。Direct 不等于关闭连接，选择 Proxy 也不能替代连接资料和系统 VPN 授权。测试前若连接尚未建立，先按平时方式启动连接并确认系统状态，再比较路由结果。
有些应用会复用已建立的连接，切换模式后旧会话不会立刻产生新请求。建议关闭并重新打开测试页面，或选择一个能明确触发新加载的操作；不需要为了一次排查删除配置或重置所有设置。若使用 Scene，除新建请求外，还要确认触发场景的条件已经满足，否则观察到的仍可能是另一个场景的行为。
模式不符合预期时：按顺序排查并恢复
如果目标流量没有按预期分流，先不要连续切换四种模式。把当前状态与测试条件记录下来，依次检查路由姿态、配置文件、规则或场景、连接状态和新请求结果。每次只调整一项，才能判断哪一项变化带来了不同结果。
- 先看模式：Home 的 Global Routing 是否确实显示预期选项。若误停在 Direct，Config 中的域名规则不会按日常方式决定当前请求去向。
- 再看配置：选 Config 时确认启用的是正确文件，而不是只确认文件已经导入。检查相关规则是否存在、排列是否合理，以及对应策略组是否选对。
- 核对兜底：若请求没有命中具体规则，查看
FINAL等末尾处理方式。不要把“没有找到目标域名规则”直接等同于“应用会自动代理”。 - 检查新连接：重新发起请求，并结合连接记录判断是否产生了新的访问。只刷新界面或观察旧会话，未必能验证新模式。
- 恢复原选择：完成对照后回到 Home → Global Routing，按开始测试时记录的模式恢复；若改动过配置或场景条件，也恢复相应原值。
为什么选了 Config，规则还是没生效？
先确认 Home 当前显示 Config，再到配置管理页面确认实际启用文件。随后检查目标规则、策略组与 FINAL，并重新发起请求；Config 姿态不会自动替你选中正确文件。
切到 Direct 后 VPN 图标还在，正常吗？
可能正常。Direct 表示受处理流量使用直连路径，不等于关闭 VPN 连接开关。分别核对系统连接状态与新请求的处理结果，不要只凭状态栏图标判断流量去向。
选了 Scene，但行为和预期不同怎么办？
进入场景相关设置，确认当前选中的场景、触发条件和对应行为；再满足条件并发起新请求。若暂时无法确认场景设置，恢复到已知的 Config 或原先记录的模式后再排查。
如果测试中改动了不熟悉的规则，不要继续叠加新规则。先恢复记录的原文或重新启用先前确认过的配置，再核实 Global Routing；若只为定位问题临时选择 Proxy 或 Direct，直接恢复开始时的路由姿态即可。需要长期调整时，每次只改一个明确目标，保存后在相同网络、相同连接和相同目标下复测。
选择模式的实用原则是：已有规则并希望按目标分流时先核对 Config；需要短时区分代理路径与直连路径时用 Proxy、Direct 做对照；只有理解并设置了场景条件时才使用 Scene。检查路由姿态、配置文件和连接状态这三项，通常比反复切换模式更容易找到原因。