· 场景配置 · 约 8 分钟

小火箭分流设置:只让指定网站走代理的规则配置方法

以 FINAL,DIRECT 兜底,再用 DOMAIN-SUFFIX 列出需要代理的网站,配合 Global Routing 的 Config 姿态完成按网站分流,并给出验证方法。

本文速览

本文适合已经在 Shadowrocket（小火箭）中配置好自有服务商连接、希望仅让少数网站使用代理的用户。操作重点是保留一份可恢复的配置，建立域名允许清单，将 FINAL,DIRECT 放在规则末尾，再切换 Global Routing → Config。完成后，分别检查目标网站和清单外网站的新连接记录，确认匹配规则与实际策略，而不是只凭网页能否打开判断分流是否正确。

一、先确定默认直连的边界

“只让指定网站走代理”是一种默认直连策略：列出的域名命中代理规则，其他连接交给 FINAL,DIRECT。它只按配置中的规则匹配，不会根据页面内容或用户所在地区自动分类。没有列出的登录域名、图片域名与 API 域名，也会按其各自匹配结果处理。

本文以用户已有自己的服务商与订阅为前提。客户端买断 ≠ 线路套餐；规则只选择连接路径，不会生成可用的服务端地址、凭据或线路。开始前应确认 Home 中已有可用连接，并明确当前选中的连接供哪个代理策略使用。

2 类结果
清单内匹配代理，清单外默认 DIRECT
1 条兜底
FINAL,DIRECT 位于规则列表末尾
2 组检查
目标域名与清单外域名分别验证

二、Global Routing 应选择 Config

Home → Global Routing 决定当前连接如何使用配置。编辑了域名规则却仍停留在 Proxy 或 Direct，是分流结果与预期不符的常见原因。本场景应选择 Config，让连接按当前生效配置中的规则处理。

Config

推荐

使用当前配置的规则决定策略。将域名代理规则写在前面、FINAL,DIRECT 写在末尾，才能表达本文的默认直连方案。

适合：只让清单内的网站走代理。

Proxy

对接管的连接采用代理路由，而不是按本文的域名清单逐条分流。可以临时用于对照检查代理路径，但不能作为分流已经生效的证据。

适合：短时确认目标是否可经代理访问。

Direct

对接管的连接采用直连路由。即使 Config 内写有域名代理规则，也不能据此期待这些规则在此姿态下完成分流。

适合：对照检查当前网络的直连可达性。

Scene

依据已配置的场景条件决定路由行为。它不是按网站分流的同义选项；若要使用，应另行核对场景定义及其实际选择结果。

适合：已有明确场景切换需求的配置。

Settings → On Demand 处理按需连接条件，不负责定义某个网站使用哪个策略。为避免排查时同时改变多个因素，先保持现有 On Demand 设置，在连接已开启的状态下验证 Config 规则，再单独检查按需连接是否符合日常需求。

三、写出最小域名规则

以下使用保留的示例域名说明语法，不是可直接用于验证代理服务的目标。把它们替换为实际需要代理的域名后，再写入当前配置的 [Rule] 段。已有配置包含该段时，只修改段内规则，不要重复增加多个同名段落。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,login.example.net,PROXY
FINAL,DIRECT

PROXY 表示代理策略；使用前应核对当前配置对此策略的解析以及 Home 中选择的连接。若现有配置使用自定义策略组，应改为配置内真实存在、且确实选择代理出口的策略组名，不能随意写一个名称期待自动创建。策略组若当前选中 DIRECT，域名规则命中该组后仍可能直连。

规则匹配范围检查重点
DOMAIN-SUFFIX,example.com,PROXYexample.com 及其子域名包含 www.example.com，但不包含 otherexample.com
DOMAIN,login.example.net,PROXY仅 login.example.net不覆盖 example.net 或其他子域名
FINAL,DIRECT此前均未命中的连接放在末尾，保留默认直连

域名字段不写 https://、路径、查询参数或端口。例如网站地址中的 /account 不是 DOMAIN-SUFFIX 的匹配内容；连接使用 TCP 443 也不会让域名规则只匹配 HTTPS。此类规则按主机名选择路径，不能只代理同一域名中的某一个网页。

四、保存配置并应用到连接

在 Config 编辑的文件与当前生效文件必须一致。建议先备份原配置，再使用一份用途明确的本地配置进行测试。若原配置由远程内容维护，应先确认后续更新是否会覆盖本地修改，避免本次验证正确、下次更新后又恢复旧规则。

  1. 记录原配置

    进入 Config，确认当前生效配置并保留原文件备份。记录原来的 Global Routing 选择，方便测试结束后恢复。

  2. 编辑规则

    在 Config 打开准备使用的本地配置进行编辑，在 [Rule] 段写入实际域名规则。检查前方是否已有冲突项，将 FINAL,DIRECT 放在所有需要检查的规则之后。

  3. 保存并选用

    保存文件，回到 Config 确认选用的是刚编辑的配置，而不是同名远程文件或另一份备份。若出现解析错误，先修正规则字段及策略名称。

  4. 设置路由

    回到 Home → Global Routing → Config，检查当前代理连接或策略组的实际出口，然后开启连接。系统若要求添加 VPN 配置，按系统提示完成授权。

  5. 新建连接

    保存后重新发起目标请求；为排除旧连接复用，可停止并重新开启连接，再重新打开目标页面。随后查看新的连接记录核对命中规则。

Home 中更新 Subscribe 主要用于刷新已有服务商的连接信息，不等于在 Config 中切换规则文件。遇到服务端地址更新时，应同时确认代理策略仍能选到可用连接；遇到分流变化时，则优先确认生效配置及规则顺序。两类问题需要分别定位。

五、用连接记录验证分流

验证至少需要一个清单内域名和一个清单外域名。请选用自己实际可访问、用途明确的网站；文中的 example.com 只承担语法示例作用。每次测试都应查看本次新产生的连接记录，核对域名、匹配规则、最终策略以及必要时的策略组出口。

测试对象预期匹配通过依据
清单内主域名对应 DOMAIN-SUFFIX 或 DOMAIN记录显示代理策略，并选择有效代理出口
清单内子域名对应 DOMAIN-SUFFIX确认后缀覆盖，而非误由 FINAL 处理
清单外域名FINAL最终策略为 DIRECT
登录或静态资源域名由该域名自己的规则决定按实际需要补充规则后重新验证

网页能打开只说明某条可用路径完成了请求，不能证明它使用代理。反过来，网页打不开也可能来自 DNS、服务端不可达、登录状态或远端限制，并不一定是 DOMAIN-SUFFIX 写错。先确定是否命中预期规则，再检查策略出口是否可用，最后查看页面依赖域名，能够减少无关修改。

六、常见现象与修正顺序

排查时每次只修改一个变量，并保留修改前后的记录。优先按“路由姿态 → 生效配置 → 规则顺序 → 策略出口 → 网站依赖”的顺序检查。不要为了修复单个登录请求，直接把整个默认策略改成代理，否则原本的清单模式已经改变。

规则写好了，为什么所有网站都走代理？

先检查 Home → Global Routing 是否为 Config，再看当前生效文件末尾是否确为 FINAL,DIRECT。若这两项正确，检查前方是否存在覆盖范围更大的代理规则或规则集，并用清单外域名的新连接确认实际命中项。

主站能打开，为什么登录或图片还是失败？

重新触发失败操作，查看新增连接中的登录、API 或资源域名。若它们不属于已列出的后缀，应根据实际需求补充 DOMAIN 或 DOMAIN-SUFFIX。不要仅凭域名看起来相似就扩大到无关的整段后缀。

命中了代理规则，为什么记录里仍是直连？

检查规则引用的策略组及当前选择。策略组可能指向 DIRECT，或者所观察的记录来自修改前保留的连接。确认出口后重建连接，再检查规则、策略组和最终出口三者是否一致。

能不能只让某个 App 中的网站走代理？

本文的规则以目标域名为对象，不按发起请求的 App 区分。同一域名被其他 App 请求时也可能命中相同规则。若需求只是某个 App 内的一个页面，先确认它是否使用独立域名，不能用 URL 路径代替域名规则。

更新后分流失效，应该重新导入订阅吗？

先进入 Config 核对生效文件及 [Rule] 段是否被替换，再检查 Global Routing。仅当 Home 中的连接信息确实过期或失效时才处理 Subscribe 更新；规则被覆盖与连接凭据变化不是同一问题。

最终验收应同时满足三项：目标域名命中指定代理规则、清单外域名命中 FINAL,DIRECT、代理策略确实使用预期出口。日后增加网站时，只追加必要的域名范围，并重复这套双向检查；这样可以维持默认直连的边界，而不是逐步变成范围不明的混合配置。

前往 App Store