Shadowrocket配置文件语法深度解析：规则、分流与实战配置

想自己维护 Shadowrocket 配置文件，重点不是记住几条规则，而是分清各个配置段的职责、确认规则按什么顺序生效，并在每次修改后验证实际命中结果。下面以可阅读、可逐步调整的 `.conf` 片段说明语法；示例中的域名和远程地址均为占位内容，不能直接当作可用订阅或规则来源。

本文速览

本文适合已在 Shadowrocket 中导入自己的订阅、准备检查或维护 `.conf` 配置的用户。你将看到配置段的基本结构、常见规则字段、规则优先级和 RULE-SET 的使用边界，并按“备份 → 小幅修改 → 确认 Global Routing → 检查请求结果”的顺序验证。配置文件只描述客户端如何处理连接，不会提供服务器或线路服务。

一、先看懂 .conf：配置段、键值与规则行

Shadowrocket 的 `.conf` 配置采用分段组织的文本结构。方括号中的名称标记一个配置段，例如 `[General]`、`[Rule]`；段内再放置对应的参数或规则行。它和订阅中的服务器列表不是同一类数据：订阅主要提供连接条目，配置文件可以管理 DNS、规则、策略组及其他设置。一个配置文件可能包含服务器参数，但不能据此认定它与 Home 中的订阅列表、更新来源和所有本机设置完全等价。

编辑前先在 Config 中确认当前使用的是哪份文件，并保留原文件副本。打开文件操作菜单，使用当前界面提供的 Edit Config 或导出入口；菜单名称和位置可能因版本而异。修改远程来源关联的配置前尤其要谨慎：重新获取远程内容可能覆盖本地改动。订阅链接、密码、UUID 和带 token 的 URL 都属于敏感信息，分享配置片段前应先脱敏。

[General]

常见全局参数所在段，例如 DNS 设置

[Rule]

按条件匹配目标并指定处理策略

3 个字段

常见规则的类型、匹配值与策略

下面的片段用于说明段落位置，不是完整配置，也没有提供任何连接服务。若原文件已有同名段落，应在原段中检查或调整对应内容，不要重复创建多个同名段落，也不要用几行示例覆盖整份配置。

[General]
dns-server = system

[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

规则行通常由逗号分隔字段。以上示例里，`DOMAIN-SUFFIX` 是规则类型，`example.com` 是匹配范围，`DIRECT` 是匹配后采用的策略；`GEOIP` 行按目标 IP 的地理数据库分类匹配；`FINAL` 则为前面规则均未命中时提供兜底策略。具体参数是否可用，还要结合 Shadowrocket 当前支持的语法和配置中定义的策略核对。

二、常见规则字段：匹配范围决定影响面

写规则时先问“我要匹配什么”，再决定策略。域名规则不匹配网页路径；IP 规则针对地址或网段；按 GeoIP 分类的规则依赖 IP 信息，而不是网页语言、域名后缀或设备所在地。匹配条件越宽，影响范围通常越大，因此建议先从明确、较窄的条件开始验证。

规则类型	匹配范围示例	编辑时检查
`DOMAIN`	只匹配一个完整域名，例如 `api.example.com`。	域名字段不写协议头、路径或查询参数。
`DOMAIN-SUFFIX`	匹配指定后缀域名及其子域名，例如 `example.com`。	范围比单个主机更宽；不要误以为只匹配一个网页。
`IP-CIDR`	匹配 IPv4 地址段，例如文档保留示例 `192.0.2.0/24`。	共享地址段可能承载多个服务；确认地址范围和 IPv4 / IPv6 情况。
`GEOIP`	按目标 IP 所属地区代码分类，例如 `CN`。	分类依据是 IP 数据，不代表按域名后缀判断。
`FINAL`	处理前面的规则均未匹配的请求。	通常放在普通规则之后；策略应符合自己的兜底需求。

例如，`DOMAIN-SUFFIX,example.com,DIRECT` 会覆盖 `example.com` 及其子域名；如果只有一个子域名需要单独处理，先考虑 `DOMAIN` 这样的精确匹配。`IP-CIDR,192.0.2.0/24,DIRECT,no-resolve` 中的 `no-resolve` 是附加选项，涉及是否为该 IP 规则主动触发域名解析；不要把它理解为“忽略所有 DNS”或“保证规则命中”。

策略字段也必须有对应对象。`DIRECT`、`PROXY`、`REJECT` 是常见处理策略名称；如果规则指向某个自定义策略组，配置中还必须存在名称一致的策略定义。拼写不一致、策略组被删除或引用了不存在的名称，都可能导致规则不能按预期工作。不要仅凭文本看起来完整，就推断实际连接已经走了预期路径。

三、规则优先级与分流：第一条匹配规则决定结果

在 Global Routing 采用 Config 的情况下，配置中的规则按顺序检查，先匹配到的规则决定该请求采用的策略。后面的规则不会自动覆盖前面已经命中的结果。因此，较具体的例外规则通常要放在范围较宽的规则之前，`FINAL` 兜底规则则应留给前面规则都未匹配的请求。

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

在这段示例中，`api.example.com` 会先匹配第一行，采用 `PROXY`；同一主域名下其他符合后缀条件的域名会匹配第二行，采用 `DIRECT`。如果把两行调换，第一条较宽的 `DOMAIN-SUFFIX` 可能先接住目标，精确规则就没有机会生效。实际配置还要检查规则是否指向策略组，以及该策略组当前的选择。

两种操作目标：日常分流与定位规则问题

日常使用

Home → Global Routing 选择 Config。
确认当前启用的 Config 文件。
检查具体规则与 FINAL 的策略。
保留原有配置中的必要策略组。

临时排查

记录当前 Global Routing 状态。
固定一个域名和当前网络环境。
一次只调整一条规则再复测。
结束后恢复原来的路由设置。

只有在 Config 路由下，才能用当前配置的规则解释对应分流；切换路由姿态会改变排查条件。

Config 页面负责管理配置文件，而 Home → Global Routing → Config 表示按当前配置的规则处理流量，两者不是同一项操作。导入文件后要确认它确实是当前使用的配置；选择了文件，也不代表 Home 的连接开关已经打开或当前服务器选择正确。排查时应把文件、路由姿态、连接状态和目标域名分开核对。

四、RULE-SET：远程规则集怎么理解与验证

RULE-SET 用于让规则引用规则集，而不是把每条匹配规则都手工写在主配置中。常见的表达形式会包含规则集来源和应用策略，例如下面的结构示意。远程 URL 和规则内容均为虚构占位符，不能直接访问或导入；使用前应确认当前 Shadowrocket 版本支持的语法、远程文件格式和字段要求。

[Rule]
RULE-SET,https://rules.example.net/sample.list,PROXY
DOMAIN,api.example.com,DIRECT
FINAL,PROXY

远程规则集相当于外部内容进入本地分流逻辑的一条路径。来源维护者可以修改规则内容，链接失效、响应格式变化或规则集顺序变化，也可能改变命中结果。不要为了“补全规则”随意复制陌生 URL；优先使用自己已经核验、理解其用途且能确认维护来源的规则文件。规则集应按实际语法放在适当位置，并检查它与其余规则、策略组及 `FINAL` 的先后关系。

备份当前文件

在 Config 中确认当前配置并导出副本。记录原有 RULE-SET、普通规则和兜底策略，避免修改后无法恢复。
核验规则来源

确认规则集由自己信任的来源提供，检查文件内容、更新方式和引用策略。不要公开包含访问 token 的 URL。
只加一条引用

在现有 [Rule] 段加入一条测试规则，不覆盖其他规则；按当前支持的语法核对字段数量、分隔符和策略名称。
确认路由姿态

回到 Home → Global Routing，确认测试时采用 Config；同时确认当前配置文件和连接状态，避免用不同条件比较结果。
测试后再扩展

用一个明确的目标域名发起新请求，检查请求记录或规则匹配信息（若当前界面提供），确认命中规则与策略后再扩大使用范围。

如果界面没有显示足够的规则命中信息，可以用单变量方法验证：先记录目标域名、网络和当前策略；临时添加一条针对该域名的精确规则；保存后重新连接并发起新的请求，再比较结果。测试应尽量使用新连接，因为已有连接可能沿用先前建立的状态。确认后删除测试规则或恢复备份，避免把诊断用配置长期留在主配置中。

规则核对

路由姿态: Home → Global Routing → Config
配置文件: 确认实际启用的文件
匹配顺序: 精确例外在较宽规则之前
兜底策略: 检查 FINAL 及其引用策略

验证时固定同一目标、网络和连接条件。

RULE-SET 核对

来源: 确认来源可信且内容可检查
语法: 对照当前支持的字段格式
顺序: 检查与普通规则、FINAL 的相对位置
策略: 确认引用对象确实存在

规则集更新可能改变结果，重要修改先保留旧版本副本。

五、证书、远程脚本与安全边界

配置文件可能含有比规则更敏感的内容，包括服务器参数、订阅 URL、访问凭据、证书设置和脚本引用。不要把完整 `.conf` 上传到公开位置求助，也不要在截图中暴露 token、密码或 UUID。确需排查时，只提供已经脱敏且足以说明问题的局部段落。

证书相关设置尤其需要谨慎。证书配置或 HTTPS 解密功能可能让客户端在特定条件下检查加密流量；这不只是“让某个网站能打开”的普通开关。只有在明确理解用途、信任证书来源并知道如何撤销的情况下，才考虑启用相关功能。不要安装来历不明的证书，也不要为了排错长期保留不必要的解密设置；涉及金融、医疗、工作账户等敏感连接时，更应避免扩大检查范围。

远程脚本具有执行配置逻辑的能力，远程内容变化会带来额外风险。只引用自己能核验来源、用途和更新方式的脚本；不清楚脚本会读取或修改什么时，不要启用。一个配置文件能成功加载，不等于其脚本或远程规则可信。对远程内容保留来源记录和可回滚副本，修改后检查实际变化，而不是只看文件名或备注。

为什么把 RULE-SET 加进去后，看起来没有变化？

先确认 Home → Global Routing 当前是 Config，再检查该规则集的来源、语法、所在位置和引用策略。发起新的目标请求，并查看当前界面提供的请求或匹配信息；不要仅凭连接延迟判断规则已经命中。

我把规则放到最后，为什么还是没按它走？

前面可能已有更宽的规则先匹配，也可能当前使用的不是 Config，或规则引用的策略不存在。先核对顺序和策略名称，再用一条精确规则做单变量测试。

可以直接复制网上的 .conf 吗？

不要在不了解来源和内容时直接覆盖当前配置。先保存原文件，再逐段检查规则、策略组、证书与脚本引用；对不认识的远程地址和敏感权限保持关闭，确认必要性后再逐项测试。

配置文件里有 FINAL，是不是所有流量都会按它走？

不是。`FINAL` 处理的是前面的规则均未命中的请求；已被前序规则接住的请求不会再由它改写。还要确认当前采用 Config，并检查前序规则实际指向的策略。

维护配置的稳妥顺序是先备份，再确认当前文件和 Global Routing，接着小幅修改、固定条件测试，最后清理临时规则并确认安全设置。若需要核对 Shadowrocket 的其他配置入口，可查看订阅手册；客户端下载与购买信息应以 App Store 页面为准。客户端买断 ≠ 线路套餐，已有订阅应从你的服务商处获取。