本文目录
开关重新关闭，既可能是订阅内容变化后的保护，也可能是已确认的选择没有被记住。判断前要固定同一订阅、保存相关字段，并区分开关状态和实际解析结果；追求开关一直亮着，反而可能掩盖需要重新确认的来源变化。
DNS 覆写确认过，重启后为什么仍会关闭？
“DNS 覆写”会把 Clash Verge Rev 设置页中的 DNS 值写入内核配置。内核是实际处理连接的程序；配置里的 dns.enable 决定其解析功能是否启用，和覆写开关不同。订阅自带受保护的解析策略时，应用要求确认，以免本地值覆盖后导致节点或网页无法访问。
固定同一订阅，保存其受保护 DNS 内容及重启前后的覆写状态。相关内容未变、已确认开启，却在重启后关闭，才符合本篇修复。若订阅更新改变相关字段，或切到未确认的另一份订阅，重新确认仍是正常保护。
官方 issue #7996 记录 macOS v2.5.4 上的现象；#8024 记录 Windows v2.5.5 每次重启都要重新确认的现象。Clash Verge Rev v2.5.7 Release 明确列出对此问题的修复。不能由这些报告推断每个系统或每个旧版本都受影响。
若开启 TUN 后域名无法解析，而运行配置中的 dns 只剩残缺字段，应阅读本站的 macOS TUN DNS 残留配置排查。那是 issue #8122 的另一种配置生成问题，不能用 v2.5.7 的此项修复直接下结论。
怎样判断是重启误关，还是订阅更新后的保护？
先在设置页记录 Clash Verge Rev 版本、当前选中的订阅名称与 DNS 覆写状态。网络已中断时先关闭 TUN，恢复普通网络或原本可用的系统代理，不在断网状态下反复改 DNS。
在动设置前备份当前订阅、自己写的扩展配置与客户端设置，并记下覆写页中要保留的 DNS 值。订阅可能含节点密码和订阅令牌，备份只留在本机，公开反馈时先脱敏。
检查当前订阅原文的 dns。v2.5.7 标签源码只把非空的 proxy-server-nameserver、proxy-server-nameserver-policy、nameserver-policy 作为需确认的受保护来源。
单独存在 nameserver、空列表、空映射或空字符串，不触发这项来源检查；不能把“订阅有任意 dns 字段”写成触发条件。
比较重启前后这三项的实际值与订阅身份。若订阅在后台自动更新、切到了别的订阅，或受保护值改变，先按新内容判断是否需要重新确认。只改其他无关字段或调整映射键顺序，不应让同一订阅的确认失效。
这一节只用于记录当前版本的表现。只有确实要用本地 DNS 覆写订阅解析设置时，才开启并阅读风险提示；保存同一订阅未更新时的确认结果、开关和运行配置，作为升级后的对照。
订阅与字段对照结果
| 观察到的结果 | 下一步 |
|---|---|
| 同一订阅、受保护字段未变，已确认的覆写重启后关闭 | 符合本文修复路径，核对版本并更新至 v2.5.7。 |
| 订阅更新后受保护字段改变，或首次切到另一订阅 | 需要重新确认；比对新内容后决定是否覆盖。 |
| 订阅只有 nameserver，没有三项非空受保护字段 | 不属于此项保护触发条件；另查设置保存、扩展和日志。 |
| 覆写保持开启，但 TUN 开启后仍然无法解析域名 | 检查运行配置与 DNS 上游，别把开关持久化当作 TUN 故障根因。 |
如何用 v2.5.7 修复，同时保留订阅 DNS 保护？
从 Clash Verge Rev 项目正式 Release 核对 v2.5.7，再按设备正常更新方式升级。不要从未核实的镜像下载，不要清空应用数据目录，也不要手改生成的运行配置。保留升级前的订阅与扩展备份，以便比较实际生效的 DNS。
升级后仍用原来的同一订阅，确认三个受保护 DNS 字段未变。确需本地覆写时开启并完成一次风险确认，再按下一节统一做重启验证。
v2.5.7 标签源码会保存每份订阅的确认，测试覆盖同一订阅、同一受保护来源在重启后继续开启，以及来源变更后重新关闭。因此修复目标是记住有效的确认，并没有取消订阅 DNS 的保护。切到另一份未确认的订阅可能关闭那份订阅的覆写；切回未改变的原订阅，其确认仍应有效。
官方扩展配置文档说明，覆写开启时，覆写页中填了值的 dns 字段和 hosts 会替换订阅相应字段；关闭时，应用不因这个开关改动订阅 dns。全局扩展、订阅扩展与脚本仍可能在后续步骤改写结果。若开关保持开启但解析与预期不符，应检查运行配置与扩展链，不要反复点击开关。
用同一订阅重启应用两次，DNS 覆写应保持开启
先核对版本为官方 v2.5.7、当前订阅和受保护 DNS 字段均与测试前相同。开启并确认一次后，完整退出并重新启动两次，DNS 覆写都应对这份订阅保持开启。
再看运行配置中的 dns，确认自己实际填写的覆写值进入最终配置，并固定同一节点访问一处真实 HTTPS 网站。Windows 用户开启 TUN 前，还必须确认实际服务组件已包含安全修复；未确认的旧服务保持停用。
需要 TUN 时，先让系统代理或普通网络通过，再在权限与服务条件满足后短时间开启 TUN，核对域名解析、网页完整加载和连接日志。
若有第二份订阅，切换过去时看它自己的覆写状态，再切回原订阅；不要把其他订阅未确认时的自动关闭当成原订阅设置丢失。订阅的受保护 DNS 内容确实更新后，客户端应重新要求确认，不能为追求“永远开启”绕过保护。
覆写仍丢失或断网时，恢复原设置并保留证据
先关闭 TUN，停用本地 DNS 覆写，让应用按官方文档用当前订阅自带 DNS 生成运行配置；确认普通网络或此前验证可用的系统代理恢复。若还改过扩展或订阅，从事前备份恢复这些改动，再重启并检查运行配置。关闭覆写只是撤销本地覆盖，不等于关闭内核 DNS，也不能保证原订阅本身一定正确。
不要手改 verge.yaml 的确认值来强制保持开启，不要随意粘贴陌生 DNS、清空 Profile 或删除整个应用数据目录。若 v2.5.7 上同一订阅、三项受保护字段完全未变仍误关，向项目 issue 提供系统和客户端版本、订阅是否自动更新、重启前后开关状态、脱敏后的相关字段、运行配置差异与日志。
若开关保持开启但 TUN 仍断网，转查 DNS 配置链、上游解析、节点与接口，不把它合并为这次持久化故障。本站已有 macOS TUN DNS 残留配置的独立排查文章，适用于相应证据匹配时的修复与回退。