自定义规则怎样维护：来源、用途与撤销写清楚

增加自定义规则前，写清目标、依据和撤销方法。规则数量多不等于更好，未经理解的规则可能让排查变得困难。

检查时关注什么

先观察实际请求命中情况，再只增加与具体任务相关的最小变更。保存原值、添加日期和作用范围，按客户端当前文档操作。服务订阅更新是否覆盖自定义项也要核对。

用一个情境说明边界

假设你只为一个工作域名调整路径，就先验证这个任务与普通网络是否都正常。不要顺手复制一整套未知规则；无效时撤销该项，再继续定位。

本次需要留下的记录

• 规则目的与出处
• 改动前后路径
• 撤销步骤和更新行为

给每条规则写一个明确撤销条件

假设你只想改变一个工作域名的路径，却导入整套陌生规则。它可能影响其他请求，后续很难知道哪条起作用。Mihomo 的规则按顺序匹配，具体语法只适用于该内核；添加规则前需要确认作用对象、位置和实际命中。

对照现象，决定下一项检查

把判断落实到一次操作

1. 根据当前软件文档观察一次自己的目标请求，只保留必要字段。
2. 保存原规则位置与选项，添加满足用途的最小变更，不顺带复制未知规则集。
3. 复测目标与普通任务，确认更新订阅后是否保留自定义项。
4. 若无效或产生副作用，按记录撤销该项并验证恢复；把未经证明的原因保留为假设。

什么时候停止，以及什么时候重新检查

不知道规则来源与含义时停止添加。企业网络和业务管理要求不由个人规则绕过。内核版本、目标域名或规则订阅更新后，旧顺序和字段可能需要重新核对。

再问一个容易遗漏的问题

DOMAIN 和 DOMAIN-SUFFIX 可以随意替换吗？

在Mihomo中前者对应完整域名，后者按域名后缀匹配，范围不同。改成后缀可能扩大影响；其他客户端不直接套同一语法。按当前规则文档确认，并观察相关任务。

保存本题的个人记录

规则用途与来源：
当前内核版本：
原位置与策略：
最小改动：
命中与副作用：
撤销及更新行为：

这份记录只保存自己核对过的条件；不填写密码、验证码或完整订阅凭据。下方检查表可下载空白版本。

常见疑问

网上流行的规则可以直接全加吗？

不应默认适用。不同任务和配置有差异，逐项理解与验证比数量更有意义。

阅读依据与下一步

继续阅读 订阅导入教程 与 旧订阅还能用但更新失败怎么理解：缓存与服务状态分开，也可返回 订阅与配置管理 查看同类问题。

资料来源