Clash Verge Rev macOS 开 TUN 后 DNS 失效怎么修？

Clash Verge Rev issue #8122 记录了一台 macOS 设备在 v2.5.6、服务模式及 Mihomo v1.19.31 下的故障：TUN 一开启，连原本可直连的网站也无法按域名打开；报告者看到运行配置只剩 dns.enhanced-mode: redir-host。

该 issue 目前仍开放，只有一份详细复现和少量同症反馈，不能据此断言所有 Mac 或所有订阅都会中招。

报告者最初推测是关闭“DNS 覆写”后应用剥掉了订阅中的 dns。

项目成员在 issue 评论指出另一条更具体的路径：基础 config.yaml 里残留不完整的 dns 段，生成运行配置时盖过订阅 DNS；残段缺少 enable: true，内核 DNS 因此不可用。

官方扩展配置文档也写明，DNS 覆写关闭时应用本身不改动订阅 dns。本文按这个可检查的残留配置路径排障，不把报告者的最初归因写成项目结论。

适用前提是关闭 TUN 后普通网络或同一节点的系统代理能访问、开启 TUN 后域名解析失败，而且基础配置与运行配置确实出现相应差异。

若日志首先是 operation not permitted、get empty name、interface not found，或同一节点在系统代理下也不可用，应先按权限、出口接口或节点问题分流，不要修改 DNS。

先关闭 TUN，确认 macOS 的普通网络是否立即恢复。若系统代理原本可用，可以暂时只用系统代理；若退出客户端后仍无法上网，再核对系统网络设置中是否留有旧代理或 DNS，不要为了测试而反复开启故障 TUN。

在改动前分别保存原始订阅或 Profile、基础 config.yaml、应用生成的运行配置，并记录当前客户端与内核版本。

基础配置通常位于 ~/Library/Application Support/io.github.clash-verge-rev.clash-verge-rev/config.yaml。请通过本机应用目录或文件管理器核对实际路径。

不要把基础配置与订阅文件、dns_config.yaml 或生成的运行配置当成同一份。

订阅和配置可能包含节点凭据，备份留在本机安全位置，公开反馈只用脱敏副本。

记录同一网络下的三个状态：TUN 关闭时能否解析域名、TUN 开启后第一条 DNS 或 TUN 日志、关闭后能否恢复。这样才能判断故障是不是由接管 DNS 的路径触发，而不是浏览器缓存、节点失效或系统权限造成。

先看原始订阅的 dns 是否完整，特别是 enable: true、nameserver 和你原有的其他解析设置。再看基础 config.yaml 是否仅留 dns.enhanced-mode: redir-host 或类似不完整字段。

最后检查应用生成的运行配置是否与这份残段相似，而不是保留原订阅的 DNS。不要在尚未比对三份文件时，仅凭“DNS 覆写”开关关闭就删配置。

Mihomo 官方文档把 dns.enable 定义为是否启用内核 DNS，并列出 nameserver 等解析字段；TUN 的 dns-hijack 会把 DNS 查询交给内核。

若运行配置没有可用的 DNS 路径而 TUN 仍接管查询，域名请求就可能失败。这解释了为何先前系统代理或普通直连可用、TUN 接管后却全站失效；但是否属于 #8122，仍以本机配置差异为准。

Clash Verge Rev 官方文档说明从 v2.5.5 起，扩展配置写入的 dns 字段会按规则覆盖对应值；设置、全局扩展、订阅扩展和应用回写都有顺序。即使订阅原文正确，后续来源仍可能改写最终结果。若基础 config.yaml 没有残段，应检查自己的扩展配置和脚本，不能强行套用这次 issue 的处理步骤。

只有三份文件的对照支持上述路径时，才按项目成员在 #8122 的建议处理。先完全退出 Clash Verge Rev，包括菜单栏进程；确认已经备份基础 config.yaml。

再用文本编辑器从该文件中移除确认残留的顶层 dns 段，保留其他键和订阅原文。不要删除整个 config.yaml、dns_config.yaml、Profile 或应用数据目录，也不要直接手改会被重建的运行配置。

保存后重新启动 Clash Verge Rev，仍先让 TUN 保持关闭。检查运行配置是否恢复了原订阅预期的 DNS 字段，并先通过配置校验及系统代理做一次真实 HTTPS 请求。只有这一层正常，才短时间重新开启 TUN 测试。

报告者曾把完整 DNS 放进全局 Merge 作为临时规避，但官方文档说明扩展会按优先级覆盖订阅；直接复制他人的 DNS 或整段规则，可能覆盖自己的局域网、公司 DNS 和节点解析策略。本文不把全局 Merge 注入当作通用修复。若设备受组织管理、配置由他人统一下发，先联系管理员，不自行改受管配置。

先核对重新生成的运行配置：dns.enable、nameserver 与你预期的原订阅或扩展设置一致；不能只看界面上的 DNS 覆写开关。然后固定同一个 Profile 和节点，分别在系统代理与 TUN 模式下请求同一真实 HTTPS 网站，并在连接和日志中查看解析是否成功。

再完整退出并重新启动一次应用，重复 TUN 测试；如果只在本次会话有效，说明仍有配置来源在重启时写回。关闭 TUN 后还应确认普通网络恢复，不需要重启整台 Mac 才能联网。

不要以 DNS 检测页显示某个地址、TUN 开关保持亮起或延迟测试有数字作为唯一成功标准。能解析自己的目标域名、网页完整加载、连接记录符合预期，并且重启后仍保持，才构成完整验证。

如果移除残段后配置校验失败、原有分流被改变或 TUN 依然断网，先关闭 TUN，恢复修改前备份的基础 config.yaml，再重新启动应用。旧配置可能仍会触发本次 DNS 故障，所以恢复它的目的只是保住原设置和证据；临时联网用已经验证的系统代理或不接管 DNS 的普通网络。

若运行配置已经有完整 DNS，但域名仍失败，另查 nameserver 本身是否可达、当前网络是否有企业 DNS、是否有其他 VPN/TUN，以及第一条内核错误。不要为了消除报错而禁用系统安全保护、清空全部 Profile、删除整个应用数据目录或随机换公共 DNS。

向 #8122 反馈时，提供 macOS、Clash Verge Rev、Mihomo 版本，TUN/系统代理对照，三份配置中与 dns 相关的脱敏片段，以及重启前后结果。报告者提出的解释与项目成员的配置残留判断应分开记述；当前没有能够据此保证所有类似断网都已修复的正式版公告。