Shadowrocket 自定义规则与优先级：自上而下匹配、FINAL 兜底与 PROXY/DIRECT/REJECT 策略

规则优先级的核心：命中第一条后停止

Shadowrocket 的规则列表不是同时计算后再选择“最精确”的一条，而是按照配置中的书写顺序，自上而下逐条检查。某条规则一旦匹配当前请求，后面的规则便不再参与这次判断。因此，优先级由位置决定，不由规则名称、字符长度或策略类型自动决定。

例如，同一个域名既能命中一条精确的 DOMAIN 规则，也能命中覆盖整个后缀的 DOMAIN-SUFFIX 规则。如果 DOMAIN-SUFFIX 写在前面，精确 DOMAIN 即使更具体也不会生效。配置时应把例外项放在宽泛规则之前，把范围最大的兜底项放到最后。

一次典型判断可以拆成五步：应用发起连接；Shadowrocket 获得目标域名或 IP；从 [Rule] 第一行开始检查；遇到首条匹配规则后停止；按照该行末尾的策略处理。若所有具体规则都没有命中，则继续到 FINAL。

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

在这组示例里，访问 api.example.com 时先命中第一行并使用 DIRECT；访问 www.example.com 时第一行不匹配，随后命中 DOMAIN-SUFFIX 并使用 PROXY。目标位于私有地址段 192.168.0.0/16 时使用 DIRECT；其余请求经过 GEOIP 判断后，仍未命中的部分交给 FINAL。

DOMAIN、DOMAIN-SUFFIX、IP-CIDR 与 GEOIP 怎样排序

规则排序应从“范围窄、意图明确”逐步过渡到“范围宽、覆盖面大”。DOMAIN 只匹配一个完整域名，适合设置单独例外；DOMAIN-SUFFIX 会覆盖指定域名及其子域名；IP-CIDR 按地址段匹配；GEOIP 根据目标 IP 的地理数据库分类。FINAL 不检查具体目标，它接收前面所有未命中的请求。

建议采用的排列层级

1. 本地与保留地址：先处理局域网地址和明确需要 DIRECT 的目标，避免内部设备请求进入其他策略。
2. 精确域名：使用 DOMAIN 表达单个主机的特殊处理方式，例如让一个 API 域名覆盖后面的后缀规则。
3. 域名后缀：使用 DOMAIN-SUFFIX 处理一个主域名及其全部子域名。
4. 地址段：使用 IP-CIDR 匹配明确的 IPv4 网段。前缀长度越大，覆盖范围通常越窄。
5. 地理分类：把 GEOIP 放在具体域名与地址规则之后，避免宽泛分类提前截走例外请求。
6. 最终兜底：将 FINAL 放在最后，明确所有剩余流量的处理方式。

DOMAIN-SUFFIX 的值只写域名本身，不要附带 https://、路径或查询参数。规则匹配的是主机名，不是完整网页地址。若需要处理 cdn.example.com，可写 DOMAIN,cdn.example.com,DIRECT；若要覆盖 example.com 及其各级子域名，则写 DOMAIN-SUFFIX,example.com,PROXY。

IP-CIDR 中的前缀长度必须与目标网段相符。以 192.168.0.0/16 为例，它覆盖从 192.168.0.0 到 192.168.255.255 的地址。若误写为 /24，覆盖范围会缩小到单个末级网段，其他同类局域网地址便不会命中。

PROXY、DIRECT 与 REJECT 分别改变什么

规则末尾的策略决定请求命中后如何处理。PROXY 表示交给当前配置指定的代理策略；DIRECT 表示直接连接目标；REJECT 表示拒绝该请求。三者是处理动作，不是规则关键字。前面的 DOMAIN-SUFFIX、GEOIP、IP-CIDR 等负责判断“匹配谁”，末尾策略负责决定“怎样处理”。

PROXY 并不代表任意请求都一定成功，它只是把请求交给当前选中的代理策略继续处理。最终结果仍取决于用户已有配置、对应协议参数和网络状态。Shadowrocket 支持的配置可能包含 Shadowsocks、VMess、VLESS、Trojan、Hysteria2 或 WireGuard 等协议，但规则顺序与具体协议相互独立：更换协议不会改变 [Rule] 的自上而下匹配方式。

DIRECT 也不是“忽略 Shadowrocket”。请求仍然先进入规则判断，只是在命中后选择直接出站。因此，遇到局域网设备无法访问时，应检查私有地址规则是否位于 FINAL 之前，同时确认 Global Routing 没有停留在 Proxy。

REJECT 应只用于边界明确的目标。若把 DOMAIN-SUFFIX,example.com,REJECT 写在前面，那么该主域名及全部子域名都会被拒绝，即使后面另有 DOMAIN,api.example.com,DIRECT 也不会生效。正确做法是先写允许例外，再写范围更大的拒绝规则。

FINAL 为什么必须放在规则末尾

FINAL 是未匹配请求的统一出口。它不限定域名、IP 或地址范围，因此放在中间时会接住此前尚未命中的所有请求，后续规则全部失去执行机会。配置中即使允许继续书写其他行，那些位于 FINAL 后面的行也无法改变已经完成的首条匹配结果。

# 推荐顺序
DOMAIN,internal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

# 错误顺序
FINAL,PROXY
DOMAIN,internal.example.com,DIRECT

第一组顺序会先检查精确域名、后缀和 GEOIP，最后才使用 PROXY 处理剩余请求。第二组在第一行已经让所有请求命中 FINAL，因此第二行永远没有机会生效。出现“新增规则完全没反应”时，首先检查它是否被写到了 FINAL 后面。

FINAL 的策略应由配置目标决定，而不是机械固定为某一个值。若配置采用“列出直连例外，其余走代理”的结构，可使用 FINAL,PROXY；若配置采用“只列出需要代理的目标，其余直连”的结构，则可使用 FINAL,DIRECT。两种结构都成立，但前面的规则必须与兜底方向一致。

修改后按固定步骤验证

1. 在 Config 中打开当前使用的配置，确认修改发生在实际启用的配置上，而不是另一份同名或备用配置。
2. 检查 [Rule] 中是否只有一条承担最终兜底的 FINAL，并确认它位于规则列表末尾。
3. 返回 Home，将 Global Routing 设为 Config。若处于 Proxy 或 Direct，自定义规则的预期分流结果无法按 Config 姿态验证。
4. 分别测试一个应命中 DIRECT 的目标和一个应命中 PROXY 的目标，不要只用单一网站判断全部规则。
5. 若结果与预期不符，从规则顶部开始查找第一条可能命中的 DOMAIN、DOMAIN-SUFFIX、IP-CIDR 或 GEOIP，而不是只检查刚新增的那一行。

配置更新、On Demand 与规则不生效的常见原因

用户已有自己的服务商与订阅时，配置更新可能重新写入远端提供的规则内容。若自定义规则直接改在会被更新覆盖的配置里，刷新后可能恢复为远端内容。修改前应分清当前配置是手动维护还是随订阅更新，并在更新后重新检查 [Rule] 顺序与 FINAL 位置。

On Demand 与规则优先级处理的是不同阶段。入口为 Settings → On Demand，它根据已设置的网络条件决定何时建立连接；连接建立后，请求怎样分流仍取决于 Global Routing 与当前配置规则。On Demand 没有建立连接时，仅调整 [Rule] 不能替代连接条件检查。

另一个常见原因是规则内容包含了 URL。DOMAIN 与 DOMAIN-SUFFIX 只接受域名部分；把协议头、端口或路径一起写入会导致匹配对象不正确。例如需要匹配访问 https://api.example.com:443/v1/status 的主机时，DOMAIN 值应写成 api.example.com，端口 443 与路径 /v1/status 不属于该域名规则的值。

规则名称和策略名称也应使用英文原文，并以英文逗号分隔字段。全角逗号、缺失字段、额外空格造成的不可见差异，都可能让一行配置无法按预期解析。复制规则后可先保留三段式结构，再逐项核对关键字、匹配值和策略。

保存前的规则检查清单

一份便于维护的配置通常具有清晰的分层：局域网与精确例外在前，域名后缀和地址段居中，GEOIP 靠后，FINAL 收尾。相同目标不应在多个位置反复出现互相冲突的策略；如果确实需要例外，应依靠“具体规则在前、通用规则在后”表达，而不是期待后面的规则覆盖前面。

• 当前修改的是正在使用的 Config，而不是另一份未启用配置。
• Home → Global Routing 已设为 Config，测试过程没有停留在 Proxy 或 Direct。
• DOMAIN 与 DOMAIN-SUFFIX 的值不含协议头、端口、路径和查询参数。
• 规则字段使用英文逗号分隔，关键字与策略保留英文原文。
• 精确 DOMAIN 位于可能覆盖它的 DOMAIN-SUFFIX 之前。
• 明确 IP-CIDR 的前缀长度，避免把 /16 与 /24 的覆盖范围混淆。
• GEOIP 位于需要优先处理的域名和地址规则之后。
• FINAL 只承担兜底作用，并位于 [Rule] 最后。
• 订阅更新后重新核对自定义内容是否仍然存在。
• Settings → On Demand 只控制连接时机，不替代 Global Routing 与规则检查。

完成检查后，应使用至少两个方向相反的样本验证：一个预期 DIRECT，一个预期 PROXY；若配置含 REJECT，再增加一个明确的拒绝目标。逐个样本从规则顶部推演首条命中项，比只观察连接开关或单次加载速度更能定位问题。

Shadowrocket 是 Apple 平台的闭源商业应用，iPhone 与 iPad 为主要使用设备，Mac、Apple TV 与 Apple Vision 的兼容性及系统要求以 App Store 页面标注为准。唯一获取入口为 App Store，开发者应显示为 Shadow Launch Technology Limited，应用 ID 为 932747118，购买方式为一次性买断。客户端买断与线路服务是不同事项，配置与订阅由用户自行准备和管理。