Clash Verge Rev: macOS TUN breaks DNS

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.

The app runs the merged configuration. An incomplete dns block left in the base config.yaml may override the subscription’s resolution settings. Use the table below to distinguish a DNS fragment from permission, interface, or node issues, then save and compare the three files.

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.

In v2.5.7/v2.5.8, open Profiles, right-click the current subscription card and choose Edit File. View and copy the Profile text, then close the editor without saving. Edit Info opens the subscription information form, not the file contents.

The base configuration is usually at ~/Library/Application Support/io.github.clash-verge-rev.clash-verge-rev/config.yaml. Check the actual path in the app directory or file manager on your machine. This is the base configuration, not dns_config.yaml or the runtime configuration.

To view the merged result, click the document icon labelled View Runtime Config at the top right of the same page. This read-only window shows the merged configuration generated by the app. It is distinct from the subscription file and base config.yaml; do not treat the base file as the runtime configuration.

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.

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 was closed on 2026-10-2. The discussion contains a detailed reproduction and a few reports of the same symptoms, but a closed status does not establish a general fix or mean that every Mac or subscription will experience the same failure.

The reporter initially thought that turning off DNS overrides removed dns from the subscription. A project member instead explained that an incomplete dns block in the base config.yaml overwrote subscription DNS during merging; without enable: true, core DNS was unavailable.

The official extension-configuration documentation says the app does not itself change subscription dns when DNS overrides are off. Distinguish the reporter’s guess from the project member’s residual-configuration explanation. Decide whether to remove a fragment from the actual differences between the three files.

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.