Clash Verge Rev TUN breaks DNS on macOS? How to fix it

Clash Verge Rev issue #8122 describes a macOS device running v2.5.6 in service mode with Mihomo v1.19.31. As soon as TUN was enabled, even sites that normally worked directly could no longer be opened by domain name. The reporter saw only dns.enhanced-mode: redir-host in the runtime config.

The issue remains open, with one detailed reproduction and a small number of similar reports. That is not evidence that every Mac or subscription is affected.

The reporter initially suspected that turning off “DNS Override” caused the app to strip dns from the subscription.

A project contributor pointed to a more specific path in the issue comments: an incomplete dns block left in the base config.yaml overrides the subscription DNS when the runtime config is generated. The leftover block lacks enable: true, so the core DNS is unavailable.

The official extension-config docs also say that the app does not change subscription dns when DNS Override is off. This guide follows that checkable leftover-config path, without treating the reporter's initial theory as a project conclusion.

Use this guide when ordinary connectivity or the same node through the system proxy works with TUN off, domain resolution fails with TUN on, and the base and runtime configs show the corresponding difference.

If the first log error is operation not permitted, get empty name, or interface not found—or the same node also fails through the system proxy—check permissions, the outbound interface, or the node first. Do not edit DNS yet.

Turn off TUN first and check whether ordinary macOS connectivity returns immediately. If the system proxy worked before, use it temporarily. If you still cannot get online after quitting the client, check system network settings for a leftover proxy or DNS setting. Do not repeatedly enable the broken TUN just to test it.

Before changing anything, save the original subscription or Profile, the base config.yaml, and the runtime config generated by the app. Record the current client and core versions.

The base config is usually at ~/Library/Application Support/io.github.clash-verge-rev.clash-verge-rev/config.yaml. Confirm the actual path in the local app directory or file manager.

Do not mistake the base config for the subscription file, dns_config.yaml, or the generated runtime config.

Subscriptions and configs may contain node credentials. Keep backups in a secure local location and share only redacted copies in public reports.

Record three states on the same network: whether domains resolve with TUN off, the first DNS or TUN log entry after turning it on, and whether connectivity returns when TUN is turned off. This helps distinguish a DNS-takeover problem from browser cache, a failed node, or system permissions.

First check whether dns in the original subscription is complete, especially enable: true, nameserver, and your other existing resolution settings. Next, see whether the base config.yaml contains only dns.enhanced-mode: redir-host or another incomplete fragment.

Finally, check whether the generated runtime config resembles that fragment instead of retaining the subscription DNS. Do not delete config merely because “DNS Override” is off before comparing all three files.

The official Mihomo docs define dns.enable as the switch for core DNS and list resolution fields such as nameserver. TUN's dns-hijack passes DNS queries to the core.

If the runtime config has no usable DNS path while TUN still takes over queries, domain requests may fail. This explains why the system proxy or direct connection can work before TUN takes over, but whether your case matches #8122 still depends on the differences in your own configs.

The official Clash Verge Rev docs say that, starting with v2.5.5, dns fields written by extension config override the corresponding values according to its rules. Settings, global extensions, subscription extensions, and app write-back have an order. Later sources can therefore change the final result even when the subscription text is correct. If the base config.yaml has no leftover block, inspect your extensions and scripts rather than forcing this issue's fix onto your setup.

Follow the project contributor's guidance in #8122 only if comparing all three files supports this path. Fully quit Clash Verge Rev, including its menu-bar process, and confirm that the base config.yaml is backed up.

Then use a text editor to remove only the confirmed leftover top-level dns block from that file. Keep every other key and the original subscription. Do not delete the whole config.yaml, dns_config.yaml, Profile, or app data directory, and do not hand-edit the generated runtime config that the app will rebuild.

Restart Clash Verge Rev with TUN still off. Check whether the runtime config again contains the DNS fields expected from the original subscription. Validate the config and make one real HTTPS request through the system proxy first. Only when that works should you briefly enable TUN for a test.

The reporter temporarily worked around the problem by putting complete DNS settings in a global Merge. But the official docs explain that extensions override subscriptions in priority order. Copying someone else's DNS or entire ruleset could override your LAN, corporate DNS, and node-resolution policy. This guide does not recommend injecting a global Merge as a general fix. On a managed device or centrally provided config, contact the administrator instead of editing managed settings yourself.

First inspect the regenerated runtime config: dns.enable and nameserver should match what you expect from the original subscription or extension settings. Do not rely only on the DNS Override switch in the UI. Then keep the same Profile and node selected, request the same real HTTPS site through both the system proxy and TUN, and check connection records and logs for successful resolution.

Fully quit and relaunch the app once more, then repeat the TUN test. If the fix lasts only for the current session, another config source may be writing the old value back at startup. After turning off TUN, confirm that ordinary connectivity returns without restarting the whole Mac.

A DNS test page showing a particular address, a lit TUN switch, or a numeric latency result is not enough on its own. Complete verification means your target domain resolves, the page loads fully, connection records match expectations, and the result survives an app restart.

If config validation fails after removing the fragment, routing changes unexpectedly, or TUN remains offline, turn off TUN first. Restore the pre-change backup of the base config.yaml and restart the app. The old config may still trigger this DNS failure; restoring it is only to preserve your settings and evidence. For temporary connectivity, use the system proxy you already verified or an ordinary connection that does not take over DNS.

If the runtime config already has complete DNS settings but domains still fail, check whether nameserver is reachable, whether this network has corporate DNS, whether another VPN/TUN is active, and the first core error. Do not disable system protections, erase every Profile, delete the entire app data directory, or randomly switch to a public DNS merely to silence an error.

When reporting to #8122, include macOS, Clash Verge Rev, and Mihomo versions; a TUN versus system-proxy comparison; redacted dns excerpts from all three configs; and results before and after restart. Keep the reporter's theory distinct from the project contributor's leftover-config diagnosis. There is currently no official release announcement establishing that every similar outage has been fixed.