Clash Meta 用 mixin 覆写远程订阅：注入自建规则不被更新覆盖（逐步操作）

为什么「改订阅文件」会被刷新覆盖

远程订阅在客户端里通常被建模为「从 URL 拉取的一段配置」，内核或 UI 会把它解析成 proxies、proxy-groups、rules 等字段，并可能写入缓存文件以便离线启动。无论你看到的是单文件合并结果还是多文件拆分，订阅刷新的本质往往是：重新下载远端内容 → 重新生成与订阅对应的那部分结构。于是你把广告拦截、GEOIP 直连或自定义策略组写进了订阅缓存本体，就等于写进了「每次可能被重写的区域」。

正确做法是把「机场维护」与「你维护」分层：机场继续负责节点与它的默认规则；你只维护覆写层（mixin、Merge、脚本覆写等，依客户端而定）或显式 prepend／append 管道。这样订阅更新只会替换 base，不会删除你放在覆写层里的片段。

心智模型：base、覆写层与「谁先生效」

把最终跑在 Mihomo 里的配置想成流水线合并结果，而不是单一静态文件。常见顺序可以概括为：订阅解析结果（base） → 客户端 Merge／mixin 叠加 →（可选）脚本覆写 → 内核启动前校验。你关心的「去广告、国内直连、自建策略组」应落在叠加层，或落在对 rules 数组有明确 prepend／append 语义的字段里。

Clash 系规则匹配是自上而下第一条命中即停。因此：

• 需要优先于机场规则裁决的内容（例如广告域名拦截、局域网直连、内网 DNS）应使用前置规则（prepend 语义），否则会先被订阅里较宽的条目抢走。
• 需要兜底或在订阅规则之后追加的条目（例如你自己的 MATCH、补充 RULE-SET）应使用后置规则（append 语义）。

Mihomo 内核侧：mixin 文件在合并中的角色

在原生 Mihomo（Clash Meta） 场景下，常见做法是在主配置所在目录提供 mixin.yaml（或通过主配置启用 mixin 机制，具体键名以你所用发行版文档为准），用于对顶层字段做递归合并。它的价值是：把 DNS、嗅探、实验特性、额外的 rule-providers 声明、以及少量 rules 补丁从订阅里剥离出来。

需要特别注意：不同版本对「数组合并」与「字典合并」的策略并不总相同。对 rules 这种超长数组，若覆写层与订阅层整表替换而非「拼接」，很容易出现「加了 mixin 反而丢订阅规则」或「订阅刷新后 rules 只剩一半」的现象。工程上更稳妥的组合是：订阅继续提供主体 rules；你把大块集合放到 rule-providers，只在覆写层增加 RULE-SET 引用行，或使用客户端提供的 prepend-rules／append-rules 管道（见下一节）。

# Illustrative: declare extra rule sets in overlay (paths depend on client workdir)
rule-providers:
  reject-ads:
    type: http
    behavior: domain
    url: "https://example.com/rules/reject.txt"
    path: ./ruleset/reject.yaml
    interval: 86400

rules:
  - RULE-SET,reject-ads,REJECT

上面仅为结构示意：请把 URL 与 path 换成你信任的规则源，并确认工作目录下可写入缓存文件。若拉取失败，按 rule-providers 专题逐项排查证书、出站与 update-interval。

图形客户端：Merge、prepend-rules 与 append-rules

在 Clash Verge Rev 等客户端中，「Merge」类覆写往往提供六种稳定语义：prepend-rules、append-rules、prepend-proxies、append-proxies、prepend-proxy-groups、append-proxy-groups。这与「直接改订阅 YAML」不同：prepend／append 明确表达拼接位置，因此订阅刷新后仍按同一管道合并。

实操建议：

1. 在 UI 中新建一条 Merge 配置（名称随意，建议带用途后缀便于备份）。
2. 把「国内直连、局域网、去广告」等高优先级条目放进 prepend-rules。
3. 把「自定义策略组引用、补充 RULE-SET、最终 MATCH」等放进 append-rules（若机场订阅已自带 MATCH，请谨慎避免重复或冲突）。
4. 需要新增节点或组时，用 prepend／append 对应段，避免与订阅里同名键意外覆盖。

# Merge snippet (client-specific file) — illustrative keys only
prepend-rules:
  - DOMAIN-SUFFIX,cn,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

append-rules:
  - RULE-SET,my-custom,MY_GROUP

若你使用脚本覆写（JavaScript 在客户端内执行），把它当作「最后一棒」：适合按条件重组数组，但更难排错；团队场景优先 Merge 的声明式拼接。

去广告、国内直连、自建策略组怎么接

去广告与拦截类规则

优先使用 rule-providers + RULE-SET，原因是大列表可独立更新、可回滚，且不会把成千上万行硬塞进 Merge。策略目标多为 REJECT 或专用 REJECT-DROP（视内核支持而定）。拦截列表过激时可能误伤应用内网页或统计域名，出现异常应二分法临时停用规则集定位。

国内直连与 GEOIP

常见写法是在 prepend-rules 中加入 GEOIP,CN,DIRECT 或更细粒度域名集。请确认与机场订阅里「最终 MATCH」的相对顺序：若机场先写了宽泛代理，再允许你 prepend，则国内直连会按预期优先生效；若顺序相反，则需要调整客户端合并顺序或改用 append／改写策略组引用。DNS 与 fake-ip 也会影响「看起来直连却仍走代理」的错觉，可交叉阅读 《DNS 泄漏与 fake-ip 排查》。

自建策略组与 url-test／fallback

当你要新增 proxy-groups 条目（例如「办公」「流媒体」「低延迟」）时，用 append-proxy-groups 或 Merge 中等价能力，避免覆盖机场已有组名。组内节点引用使用订阅生成的 proxy 名称，名称需与订阅解析结果完全一致（大小写敏感）。自动测速与故障切换可参考 《url-test 与 fallback 逐步配置》。

profile 与「选中节点」会不会丢

不少用户担心：订阅刷新后，自己在 UI 里选的节点是否会被重置。通常与 profile.store-selected 一类能力相关：开启后把「当前策略选择」写入 profile 存储，与订阅内容解耦。不同客户端把该开关放在「应用配置」「全局设置」或「profile 元数据」里，名称略有差异。建议你在完成 mixin／Merge 调整后，顺手确认该选项状态，并在一次订阅更新后验证选择是否保留。

验证步骤：看最终配置与做一次手动刷新

常见问题

写了 prepend 但仍走代理

多为顺序未如预期合并或 DNS 解析路径导致规则未按域名命中。请回到「最终配置」核对 prepend 段是否在最前，并检查 Sniffer、fake-ip 与相关域名是否被其他规则先行匹配。

启用 mixin 后订阅规则消失一部分

高度怀疑发生了整表覆盖式合并。把大段 rules 从 mixin 中移出，改为 rule-providers，或改用客户端提供的 prepend／append 管道，只增量插入少量行。

多配置文件／多订阅谁先合并

以你所用客户端文档为准；链式 Merge 的输出顺序决定最终行为。合并链越长，越建议用注释（英文）在本地 YAML 分段标注来源，避免日后自己也不记得哪一段来自哪个扩展。

实操检查清单

• 自定义内容已迁出「订阅缓存／订阅正文」，进入 Merge 或 mixin 层。
• 高优先级规则使用 prepend；兜底或补充使用 append，避免与机场 MATCH 打架。
• 大块列表使用 rule-providers，并确认本地 path 可写、interval 合理。
• 订阅刷新前后各导出一次「最终配置」做 diff。
• 与 DNS／fake-ip 异常交叉时，先按 DNS 专题缩小变量再调规则。

从可维护的客户端开始

把「订阅」与「覆写」拆清楚之后，Clash Meta 的长期价值才显现：机场更新节点，你更新规则哲学，两者互不抢地盘。接下来只需选一款对 Merge、mixin 与运行时预览支持友好的客户端，把流程固化成个人习惯即可。

立即免费下载 Clash，开启流畅上网新体验