为什么需要「覆写」：订阅更新会带走手改内容

很多人第一次用 Clash Meta（社区常称 Mihomo 内核）时，路径都很标准：拿到机场订阅链接 → 导入客户端 → 选一个策略组开始上网。真正开始「折腾」的契机，往往是下面三类诉求之一：只想给某个域名单独走直连或代理、想塞一个自建节点进主策略组、或机场默认策略组结构不符合你的习惯。若直接去改「下载下来的那份订阅 YAML」，下次点「更新订阅」时，你的改动很可能被远程内容整份覆盖——这就是要把「远程」和「本地」拆开的理由。

所谓 覆写（Override），在工程上通常等价于：客户端或你自己维护的第二份（或多份）YAML 片段，在生成最终运行配置时与订阅合并。内核仍然只吃一份合成后的配置；对你而言，机场订阅保持「只读」，个人偏好写在覆写层，更新与定制互不影响。本文默认你已能稳定导入订阅；若还在熟悉订阅与多源管理，可先对照 Clash 订阅链接使用教程，再回到这里做增量。

先建立心智模型：谁负责节点，谁负责哲学

把配置想成两条轨道最省心。第一条轨道是订阅：由机场维护节点列表、倍率、分组标签，它的生命周期是「定期拉取」。第二条轨道是本地覆写：放你自己的 proxies、对 proxy-groups 的补丁、以及额外的 rules 或 rule-providers。合成后，内核看到的仍是标准的 proxies / proxy-groups / rules 结构，并不会魔法般地多出一种「订阅里不存在的字段」；区别只在于这些段落来自不同文件，由软件在启动或重载前拼好。

因此，覆写不适合用来「修补失效的机场节点」——那是上游质量或线路问题；它适合的是个人策略：公司内网域名直连、某个 SaaS 固定走自建、把两套订阅里的节点并入同一手动组等。分流哲学的大框架仍可参考 Clash 分流规则配置教程，本文只补充「不碰订阅文件的前提下如何落地」。

图形客户端与「合并文件」：界面里那份「本地扩展」就是覆写

不同桌面客户端对覆写的叫法不一：Merge、Mixin、覆写、扩展配置等，本质都是把一段本地 YAML 与当前配置合并。以 Windows 上常见的 Clash Verge Rev 为例，你可以在「订阅配置」之外单独维护一份合并片段，用于声明自定义节点或附加规则；保存后由客户端生成最终配置再交给内核。具体菜单位置会随版本迭代而变化，但判断标准不变：是否存在一份独立于订阅 URL、不会因点「更新订阅」就被整份覆盖的编辑区。

若你更习惯纯文件工作流：在服务器或路由器上直接跑 Mihomo 时，通常会把「基础配置」与「个人片段」分成两个文件，再用你自己的生成脚本或上游工具链接起来——这与图形界面里的合并是同一类问题，只是少了 UI 包装。无论哪条路，都建议先在客户端里打开「当前运行配置」预览（若提供），确认合并结果是否符合预期，再讨论延迟与规则命中。安装与首次导入若仍不熟，可并行阅读 Clash Verge Rev 完整使用教程。

自定义节点：写在覆写里的 proxies

要在不修改订阅 YAML的前提下增加一个自建或其它来源的节点，标准做法是：在覆写文件中声明 proxies: 数组，并确保每个节点有全局唯一的 name。Clash Meta 支持的协议类型随版本扩展，字段名与原版 Clash 大体一致，但个别传输层选项以你所用内核版本文档为准。下面是一段仅作结构演示的骨架（示例值请替换为你自己的服务器信息）：

proxies:
  # Example: single outbound; use a unique name to avoid collision with subs
  - name: HOME-SS-EXAMPLE
    type: ss
    server: 198.51.100.10
    port: 8388
    cipher: aes-128-gcm
    password: "REPLACE_ME"

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - HOME-SS-EXAMPLE
      - 🔰 节点选择

要点有三。第一，proxy-groups 里引用到的名称必须已经在合并后的 proxies 或 proxy-providers 展开结果中存在。第二，若你只新增了 proxies 却忘了把名称挂进任何策略组，界面里可能根本选不到它。第三，大型节点列表更适合用 proxy-providers 引用外部文件或 URL，由内核按间隔更新；覆写文件只负责声明 provider 与组关系，而不是把上千行节点粘进一个文件。

改某个策略组：覆写如何「补全」而不是「整段替换」

不同合并实现对 YAML 键的深度合并策略可能不同：有的会把同名 proxy-groups 数组合并，有的则以后者覆盖前者。实际排障时，不要凭记忆猜，而应以合并后的最终配置为准。若你发现「覆写里写的组消失了」，通常是因为整段被订阅里的同名键覆盖——解决办法包括：调整合并顺序（让覆写在后）、或改用唯一命名的新组，再在 rules 里把流量导向新组。

一种稳妥的个人习惯是：少改机场自带组名，多建一个「我的主组」，里面按你需要混合订阅节点与自建节点；规则末尾把 MATCH 指向该组。这样机场更新改变了内部小分组结构时，你不至于跟着全盘重绑。若你从旧客户端迁来，也可把覆写当作迁移助手，思路与 Clash Meta 升级指南 中「订阅优先再补规则」一致。

追加规则：让「前面的先匹配」为你服务

规则列表是自上而下匹配的——这在 分流教程 里反复强调。覆写层追加规则时，你要问自己：这些规则应该出现在最终列表的顶部、中部还是底部？若目的是为少数域名「开绿灯」或「关进代理」，通常要把它们放在足够靠前的位置，避免被某条宽泛的 GEOIP 或远程规则集提前命中。

图形客户端往往提供「规则前插 / 后插」或分栏编辑，本质就是把你的行插入合并结果的不同位置；若你手写合并，请在生成后检查 rules: 全量顺序。对于体量大的第三方规则，推荐使用 rule-providers 引用远程集，再在覆写里只写少量「个人例外」行，避免单文件几千行难以 diff。若规则命中与预期不符，可配合 连接日志排查教程 对照域名与策略组。

与 DNS、TUN 的交界：覆写不是万能补丁

有时你以为「加一条规则就能好」，实际却是 DNS 解析路径或 TUN 全局接管导致流量根本没走到你假设的策略组。覆写层同样可以包含 dns: 段落或开关型选项，但改动越大，越建议分步验证：先确认规则命中，再动 DNS，最后才碰 tun 与系统路由。对游戏与命令行场景，可对照 TUN 模式详解，避免把「规则问题」误判成「节点问题」。

常见翻车点 checklist

• 同名节点：合并后出现重复 name，界面选中与真实出站不一致。
• 合并顺序反了：覆写写在订阅之前加载，导致订阅又把你的组盖掉。
• 规则放错位置：命中顺序靠后，永远轮不到你的例外。
• 引用了不存在的组：YAML 语法通过，但内核启动报错或静默忽略段落。

遇到诡异现象时，优先导出「运行时配置」做全文搜索，比只在覆写文件里盯着几行更快定位。

开源仓库与安装包：继续分开看待

Mihomo 与 surrounding 客户端多为开源项目，在 GitHub 上查阅 Issue、核对发行说明是深度用户的良好习惯。需要强调的是：仓库与 Release 页适合建立信任与查版本；日常安装与升级仍建议以本站 Clash 客户端下载页 为主入口，避免误入仿冒或过期分流。若你还希望系统了解术语与选项，也可浏览 使用文档中心。

把订阅与覆写分层之后，你会明显感到「机场更新不再是一场心跳事件」：上游只管把节点列表保持新鲜，你的分流与自建入口则稳定在本地一层，改起来有章法、回滚也有据可查。相比每次在远程 YAML 里手改却被覆盖，这种结构在长期使用里往往更省心。

若你准备好在桌面端装好客户端并导入订阅，不妨从本站 下载页 选择适合自己系统的版本，把覆写当作「个人配置仓库」来维护；当订阅与本地习惯解耦后，同样的节点池也能玩出更贴合自己的走法。→ 立即免费下载 Clash，开启流畅上网新体验