本文速览

本文适合已经在 Shadowrocket 中使用自己的订阅、准备把一组规则托管在远程地址的用户。你将看到 RULE-SET 的引用思路、规则顺序如何影响命中、怎样用小范围改动验证配置，以及远程内容未更新或不兼容时的排查办法。示例域名与 URL 均为演示值；实际使用前应替换为自己确认可访问、可信任的规则文件地址。

远程规则集是什么：引用规则，不是订阅服务器

Shadowrocket 的 .conf 可以把具体匹配规则写在本地，也可以在配置中引用远程规则集。远程规则集通常是按约定格式保存的一组规则，由 RULE-SET 行引用其地址，并为这组规则指定策略。这样做便于集中维护多条规则：调整规则内容时，可以更新远程文件，而不必逐条修改本地配置。

远程规则集与 Home 中的连接资料、订阅不是同一类内容。连接资料描述服务器及协议参数；订阅用于导入或更新这些连接条目；RULE-SET 处理的是请求如何匹配并选择策略。导入连接订阅不会自动把某个远程规则集加入当前配置，规则文件更新也不会替换服务器资料。

读取本地配置 加载远程规则 按序匹配请求 应用策略
3 个环节
引用地址、规则内容、策略分别核对
自上而下
先命中的规则决定请求的匹配结果
1 条兜底
FINAL 放在规则末尾处理未命中请求

开始前先在 Config 确认当前选中的配置文件；随后在 Home 检查 Global Routing 是否为 Config。若使用 Proxy 或 Direct，实际请求可能不会按 .conf 中的规则逐条分流。配置文件已导入、远程地址已写入、规则已实际生效，是三个不同状态，应分别验证。

RULE-SET 引用：先核对地址与规则文件格式

RULE-SET 行的作用是引用远程规则内容，并给这组规则指定策略。以下片段展示常见的表达思路，不是可直接使用的真实规则地址。将示例地址换成自己的文件地址后，还要确认 Shadowrocket 当前使用的配置能够解析该写法，并确认远程文件格式符合规则集要求。

[Rule]
DOMAIN,api.example.com,DIRECT
RULE-SET,https://rules.example.invalid/proxy.list,PROXY
DOMAIN-SUFFIX,example.cn,DIRECT
FINAL,PROXY

这里的 example.invalid 是保留作演示的域名，不会提供可用规则。示例意在说明：本地精确规则、远程规则集、其他本地规则和 FINAL 可以共同出现在 [Rule] 中。远程规则集的具体语法与可接受的文件格式，应以当前 Shadowrocket 对应配置解析结果为准；不要把其他工具的规则提供者声明原样当成 Shadowrocket 可识别的格式。

引用行核对

关键字
RULE-SET
地址
确认是可访问的规则文件 URL
策略
使用配置中存在的策略名称
分隔符
字段之间使用半角逗号

保存后回到 Config，确认编辑的是当前启用的文件。

远程文件核对

内容
使用规则集要求的规则格式
响应
检查访问结果不是登录页或错误提示
编码
避免混入不可见字符或中文标点
维护
保留来源与修改记录

可在浏览器或文本查看器检查内容，但能打开网页不等于客户端已成功加载。

规则集文件不能随意混入完整配置段。若文件预期只包含匹配规则，就不要在其中重复写 [General]、[Rule] 等配置段名，也不要在每条规则末尾擅自附加与引用策略冲突的字段。使用前查看规则文件维护者提供的格式说明；若没有说明，先从少量、格式清楚的规则开始验证。

匹配优先级：例外放前面，FINAL 放最后

[Rule] 按顺序检查。对于能够完成判断的请求，先命中的规则决定后续策略；并不会因为后面的规则更具体，就自动推翻已经命中的前序规则。因此，如果某个域名需要特殊处理，应把该例外安排在可能覆盖它的宽泛规则之前。

例如，远程规则集覆盖一批域名并使用 PROXY，而你希望其中的 api.example.com 直连，就应在相关 RULE-SET 行前放置精确规则。若先命中远程规则集，后面的精确规则通常就没有机会处理该请求。检查顺序时，应查看配置最终呈现的规则排列，而不是只看自己最近编辑的那一行。

[Rule]
DOMAIN,api.example.com,DIRECT
RULE-SET,https://rules.example.invalid/proxy.list,PROXY
DOMAIN-SUFFIX,example.cn,DIRECT
FINAL,PROXY

策略名称也要与配置中的可用策略对应。示例中的 PROXY 与 DIRECT 只是常见写法；如果实际配置使用不同的策略组名称，引用行应使用当前配置能够识别的名称。名称不匹配时，即使远程规则内容正常，也可能无法得到预期路由结果。

结论：先找最早命中的规则

出现分流错误时，先从 [Rule] 顶部逐行检查目标请求可能匹配的条目，再确认对应策略是否存在。不要先把规则集整组移到文件末尾；这可能暂时改变现象，却同时破坏其他规则的优先关系。

安全修改与验证：每次只改一处

远程规则集会影响一批请求，不适合在没有备份的情况下直接替换整段配置。先保留当前 .conf 副本，记录 Global Routing、启用的配置文件和已有策略；随后增加一条规则集引用，或只调整一个例外的位置。这样出现变化时，比较容易定位是地址、格式、顺序还是策略造成的。

  1. 备份配置

    在 Config 确认当前启用的文件，并保存原配置副本。记录修改前与修改后的规则行，避免误删原有 FINAL 或策略组引用。

  2. 检查远程内容

    确认 URL 对应的是规则文件而非介绍页，内容可以正常读取，且格式与 RULE-SET 的使用方式相符。地址若要求登录、依赖特殊请求头或返回动态网页，应先确认客户端能否按该方式获取。

  3. 加入引用行

    在 Config 的配置编辑入口中添加 RULE-SET 行，核对半角逗号、URL 和策略名。将需要优先处理的精确例外放在引用行之前。

  4. 保存并启用

    保存后确认当前选中的仍是修改过的文件；在 Home 将 Global Routing 设为 Config，并确认已有可用连接。不要只根据 VPN 状态图标判断规则已生效。

  5. 发起新请求

    重新访问一个明确符合测试规则的目标，必要时关闭并重新打开目标应用，避免旧的长连接继续沿用之前的路径。一次只测试一个目标并记录预期策略与实际结果。

验证时可选一个远程规则集中的域名，再选一个本地例外域名和一个预计落入 FINAL 的目标。三者分别用于确认规则集能否命中、本地顺序是否正确、兜底行为是否符合预期。不要使用包含敏感账户操作的请求做首次测试，也不要把某一网站暂时打不开直接归因于规则集。

更新与故障排查：区分获取失败、解析失败和未命中

远程内容发生变化后，客户端何时重新获取、是否缓存以及更新失败时如何处理，可能受当前配置与应用行为影响。不要假设每次打开页面都会立即拉取最新版，也不要把刷新连接资料等同于刷新远程规则集。修改远程文件后，应按当前界面提供的规则或配置更新操作执行，并再次确认配置已保存、当前选中项正确。

规则集地址能打开，但请求没按预期走？

先确认 Home → Global Routing 为 Config，再查看精确例外、RULE-SET 与 FINAL 的先后顺序。接着核对命中的策略名是否存在，并用新请求复测。

更新远程文件后结果仍像旧规则？

确认客户端执行了当前界面提供的配置或规则更新操作，随后重新建立测试请求。若仍不变，检查实际启用的配置是否引用了该 URL，以及远程地址是否指向刚修改的文件。

RULE-SET 行看起来正确，却没有效果？

逐项检查 URL 可访问性、远程内容格式、半角逗号和策略名称；再尝试用一条本地精确规则验证 Config 路由是否工作。不要一次同时改 URL、规则顺序和策略。

规则只在部分请求上失效？

确认请求实际使用的域名是否在远程集合覆盖范围内，并考虑应用可能使用多个域名或直接连接 IP。选择一个规则明确覆盖的目标进行对照，不要仅凭网站主域名推断所有请求都匹配。

远程文件出现陌生规则或无法读取？

暂停使用该引用，检查文件来源、最近改动及服务器返回内容；必要时恢复备份。只引用自己信任并能持续维护的地址，不要把登录页、错误页或未知内容当作规则文件。

排查可按三类现象记录：获取失败通常指地址不可访问或返回内容不正确；解析失败通常与规则格式、分隔符或策略字段有关；规则未命中则要核对目标是否在集合范围内，以及前面是否已有其他规则命中。把现象分开记录，比反复刷新或移动整段规则更容易找到原因。