Shadowrocket 自定义规则优先级:从上到下匹配与 FINAL 兜底写法

一、规则优先级：先命中，不是越精确越优先

在按配置分流时，[Rule] 段按从上到下的顺序检查；某条规则匹配成功，就采用该条指定的策略，不再继续寻找后面的“更精确规则”。因此，规则类型本身没有一个能取代行顺序的统一优先级。把 DOMAIN 写在 DOMAIN-SUFFIX 后面，不会使它自动获得更高优先级。

例如，希望 api.example.com 直连，而 example.com 的其他子域名走代理，应先写这个单独域名的例外。下面的域名是说明语法用的示例，不是服务地址或可用性承诺。

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

• 请求 api.example.com：第一行命中，使用 DIRECT。
• 请求 www.example.com：第一行不匹配，第二行命中，使用 PROXY。
• 其他未被前面规则覆盖的请求：由 FINAL,DIRECT 处理。

如果交换前两条规则，api.example.com 也符合较宽的域名后缀条件，会先被 PROXY 接住。排查“明明写了直连却仍走代理”时，首先检查目标规则之前有没有已经覆盖它的规则，而不是继续在末尾追加重复条目。

二、先核对 Global Routing，再编辑 Config

配置文件中写有规则，不等于当前连接一定按这些规则分流。进入 Home → Global Routing 核对当前姿态，再到 Config 确认正在使用的文件。下面只比较本次验证会用到的三个姿态；Scene 用于场景配置，排查本篇规则时先明确选择 Config，减少场景切换带来的变量。

1. 备份配置

   进入 Config，先保存当前文件的副本或导出备份，保留可恢复的原始规则；不要只保存新增的几行。

2. 打开编辑

   在 Config 中打开目标配置的编辑入口，找到 [Rule] 段。确认修改的是配置正文，而不是 Home 中的服务器连接参数。

3. 排列规则

   把单域名例外放在对应的宽泛规则前面，再检查 IP 范围和 GEOIP 条目，末尾保留 FINAL；保存后确认该文件被选用。

4. 核对姿态

   回到 Home → Global Routing → Config，确认已有服务器选择正确，再开启连接；需要系统 VPN 配置授权时按系统提示操作。

5. 发起新请求

   关闭目标页面后重新访问，必要时重新建立连接，避免用旧连接判断新规则。记录目标域名、时间和匹配结果，再做下一次改动。

三、DOMAIN-SUFFIX、IP-CIDR 与 GEOIP 如何排列

规则按什么对象匹配，与它写在第几行是两个问题。域名规则检查主机名，IP 规则检查目的地址，GEOIP 则依据地址数据库分类。域名请求可能解析到多个地址，同一域名也可能随网络环境解析到不同地址；不要把一次 IP 命中当作该域名永久固定的属性。

DOMAIN-SUFFIX 后面应写 example.com，不是带有 https:// 的完整网址，也不是 example.com/path。路径属于 URL 的另一部分；将它粘贴进域名字段，不能表达“只让这个页面走代理”。规则同样不因某个网站使用 HTTPS 的常见端口 443，就自动获得端口匹配条件。

no-resolve 表示不要为了匹配该 IP 规则而额外触发域名解析，并不表示关闭整个配置的 DNS，也不表示这个网段永远不会匹配。请求已经有可用于判断的目的 IP 时，仍可按地址范围判断。若只知道域名、又不希望为该条规则进行解析，应理解跳过解析可能让请求继续向下匹配。

• 先列业务上必须保留的精确例外，再列对应域名后缀；这能避免宽规则提前覆盖例外。
• 仅当确实需要按目的地址区分时加入 IP 网段；/32 是单个 IPv4 地址，/24 覆盖 256 个地址。
• 范围较大的 GEOIP 通常放在明确例外后面，但这是一种便于维护的排列方式，不是客户端强制的类型优先级。
• 若连接直接使用 IP 而没有可用域名，不能指望仅靠 DOMAIN-SUFFIX 匹配它。

四、PROXY、DIRECT、REJECT 与 FINAL 的完整写法

规则末尾的策略决定命中后的动作：PROXY 交给代理路径处理，DIRECT 直接连接目的地，REJECT 拒绝请求。这些动作与服务器协议是不同层次的设置；将已有服务器从 Shadowsocks 换为 Trojan，不会改变规则自上而下匹配的基本顺序。

下面仅是用于讲解的 [Rule] 段，不是可以替代所有现有设置的完整配置。它假定用户已有可用服务器；示例域名不提供任何服务。实际合并前，应检查现有文件中的策略名称、其他规则及所需网络范围。

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

• api.example.com 虽然属于 example.com，但先命中第一条例外，因此直连。
• blocked.example.com 在后缀规则前命中 REJECT；访问失败是该策略的预期结果。
• 192.168.0.0/16 只覆盖这个私有地址范围，不代表所有本地网络；其他范围要按实际需要单独判断。
• GEOIP,CN,DIRECT 依赖目的 IP 的数据库归类，不保证覆盖所有中文网站，也不保证某个域名每次归类相同。
• FINAL,PROXY 只处理此前未命中的请求；它不会把已经命中 DIRECT 的请求改成代理。

将 FINAL 插在规则中间，会提前接住其后的未分类请求，使后面的条目失去预期作用。维护时只在末尾保留一条明确的兜底，避免旧配置中遗留的第二条 FINAL 造成阅读误判。

五、用单变量测试定位规则没有生效的原因

验证顺序应是“当前文件 → 当前姿态 → 请求目标 → 实际匹配 → 连接结果”。网页能打开只能证明一次请求成功，不能单独证明它经过哪条路径；网页打不开也可能是 REJECT、目的服务故障或代理连接问题。应把匹配判断与连接成败分开记录。

1. 建立基线：保持同一个网络、同一个已有服务器和同一个目标，记录修改前表现，避免同时更换服务器与规则。
2. 只改一行：例如仅交换 DOMAIN 与 DOMAIN-SUFFIX 的顺序，保存并确认使用该配置，然后重新发起请求。
3. 检查请求信息：在应用的连接记录或日志中查找本次目标主机、目的 IP 和可见的策略信息；若只看到 IP，先判断是否存在域名信息。
4. 检查完整资源：页面正文、图片和登录接口可能属于不同域名。只为主站加一条规则，不一定覆盖整个页面依赖。
5. 恢复对照：将刚才的改动恢复，再次访问。若表现并不随改动重复变化，继续检查缓存、旧连接和目标服务状态。

订阅更新与配置编辑也要分开处理。Home 中更新用户已有的服务器订阅，主要用于刷新服务器条目；Config 中的远程配置更新则可能替换配置正文。不能把这两类更新都当作“刷新规则”。修改远程配置之前保存本地副本，更新后重新检查例外条目和 FINAL 是否仍然存在。

六、规则顺序与 FINAL 常见问答