Shadowrocket（小火箭）的 Home → Global Routing 用来选择当前连接的流量处理方式：Config 按当前配置中的规则分流，Proxy 采用代理姿态，Direct 采用直连姿态，Scene 则按已设置的场景工作。本文从日常浏览、临时全局代理和规则分流等需求出发，说明怎么选择、如何验证，以及测试后如何恢复原设置。操作以用户已有自己的连接配置为前提。
先分清四种 Global Routing 姿态
Global Routing 是连接建立后决定流量如何处理的路由选择，不负责创建服务器条目，也不负责导入订阅。开始设置前，先在 Home 确认当前选中的服务器和连接状态；如果选择 Config，还要到 Config 页面核对正在使用的配置文件。服务器条目、配置文件与路由姿态是不同对象，三者都要符合预期。
| 选项 | 处理方式 | 适合用途 | 检查重点 |
|---|---|---|---|
Config | 按当前配置中的 Rule 等设置处理请求。 | 日常使用规则分流，让不同请求按规则选择代理或直连。 | 确认选中了正确的 Config，Rule 中有目标规则和合适的兜底项。 |
Proxy | 采用代理姿态处理流量，而不是按 Config 的 Rule 逐条分流。 | 短时间检查代理路径，或明确需要整体走代理的场景。 | 确认 Home 中选中的代理可用；不要把它当成规则分流模式。 |
Direct | 采用直连姿态，不经所选代理转发目标请求。 | 对照测试当前网络直连是否可用，或需要整体直连的场景。 | 直连失败可能来自本地网络或目标站点，不等同于代理故障。 |
Scene | 按已设置的场景选择相应处理方式。 | 已经配置并理解场景条件，且需要按场景切换行为时。 | 检查场景内容与条件；不能只凭名称推断流量一定走代理或直连。 |
如果目标是“部分网站走代理，其余网站直连”，通常应选择 Config，并在当前配置的 Rule 中写明各自策略。选择 Proxy 并不会自动读取每一条域名规则来实现这种精细分流；选择 Direct 也不会在直连失败时自动回退到代理。Scene 的具体行为取决于场景本身，设置尚未确认时，不适合作为排查基线。
先核对的页面
- 路由入口
- Home → Global Routing
- 配置文件
- Config 页面确认当前选中的文件
- 连接对象
- Home → SERVER 确认当前选中的条目
Config 负责规则来源，Global Routing 负责当前采用的路由姿态。
两条常见 Rule
- 指定域名
- DOMAIN-SUFFIX,example.com,PROXY
- 其余请求
- FINAL,DIRECT
- 规则顺序
- 具体规则在前，FINAL 在末尾
示例域名只说明格式；规则须与当前配置中的策略名称相符。
选择建议：先明确要控制的范围
只想测试某个代理出口时，可短时选择 Proxy；希望按照域名或 IP 规则区分流量时，选择 Config；要建立直连对照时，选择 Direct。测试结束后回到原有姿态，避免把临时排查状态误当作日常设置。
按日常需求选择模式
日常浏览通常需要兼顾可访问性与流量路径，因此判断重点不是哪个选项名称更简单，而是当前配置是否已经写好要使用的规则。若配置有明确的代理规则、直连规则和兜底规则，选 Config 能保留这些区别。若配置文件为空、选错文件或 Rule 并不包含预期规则，选中 Config 也不会自动生成分流策略。
- 日常规则分流：选择
Config，检查当前配置文件和 Rule 顺序。把具体域名规则放在宽泛规则前面，并确认FINAL的策略符合预期。 - 临时整体代理测试：选择
Proxy，再用同一目标测试。这个结果可用于和 Config 或 Direct 做对照，但不代表所有应用请求在各种系统网络条件下都必然成功。 - 检查本地网络直连：选择
Direct，访问一个当前网络通常可达的目标。若失败，先检查 Wi-Fi、蜂窝网络、网络认证和目标站点，不要只凭这一项判定服务器有问题。 - 按已设场景切换：选择
Scene前，先读懂场景所关联的条件和动作。场景中的规则或选择若改变，实际效果也可能不同；记录现有内容，避免测试期间同时改动多个条件。
例如，配置中写有 DOMAIN-SUFFIX,example.com,PROXY 和 FINAL,DIRECT，这两条规则表达的是指定域名代理、其余请求直连的意图。若 Global Routing 当前选中 Proxy 或 Direct，就不能把测试结果直接解释为上述两条 Rule 的逐条匹配结果。判断规则是否生效，应回到 Config，并结合请求记录或实际目标逐项核对。
同一个网站也可能调用独立域名加载图片、登录接口或其他资源。页面能打开不一定代表所有请求都使用了相同策略；页面打不开也不一定是主域名那条规则写错。验证时记录具体目标、当前姿态和所用网络，尽量使用相同目标进行比较。
按步骤切换并验证
开始前记下当前 Global Routing 选项、当前选中的 SERVER 条目，以及 Config 页面选中的文件名称。若当前连接状态正常，也可记录一个已知能够访问的目标作为基线。每次只改变路由姿态，不要同时改规则、更新订阅和替换服务器，否则出现变化时难以判断原因。
-
记录原设置
在 Home 查看当前 Global Routing 选项和 SERVER 选择；若使用 Config，再到 Config 记下当前文件。保留这些信息，作为测试后的恢复依据。
-
选择目标姿态
进入 Home → Global Routing，按测试目的选择 Config、Proxy 或 Direct。只有已确认场景配置时才选择 Scene；不要同时调整其他路由条件。
-
确认连接状态
回到 Home 查看连接开关状态。若断开，按已有配置正常连接；首次连接时按系统提示允许添加 VPN 配置。连接状态与网页能否访问是两个分别需要验证的结果。
-
测试同一目标
使用相同网络和目标地址进行访问，并记录页面结果。若使用 Connectivity Test，也记录测试方式；延迟或连通结果不能单独证明目标域名解析、TLS 握手和网页请求都成功。
-
恢复原有模式
完成对照后，回到 Home → Global Routing，重新选择开始前记录的姿态。若测试中改过配置或场景，也一并恢复已记录的原值，再用日常目标复核。
切换后若结果没有立刻变化，可确认当前连接状态，并在安全可行时断开后重新连接再测试。不要在不了解后果时删除系统 VPN 配置，也不要把清除全部网络设置作为常规恢复步骤。Settings → On Demand 若启用了按需条件，还应留意系统可能按条件自动建立连接；手动测试时记录这一状态，避免把自动触发误认为 Global Routing 切换失败。
模式选对了仍无法访问时
路由姿态只是整个访问路径中的一环。出现“连接已打开但网页失败”时，先区分是所有目标都失败，还是某一域名失败；再看 Config、SERVER、DNS 与当前网络。不要因单个网页打不开就直接把所有 Rule 改为代理，也不要因 Connectivity Test 有响应就认定网站访问链路正常。
选了 Config，指定网站还是直连？
确认 Home → Global Routing 确实为 Config，再到 Config 检查当前文件是否选中、Rule 是否包含目标域名，以及策略名称是否写对。检查规则顺序，尤其确认目标规则没有排在会先匹配的宽泛规则之后。
选了 Proxy，网页仍然打不开？
确认 Home → SERVER 选中的是已有的目标条目，并检查连接状态。随后用同一目标和当前网络复测；如果只有某一域名失败，继续检查 DNS、目标站点与相关请求，不要仅凭 Proxy 姿态认定问题一定在规则。
切回 Config 后行为和以前不同？
核对 Config 页面当前选中的文件，以及测试时是否改过 Rule、FINAL 或 Scene。若存在备份，先恢复已知可用的原文件，再逐项比较差异；不要用一份只含示例规则的片段覆盖完整配置。
排查顺序：固定条件，再比较结果
保持服务器、网络、目标域名不变，先比较路由姿态，再按结果检查配置规则、DNS 或连接状态。一次只改一项并在完成后恢复原值，能减少误把临时状态留作日常设置的情况。
Shadowrocket 的客户端连接能力与用户已有的线路配置是两回事；改变 Global Routing 不会生成服务器条目，也不会修复失效的连接参数。日常使用前确认 Home 中的连接对象、Config 中的规则文件和 Global Routing 姿态彼此一致。需要进一步核对首次连接、配置导入或规则基础时，可查看快速上手与代理模式说明。