📖 教程 ⏱ 约 18 分钟阅读

Clash Verge Rev 在 Windows 11 上怎么配置 Mixin 覆写？YAML 与界面分步实测（2026）

很多人手里是一份机场远程订阅，只想在本机改监听端口、给公司内网域名插几条直连、或把DNS从默认再拧一小格——却不想每次刷新订阅都把手工改动冲没。Clash Verge Rev 在 Windows 11 上提供的 Mixin／Profile Override（覆写）就是干这个的：你在 GUI 里打开覆写编辑器，贴小段 YAML，由 Mihomo 在加载最终配置时与远端基底深度合并。本文按实测顺序写：入口在哪、写什么键安全、规则 prepend 与 append 何时用、以及保存—重载—看日志的最短验证链；从零安装与系统代理／TUN 选型仍请看Win11 首次安装 Verge Rev。

这篇适合谁、和站内哪些文章互补

你已经能在 Windows 11 上导入订阅并上网，但希望：不修改商家托管的 YAML，只在本地叠一层「补丁」。这与「把订阅下载下来手工当静态文件改到地老天荒」是两条路：覆写让你保留自动更新节点列表的好处，把私有策略留在本地壳层。若你还卡在防火墙弹窗、混合端口默认是多少、TUN 与系统代理二选一，请先完成Windows 11 下 Clash Verge Rev 首次安装，再回本文动覆写，否则你会把「内核没加载成功」误会成「YAML 合并坏了」。

当你需要理解策略组名字与规则行里第三跳怎么对齐，可平行读Clash proxy-groups 完全指南与自定义规则教程；它们讲「写什么」，本文讲「写进覆写层后怎么与远程模板共存」。若覆写涉及 DNS 与假 IP，可再对照Clash 使用教程里 DNS／分流总览，把「单一事实来源」想清楚再改 keys。

排障时若已有超时日志但不确定卡在哪一段，可把本文与Win11 日志面板排查连接超时串联：覆写负责静态合并结果，日志负责运行时证据。

先把名词对齐：Mixin、覆写、Merge 到底是什么

不同教程里你会看到 Mixin、Override、Merge、Patch 交替出现；在 Clash Verge Rev 的语境下，可以粗略记：它们都是「在远端订阅生成的基底上再叠一层本地 YAML」，由内核在启动或重载时合成一份有效配置。这与在老式客户端里「找到下载缓存里的 config.yaml 用记事本硬改」不同：硬改往往在下次 Update 时丢更改，而覆写文本通常由 GUI 单独持久化，刷新订阅应保留这层内容（仍建议你在大版本升级后随手打开确认一眼）。

Mihomo 侧的合并是结构化深度合并：对象键会递归叠在一起，列表类字段有时由专用扩展键（例如规则增补）表达，而不是简单把整个 rules: 数组替换成只有你两行——那样会丢掉机场下发的数百条规则，属于新手最常犯的毁灭性操作。正确姿势是：改标量（端口、开关）、给 dns 增量补字段、用 prepend-rules／append-rules 在头尾塞你的片段。具体键名以你安装的内核主版本为准；保存若报错，优先看日志里提示的不识别键与 YAML 缩进。

第一步：确认当前激活的是「你要改的那份 profile」

覆写永远挂在某一份配置档上，而不是全局悬空。打开主界面后先核对：哪一条 profile 处于启用／高亮状态；系统代理或 TUN 开关是否由这份 profile 驱动。一个经典坑是笔记本里残留测试档 A与日常档 B，你在 A 的覆写里写了半天，实际在用 B——表象就是「我明明改了端口，netstat 却对不上」。这与订阅自动更新间隔一文里强调的「只对激活档调参」是同一纪律。

若你使用多份机场订阅拼在同一 profile，覆写仍只算最后一层补丁：理解「基底已经是合并后的胖文件」有助于估算冲突概率——越胖的默认 DNS／规则栈，越要用prepend精确抢跑，而不是试图重写半截 dns.fake-ip-range 却不知道上游已经依赖原值。

第二步：在 GUI 中找到覆写编辑器（Override／Merge）

不同发行与皮肤下菜单位移频繁，但心智模型稳定：进入 Profiles／配置列表 → 选中当前档 → 编辑详情 → 找到覆写／Override／Merge 文本框。部分版本把入口放在齿轮图标或右侧抽屉里；若你看到的是「仅预览整包 YAML」，那通常是只读合并结果，真正的可编辑覆写在旁边单独的 tab。

操作建议：初次只写两三行能保存的配置（例如改一个无害标量），证明「编辑器 → 保存 → 重载」闭环畅通，再写 DNS 与长规则。不要第一次就粘贴从论坛抄来的上百行「全能模板」——一旦合并失败，你很难判断是机场基底升级了，还是模板里的键与你的内核不匹配。从 CFW 迁来的读者可对照本站从 Clash for Windows 迁移到 Verge Rev里「用 Override 代替旧 Mixin」那一节，把旧片段改写成 Meta 接受的键名。

第三步：用覆写改混合端口与局域网监听

这是最适合练手的一类变更：键语义直观、验证快、和规则无耦合。当你希望终端、旧版 IDE、或局域网里另一台设备指向固定端口时，可以在覆写里声明 mixed-port 或与端口相关的等价键（以 GUI 生成预览为准），再结合 Verge 自带的系统代理写入能力，让 Windows「设置 → 网络和 Internet → 代理」里看到一致地址。若你要让局域网访问本机代理，往往还要同时打开 allow-lan，并在Windows 防火墙放行入站——否则「手机能 ping 通电脑但代理握手全拒绝」。局域网放行细节见Windows 11 允许局域网与防火墙专文，本文只强调：改端口＝三件事同时真：覆写里的监听值、系统代理或客户端里的展示值、下游应用的环境变量。

下面是一段示意（数字请按你环境替换），保存后应在日志或关于页看到新端口生效：

# Profile override snippet (example) — adjust port to your plan
mixed-port: 7888
allow-lan: true
bind-address: '*'

某些公司安全软件会劫持本机环回地址或扫描 CONNECT；如果你改端口后仅浏览器异常、日志里却看不到相应会话，不要先怀疑合并，而应检查是否有HTTPS 扫描与 Loopback 例外，必要时参考 UWP／商店应用环回专文。整体策略仍建议在教程索引里把「代理写进系统 / 只写环境变量 / 上 TUN」的分工先画清楚。

第四步：在覆写里调节 DNS 片段

DNS 属于高耦合区块：enhanced-mode 为 fake-ip 时，你在规则里对 IP-CIDR 的处理顺序会与「先域名后 IP」读取假设相互影响。覆写 dns 的原则是：只动必须动的子键，避免把机场自带的 nameserver-policy 或 fallback 整棵删掉却不自知。若你希望强制指定国内上游，可在覆写中补 nameserver 列表；若你发现办公网对 DoH 抖动，谨慎增加 fallback 并观察日志里解析阶段耗时。

示意（仍以你实际基底为准，切忌不经思考整段覆盖）：

dns:
  enable: true
  use-system-hosts: true
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

当你改 DNS 后访问异常，请先用日志是否仍有解析失败与连接视图的目标地址形态（域名还是 IP）对齐假设，再决定是回滚覆写还是改规则。盲目加 fallback 只会让排障维度从二维变五维。

第五步：prepend-rules 与 append-rules——插入你自己的规则碎片

绝大多数用户的需求是：几条内网直连、一个分流到新策略组、或临时把某域名送去某个 select。prepend-rules 把行插到规则表前部，让它更早被命中；append-rules 放在尾部，适合在你确认不想破坏机场 MATCH 行为的前提下追加兜底。务必保证第三列策略组或内置动作字面量真的存在于合并后的 proxy-groups；机场如果喜欢把自动组命名为「♻️ 自动选择」这类带符号的名字，你也要逐字照抄，而不是自己发明一个简短别名。

示意：

# Replace MY_GROUP with an existing proxy-group name from your merged profile
prepend-rules:
  - DOMAIN-SUFFIX,corp.example,DIRECT
  - DOMAIN,internal.vpn,DIRECT
  - DOMAIN-SUFFIX,stats.internal,REJECT

append-rules:
  - DOMAIN-SUFFIX,lab.example,MY_GROUP

如果你发现「明明 prepend 了却仍然走错组」，先怀疑更早还有其他高优先级规则，或域名实际请求的是另一个 CDN 主机名——用连接列表抄真实 SN 再写规则，比在覆写里堆二十条猜的域名要有效得多。更不要尝试在覆写中重写整个 rules: 数组去「图省事」，那等于关掉机场维护的大部分分流资产。

提醒：覆写文本若含内网地址、测试令牌、团队网关主机名，截图前请打码；仓库或群聊里传播覆写片段与传播密码本风险相当。

第六步：保存、重载与最小验证清单

建议把验证拆成四步打卡，任何一步失败都停在当前层，不要同时改端口又改 DNS 又加规则：

  1. 保存无报错：若解析失败，内核会在日志中给出行号；把覆写减半用二分法快速定位语法问题。
  2. 关于页／主界面展示的值与覆写一致：至少核对监听端口、模式、DNS 开关等可见项。
  3. 系统代理或测试命令指向新端口：例如用熟悉的 curl 探活地址看你的覆写端口是否真的在监听（注意环境变量是否仍写死旧值）。
  4. 连接列表出现预期命中：为测试域名故意触发访问，看策略链是否显示你的目标组；必要时暂时把日志级别抬高，对照日志面板教程里的阅读顺序。

订阅刷新测试同样重要：在 GUI 中对远程 profile 执行一次手动更新，再回到覆写编辑器确认你的本地补丁仍在，并观察更新后节点列表是否正常。若更新后突然解析失败后优先对比「是订阅真失败」还是「覆写引入键冲突」——二者日志前缀不同。

常见误区与会拖垮合并的写法

  • 在覆写里复制整份机场 YAML 再手改：失去订阅自动更新的意义，也会在合并层制造重复键。
  • 引用不存在的策略组名或拼写少一个字节：合并阶段或首批连接时立刻报错，症状像「突然全红」。
  • 同时多处修改端口：覆写写 7899，环境变量仍指向 7890，表现为「只有某个终端不通」。
  • 忽视 fake-ip 与规则的次序：覆写中改 DNS 后却不调整相关 no-resolve 片段，可能产生不可复现的间歇误判。
  • 把实验性键从旧 gist 直接粘贴：不同内核版本对实验字段的容忍度不同；保存失败时应以当前发行说明为准而不是以「网友全套配置」为准。

常见问题（口语速查）

覆写与「编辑远程预览 YAML」有什么区别？

预览往往是合并后的只读结果，用于审阅；覆写是本地持久化补丁源。改预览而不通过覆写层，常见后果是下次刷新订阅你的改动消失。

我可以只在覆写里写 tun 段吗？

可以片段化声明，但 TUN 涉及驱动与权限， Windows 上还要与系统路由协作；写完务必按首次安装文里的 TUN checklist 验证，不要假设「只要 YAML 有段就能隐式可用」。

覆写会影响订阅自动更新频率吗？

不直接影响；频率仍由订阅条目上的间隔与应用调度决定，详见订阅自动更新间隔。但如果你在覆写里引入大量健康检查或额外 rule-providers，可能间接改变流量形态——那是另一类调参。

小结

在 Windows 11 上用好 Clash Verge Rev 的 Mixin／Profile 覆写，本质是把「机场维护的共性配置」与「你只属于自己的边角需求」分层：远端负责节点与大体分流骨架，覆写负责端口、DNS 细节与几条必须靠前的私域规则。掌握 prepend 与 append 的语义、坚持小步保存验证，你就不会在订阅更新季把自己的本地补丁整个推翻。

相比之下，部分老式代理壳要么只提供「一次性导入」、要么鼓励你直接在缓存里手改整包，既不区分基底与补丁，也缺乏对 Mihomo 合并顺序的可视化；还有一类闭源工具把规则锁死在私域格式里，导出困难。Clash 生态则让 YAML 仍是可审计的通用语，客户端负责把远程更新、覆写层、内核观测串在同一流水线里；你再结合本站下载 Clash页挑选维护中的发行版，就能把「机场更新」与「本地策略」长期并列维护，而不必二选一。