很多 Clash、Mihomo、Clash Verge Rev 用户都会遇到一个问题：
明明已经手动修改好了规则、DNS、代理组或者节点名称，但只要点击一次“更新订阅”，之前改过的内容就全部恢复成原来的样子。
常见表现包括：
- Clash订阅更新后配置被覆盖
- 自定义规则更新后消失
- DNS设置被恢复
- Proxy Groups被重置
- 手动修改的节点名称变回原样
- 更新订阅后分流规则失效
- 本地修改的YAML被覆盖
- Clash Verge Rev更新订阅后配置恢复
- Mihomo更新后自定义配置丢失
- 每次订阅更新都要重新改配置
这种情况通常不是客户端故障。
真正的原因是：
订阅配置和本地自定义配置没有分离。
本文重点讲清楚为什么 Clash 更新订阅会覆盖配置，以及怎样保留自定义 Rules、DNS、Proxy Groups 和其他长期设置。
Clash 订阅更新后配置总被覆盖，想获取稳定可用的 Clash / Mihomo 订阅线路？
获取稳定订阅线路一、为什么Clash更新订阅后配置会被覆盖？
先理解 Clash 订阅的工作方式。
普通订阅通常是一个远程 URL，例如：
https://example.com/subscribe?token=xxxxxx
客户端点击更新时，会重新访问这个地址。
服务器返回一份新的配置，例如：
proxies:
proxy-groups:
rules:
dns:
客户端随后会用服务器返回的新配置替换原来的订阅配置。
所以流程实际上是：
订阅链接
↓
服务器生成最新配置
↓
Clash重新下载
↓
覆盖原订阅配置
↓
加载新配置
如果你直接修改的是这份由订阅生成的 YAML，那么下一次更新时，自然有可能被覆盖。
Clash更新订阅会覆盖原来的DNS配置吗？
会，具体取决于你修改DNS配置的位置。
如果你直接修改的是远程订阅下载下来的YAML配置，例如手动调整：
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
– 1.1.1.1
– 8.8.8.8
那么下一次执行“更新订阅”时，客户端通常会重新下载服务端提供的完整配置文件。
新的远程配置可能重新写入：
- dns
- proxies
- proxy-groups
- rules
- rule-providers
因此你之前手动修改的DNS配置可能会被覆盖。
这也是很多用户遇到：
“Clash更新订阅后DNS又恢复了”
“更新订阅时覆盖了原有DNS配置”
“我改好的DNS为什么更新一次就没了”
这些问题的主要原因。
简单理解就是：
你修改的是订阅文件本身，而订阅更新相当于重新下载一份新的配置。
只要服务端返回的新配置中包含dns字段，就可能覆盖你本地修改过的dns内容。
怎么避免更新订阅覆盖DNS？
不建议长期直接修改远程订阅生成的YAML文件。
更稳妥的方法是使用客户端提供的：
- Override
- Mixin
- 覆写配置
- 扩展配置
- 本地配置
把自己的DNS设置单独放在覆写层。
这样即使远程订阅更新，客户端仍然可以在加载订阅后，再应用自己的本地DNS设置。
不同Clash或Mihomo客户端名称可能不同，但原理基本一样：
远程订阅负责节点和基础配置。
本地覆写负责你自己的DNS、规则和策略修改。
“当前订阅包含自定义DNS配置”是什么意思？
部分Clash、Mihomo或Clash Verge Rev客户端在更新订阅时，可能会检测到当前配置已经包含自定义DNS设置。
如果看到类似：
“当前订阅包含自定义DNS配置”
“更新订阅可能覆盖DNS设置”
这样的提示，意思通常不是DNS出现故障，而是在提醒你：
当前配置中的dns字段可能会随着订阅更新发生变化。
例如当前配置里可能已经存在：
dns:
enable: true
或者：
nameserver:
fallback:
fake-ip-filter:
这些配置可能来自：
- 服务商订阅
- 你自己手动修改的YAML
- Override
- Mixin
- 第三方配置模板
如果这些DNS设置很重要，更新订阅之前最好先确认它们到底属于：
远程订阅配置
还是：
本地覆写配置。
如果属于远程订阅本身，那么更新后被替换是正常现象。
如果希望长期保留，建议迁移到Override、Mixin或客户端提供的本地覆写功能中。
更新订阅前要不要备份DNS？
如果之前手动修改过：
nameserver
fallback
fake-ip
fake-ip-filter
respect-rules
等DNS参数，建议先备份。
特别是自己解决过：
DNS污染
国内外DNS分流
Fake-IP冲突
某些网站无法解析
等问题的用户，不建议直接更新订阅后再重新配置。
更好的做法是：
先保存自己的DNS配置，再把需要长期保留的部分迁移到本地覆写层。
二、订阅配置和本地配置一定要区分
可以简单理解为：
订阅配置：
由服务器控制。
本地配置：
由你自己控制。
订阅更新以后，服务端配置可以重新生成。
但真正想长期保存的：
- Rules
- DNS
- Proxy Groups
- TUN
- Sniffer
- Rule Providers
最好不要全部直接修改在自动更新的订阅文件里。
否则每次刷新都可能重新覆盖。
三、哪些配置最容易被订阅更新覆盖？
最常见的是以下几类。
1. 自定义Rules
例如你手动增加：
DOMAIN-SUFFIX,example.com,DIRECT
或者：
DOMAIN-SUFFIX,google.com,节点选择
更新订阅后，这些规则可能直接消失。
2. DNS设置
例如手动修改：
nameserver
fallback
fake-ip-filter
更新以后也可能重新恢复为服务端默认值。
3. Proxy Groups
例如自己增加：
AI工具
流媒体
国外网站
自动选择
等策略组。
如果直接写进订阅 YAML，也可能被服务器重新生成的配置覆盖。
4. 节点名称
例如把：
HK-01
改成：
香港高速01
订阅更新后通常会恢复成服务端原始名称。
5. TUN与Sniffer
如果服务端完整下发 YAML，这些高级配置同样可能被覆盖。
四、为什么手动修改节点名称最容易失效？
节点名称本身通常由订阅服务器提供。
例如服务器返回：
name: HK-01
你在本地修改成：
name: 香港01
下一次更新时，服务器又重新返回：
name: HK-01
客户端就会再次覆盖。
所以：
手动修改订阅节点名称通常不是长期稳定方案。
如果客户端支持覆写、脚本或配置增强功能，应优先使用这些机制。
五、更新订阅前先备份原配置
如果当前已经有一份修改好的配置，第一步不要继续更新。
先备份。
例如：
config.yaml
复制成：
config-backup.yaml
或者：
custom-config.yaml
至少保留一份当前可以正常使用的版本。
这样即使更新后配置被覆盖，也可以立即恢复。
六、最简单的方法：不要直接修改订阅生成的YAML
这是最重要的一条原则。
如果当前配置来自：
远程订阅
就尽量不要直接把大量自定义内容写进这份自动更新文件。
因为这份文件的控制权本来就在服务端。
更稳妥的思路是：
订阅负责节点
本地配置负责规则
这样两部分互不干扰。
七、什么是“本地配置 + Proxy Provider”？
这是比较常见的解决方案。
核心思路是：
本地 YAML 保存：
- DNS
- Rules
- Proxy Groups
- TUN
- Sniffer
远程 Proxy Provider 负责：
- 节点列表
- 节点更新
例如：
proxy-providers:
airport:
type: http
url: https://example.com/provider.yaml
interval: 86400
这样节点可以远程更新。
但本地规则不会随着节点更新被整体覆盖。
八、为什么Proxy Provider更适合长期自定义？
普通完整订阅更新时，可能直接覆盖整份配置。
而 Proxy Provider 通常只负责：
节点。
例如：
本地配置：
DNS
Rules
Proxy Groups
保持不变。
Provider更新：
HK-01
JP-01
SG-01
只更新节点列表。
这样就实现：
节点自动更新
同时：
自定义配置长期保存
这是很多进阶用户长期使用的方式。
九、本地配置可以怎样组织？
一个简单思路是：
本地 YAML：
mixed-port
mode
dns
proxy-groups
rules
proxy-providers
然后节点来源放在：
proxy-providers
例如：
proxy-providers:
provider1:
type: http
url: https://example.com/provider.yaml
代理组再调用：
provider1
这样不需要把所有节点直接写进本地配置。
十、代理组怎样调用Provider？
例如：
proxy-groups:
- name: 节点选择
type: select
use:- provider1
这样：
provider1负责更新节点。
节点选择负责显示和调用这些节点。
即使 Provider 更新：
增加节点
删除节点
更换服务器
本地的：
节点选择
这个代理组仍然可以保留。
十一、Rules应该放在哪里？
如果希望规则长期保存，建议放在：
本地配置
而不是远程完整订阅中直接修改。
例如：
rules:
- DOMAIN-SUFFIX,google.com,节点选择
- DOMAIN-SUFFIX,youtube.com,节点选择
- GEOIP,CN,DIRECT
- MATCH,节点选择
这些规则只要本地 YAML 不被覆盖，就可以长期保存。
十二、DNS也建议放在本地配置
例如：
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
– 1.1.1.1
– 8.8.8.8
如果直接改订阅生成的 YAML，下一次更新可能消失。
如果把 DNS 放在自己的本地配置中，就不会因为节点 Provider 更新而自动被覆盖。
十三、更新节点和更新完整配置不是一回事
这是理解整个问题的关键。
完整订阅更新：
可能更新：
- 节点
- Proxy Groups
- Rules
- DNS
- Providers
Provider更新：
通常主要更新：
- 节点
所以如果用户自定义需求比较多：
Provider方式更容易长期维护。
十四、Clash Verge Rev可以使用覆写功能吗？
部分 Clash Verge Rev / Mihomo 客户端会提供：
- Merge
- Override
- Script
- Mixin
- 扩展配置
名称可能因版本不同而变化。
这些功能的核心作用类似：
订阅更新后
再把你的自定义配置重新合并进去。
例如：
服务器下发原始配置
↓
客户端更新
↓
应用本地覆写
↓
生成最终配置
这样也可以解决“更新后自定义规则消失”的问题。
十五、什么是配置覆写？
配置覆写可以理解为：
不直接修改原始订阅。
而是在订阅加载以后，再额外增加自己的设置。
例如原订阅 DNS 是：
dns:
enable: true
通过覆写增加：
fake-ip-filter
或者调整：
nameserver
这样即使原订阅重新下载，客户端仍可以重新应用这部分自定义配置。
十六、覆写功能比直接改YAML有什么优势？
最大的优势就是：
不会直接破坏原始订阅。
同时更新后可以重复应用。
如果直接修改原 YAML：
更新一次就可能消失。
如果使用覆写：
每次更新以后都可以再次自动合并。
所以对于经常更新订阅的用户，覆写更加适合。
十七、不同客户端的覆写功能名称可能不一样
不要死记某一个菜单名称。
不同客户端可能叫：
- Override
- Merge
- Mixin
- Script
- 扩展配置
- 配置覆写
本质上都是：
在原配置基础上进行二次处理。
具体功能需要根据当前客户端版本判断。
十八、为什么更新后代理组突然变了？
因为代理组：
proxy-groups
也可能由订阅服务器直接生成。
例如原来服务器返回：
节点选择
自动选择
故障转移
后来服务端调整为：
手动选择
自动测速
订阅更新以后，本地代理组就会跟着改变。
如果希望代理组结构固定：
应该自己维护本地 Proxy Groups。
十九、为什么更新后原来选择的节点变了？
订阅更新以后可能出现：
- 原节点被删除
- 节点改名
- Proxy Group重新生成
- 默认选择恢复
于是原来选择：
香港01
更新后节点变成：
香港高速
客户端就找不到原来的节点。
这时可能自动切换到：
DIRECT
或者：
第一个可用节点。
所以更新后发现“节点被切换”并不一定是程序异常。
二十、怎样避免节点改名导致代理组失效？
尽量不要在本地 Proxy Groups 中直接写大量可能变化的节点名称。
更稳定的方法是：
通过 Provider：
use:
来调用一组节点。
例如：
proxy-groups:
- name: 自动选择
type: url-test
use:- provider1
这样 Provider 内部节点变化后，代理组仍然存在。
二十一、Rule Provider也可以减少配置维护量
如果规则很多，也可以使用：
rule-providers
例如：
rule-providers:
google:
type: http
url: https://example.com/google.yaml
这样：
主配置负责结构
规则文件负责具体规则。
优点是：
不同模块可以分别更新。
但同时也增加了配置复杂度。
普通用户不需要一开始就全部使用 Provider。
二十二、订阅更新后DNS恢复默认怎么办？
如果每次更新以后 DNS 都被恢复，说明 DNS 很可能写在：
订阅生成配置
里面。
可以考虑：
方法一：
使用客户端覆写功能。
方法二：
建立本地主配置，把 DNS 写在本地主配置中。
方法三：
使用本地 YAML + Proxy Provider。
核心原则还是：
不要长期直接编辑会被远程更新覆盖的配置。
二十三、订阅更新后自定义Rules消失怎么办？
同样可以采用三种思路。
方法一：本地备份后手动恢复
适合偶尔修改规则的用户。
方法二：客户端覆写
适合需要自动更新订阅，同时只做少量自定义的用户。
方法三：本地配置 + Provider
适合长期维护大量自定义规则的用户。
二十四、哪种方式最适合普通用户？
如果只是偶尔修改一两条规则：
优先：
客户端覆写功能。
这样操作相对简单。
不需要完全重写一套 YAML。
二十五、哪种方式适合进阶用户？
如果需要：
- 自定义DNS
- 大量Rules
- 多个Proxy Groups
- 多订阅管理
- 固定分流结构
- 长期维护
更适合：
本地配置 + Proxy Provider。
因为配置结构更清晰，也更容易控制。
二十六、什么时候不建议自己维护复杂YAML？
如果只是想：
- 导入订阅
- 选择节点
- 正常访问网络
完全没必要自己维护复杂配置。
直接使用服务端提供的订阅即可。
只有真正需要：
分流
DNS
多订阅
高级规则
时，再逐步学习本地配置。
二十七、为什么“保存配置”不等于“永久不会被覆盖”？
客户端里点击：
保存
只能说明：
当前本地修改已经保存。
但如果这个 Profile 本身属于：
远程订阅
那么下一次更新仍然可能重新下载服务器配置。
所以：
保存 ≠ 禁止订阅覆盖。
要真正保留自定义内容，必须把配置结构设计正确。
二十八、不要把订阅自动更新频率设得太高
如果当前还没有解决配置覆盖问题，却设置：
每30分钟自动更新
那么你的本地修改可能很快再次被覆盖。
在调整配置期间，可以先：
关闭自动更新
或者：
延长更新间隔
等本地配置结构处理好以后，再重新开启自动更新。
二十九、修改配置前建议关闭自动更新
特别是准备手动改：
Rules
DNS
Proxy Groups
之前。
建议先暂时关闭：
自动更新订阅
避免正在修改过程中，客户端突然刷新配置。
否则可能出现：
刚修改完成
几分钟后又恢复原样。
三十、怎样判断当前配置是不是远程订阅生成的？
可以进入客户端：
Profiles / 配置
查看来源。
如果配置旁边有：
- URL
- Update
- Refresh
- 更新时间
- 自动更新间隔
通常说明它属于远程订阅。
如果只是：
本地文件路径
例如：
C:\Users\xxx\config.yaml
则更可能是本地配置。
三十一、更新前后可以对比YAML文件
如果不确定具体哪些内容被覆盖，可以：
更新前：
保存一份 config-before.yaml
更新后：
保存一份 config-after.yaml
然后使用文本比较工具对比。
重点看：
- proxies
- proxy-groups
- rules
- dns
- tun
- providers
这样可以快速判断究竟是哪部分发生变化。
三十二、订阅更新后配置被覆盖的标准解决顺序
遇到问题时，可以按照下面顺序处理。
第一步：暂停自动更新
避免配置继续变化。
第二步：备份当前可用配置
保存原始 YAML。
第三步：确认哪些内容被覆盖
重点检查 Rules、DNS 和 Proxy Groups。
第四步：区分远程配置和本地配置
确认当前 Profile 的来源。
第五步：少量自定义使用覆写
不要直接修改原订阅。
第六步：大量自定义使用本地主配置
把规则、DNS 和代理组放在本地。
第七步：节点改用Proxy Provider
让节点继续自动更新。
第八步：恢复自动更新
确认更新节点不会覆盖本地配置后再开启。
三十三、常见问题快速对照
| 现象 | 优先处理方向 |
|---|---|
| 更新后Rules消失 | 本地规则或覆写 |
| 更新后DNS恢复默认 | DNS覆写或本地配置 |
| Proxy Groups被重置 | 本地代理组 |
| 节点名称恢复 | 服务端节点名称 |
| 更新后节点选择变化 | 原节点删除或改名 |
| 本地YAML全部恢复 | 远程订阅覆盖 |
| 每次更新都要重新修改 | 配置结构需要分离 |
| 自动更新后突然变化 | 暂停自动更新 |
| 只想修改少量规则 | 使用Override/Mixin |
| 需要大量长期自定义 | 本地配置 + Provider |
三十四、最推荐的三种使用方式
方案一：普通订阅
适合：
新手
普通使用
不修改规则
特点：
简单、省事、自动更新。
方案二：订阅 + 覆写
适合：
需要少量：
Rules
DNS
Proxy Groups
自定义的用户。
特点：
既可以更新订阅，又能保留一部分本地修改。
方案三：本地配置 + Proxy Provider
适合：
进阶用户
长期自定义
多订阅管理
特点：
节点远程更新
规则本地控制
配置最稳定。
Clash改规则后更新订阅为什么又被覆盖？
原因和DNS配置被覆盖完全一样。
如果直接修改远程订阅中的rules、proxy-groups或DNS，下一次更新订阅时，客户端会重新下载服务端配置，因此本地修改可能消失。
想长期保留自己的规则，建议不要直接修改远程订阅主体，而是使用Override、Mixin或本地配置追加自己的规则。
因此可以把Clash配置分成两层理解：
远程订阅：节点、基础规则、服务商配置
本地覆写：自定义DNS、自定义规则、自定义代理组
这样以后更新订阅时，就不容易把自己的配置一起覆盖掉。
总结
Clash订阅更新后配置被覆盖，通常不是客户端故障，而是远程订阅的正常更新机制。
当你点击更新订阅以后，客户端会重新下载服务端生成的配置。
如果之前直接修改了这份配置里的：
Rules
DNS
Proxy Groups
节点名称
TUN
这些内容就可能被新的远程配置覆盖。
解决这个问题的核心不是：
“怎样阻止Clash更新。”
而是：
“怎样把远程订阅和本地自定义配置分开。”
普通用户如果只需要少量修改，可以优先使用客户端的：
Override
Merge
Mixin
配置覆写
等功能。
如果需要长期维护复杂的：
Rules
DNS
Proxy Groups
更适合使用：
本地配置 + Proxy Provider
让：
节点由远程订阅更新
而：
规则、DNS和代理组由本地配置长期保存。
只要把这两部分分离，Clash订阅更新后配置反复被覆盖的问题就会明显减少。
