连接排障 · Clash 技术博客

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

Clash Verge Rev macOS 开启 TUN 后域名打不开？对照订阅、运行与基础配置的 DNS，确认是否残留 dns 段；备份后按官方建议移除并验证。

阅读正文返回博客
  • Clash Verge Rev
  • macOS
  • TUN
  • DNS
  • config.yaml
本文目录
文章作者
Clash 官方
发布日期
更新时间
预计阅读
约 9 分钟

订阅里的解析设置看起来完整，开启虚拟网卡后仍可能无法按域名访问。应用使用的是合并后的配置，需要找出哪个设置改写了解析内容。保留普通联网方式，保存订阅、基础文件和运行配置，再决定是否处理已确认的残留字段。

TUN 一开就无法解析：运行配置中的 dns 是否残缺？

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

应用运行的是合并后的配置。基础 config.yaml 若残留不完整的 dns 段，可能覆盖订阅原有解析设置；先用下表区分 DNS 残段、权限、接口与节点问题，再保存并对照三份文件。

域名解析、权限与接口错误的区别

观察到的证据优先判断
运行配置的 dns 只剩 enhanced-mode，基础 config.yaml 留有同样残段继续核对本文的配置覆盖路径
TUN 开关立即回落或日志出现 operation not permitted先检查 macOS 服务授权
日志先有 get empty name / interface not found先检查当前出口接口
系统代理和 TUN 都不能访问同一网站先查 Profile、节点与共同的 DNS 故障

关闭 TUN 恢复联网，保存订阅、基础文件与运行配置

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

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

v2.5.7/v2.5.8 中，到 Profiles（订阅）页，右键当前订阅卡片，选择“编辑文件”（Edit File）。只查看并复制 Profile 原文，关闭编辑器时不保存；“编辑信息”（Edit Info）是订阅信息表单，不能代替文件原文。

基础配置通常位于 ~/Library/Application Support/io.github.clash-verge-rev.clash-verge-rev/config.yaml。通过本机应用目录或文件管理器核对实际路径；这里查看的是基础配置，不是 dns_config.yaml 或运行配置。

查看合并结果时，点击同页右上角的文档图标“查看运行时订阅”（View Runtime Config）。该窗口只读显示应用生成的合并配置；它与订阅原文件、基础 config.yaml 不同，不要把基础文件当成运行配置。

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

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

三份配置中，哪一份改变了订阅 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 的处理步骤。

原订阅 DNS 完整，基础配置残缺，运行配置同样残缺

备份后只处理基础配置中的确认残段。

原订阅本身没有 enable 或 nameserver

先向订阅提供方确认原配置，不把故障归因于基础配置覆盖。

基础配置正常，运行配置却改变

检查全局/订阅扩展、脚本及应用设置的写入顺序。

运行配置 DNS 完整，仍无法联网

转查 DNS 上游可达性、规则、节点、接口和服务日志。

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

该 issue 已于 2026 年 10 月 2 日关闭；现有讨论包含详细复现和少量同症反馈，但关闭状态不等于已确认通用修复，也不能据此断言所有 Mac 或所有订阅都会出现同样故障。

报告者最初认为关闭“DNS 覆写”会剥掉订阅中的 dns。项目成员提出的解释是：基础 config.yaml 留有不完整的 dns 段，合并时盖过订阅 DNS；缺少 enable: true 会使内核 DNS 不可用。

官方扩展配置文档说明，DNS 覆写关闭时应用本身不改动订阅 dns。报告者的猜测与项目成员的残留判断应分别记述；是否需要移除残段，以三份文件的实际差异为准。

只移除基础配置中已确认残留的 dns 段

只有三份文件的对照支持上述路径时，才按项目成员在 #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 注入当作通用修复。若设备受组织管理、配置由他人统一下发，先联系管理员，不自行改受管配置。

系统代理、TUN 与重启后的域名访问都要通过

先核对重新生成的运行配置：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 相关的脱敏片段，以及重启前后结果。报告者提出的解释与项目成员的配置残留判断应分开记述；当前没有能够据此保证所有类似断网都已修复的正式版公告。

参考资料