On this page
A switch turning off again may be protection after subscription changes, or a confirmed choice that was not remembered. Keep the subscription fixed, save the relevant fields, and distinguish the switch state from actual resolution results. Trying to keep the switch on at all times can hide a source change that needs fresh confirmation.
DNS override was confirmed: why does it still switch off after restart?
“DNS override” writes DNS values from the Clash Verge Rev settings page into the core configuration. The core is the program that handles connections; dns.enable controls its name-resolution function and differs from the override switch. If the subscription supplies protected resolution settings, the app asks for confirmation so local values do not unexpectedly prevent nodes or websites from working.
Keep the same subscription and save its protected DNS values and override state before and after restarting. This fix applies when those values are unchanged and the override was confirmed, yet it switches off after restart. A subscription update that changes protected fields, or switching to another unconfirmed subscription, can still legitimately require fresh confirmation.
Official issue #7996 describes this on macOS v2.5.4; #8024 describes having to reconfirm after every restart on Windows v2.5.5. The Clash Verge Rev v2.5.7 Release explicitly lists a fix. These reports do not show that every OS or every older version is affected.
If domains fail to resolve after TUN is enabled and only an incomplete dns section remains in the runtime configuration, read this site’s macOS TUN DNS residual-configuration troubleshooting guide. This is a separate configuration-generation problem described in issue #8122; you cannot draw a conclusion from this v2.5.7 fix alone.
Is this a restart bug or a safeguard after a subscription update?
First record the Clash Verge Rev version, selected subscription name, and DNS Override state on the settings page. If your connection is already down, turn off TUN and restore ordinary connectivity or a previously working system proxy. Avoid repeatedly changing DNS while offline.
Before changing settings, back up the current subscription, any extension configs you wrote, and the app settings. Record the DNS values you need to keep from the override page. Subscriptions may contain node passwords and subscription tokens; keep backups local and redact them before sharing a report.
Inspect dns in the raw content of the currently selected subscription. In the v2.5.7 tagged source, only nonempty proxy-server-nameserver, proxy-server-nameserver-policy, and nameserver-policy values are protected sources requiring confirmation.
A nameserver field alone, an empty list, an empty mapping, or an empty string does not trigger this source check. The condition is not simply “the subscription contains any dns field.”
Compare the actual values of those three fields and the subscription identity before and after restart. If the subscription updated in the background, you switched subscriptions, or a protected value changed, assess whether the new content needs confirmation. Changes to unrelated fields or a different mapping-key order should not invalidate confirmation for the same subscription.
This section records the current version’s behavior. Enable local DNS overrides and read the warning only if you actually need to replace the subscription’s resolution settings. With the same subscription left unchanged, save the confirmation result, switch state, and runtime configuration for comparison after upgrading.
Subscription and field comparison results
| What you observe | Next step |
|---|---|
| The confirmed override turns off after restart with the same subscription and unchanged protected fields | This matches the fix in this guide. Check your version and update to v2.5.7. |
| A subscription update changes the protected fields, or you select another subscription for the first time | Confirmation is required again; compare the new content before deciding to override. |
| The subscription has only nameserver, with none of the three nonempty protected fields | This does not trigger this safeguard. Check settings persistence, extensions, and logs separately. |
| The override stays on, but domains still fail to resolve when TUN is enabled | Inspect the running config and DNS upstreams. Do not treat switch persistence as the cause of a TUN failure. |
How do you apply the v2.5.7 fix while keeping subscription DNS protection?
Verify v2.5.7 on the Clash Verge Rev project's official Releases page, then update using the normal method for your device. Avoid unverified mirrors, do not erase the app data directory, and do not edit the generated running config by hand. Keep your pre-update subscription and extension backups so you can compare the DNS that actually takes effect.
After upgrading, keep the same subscription and confirm that its three protected DNS fields have not changed. If you need a local override, enable it and confirm the risk once, then follow the restart checks in the next section.
The v2.5.7 tagged source stores confirmation for each subscription. Its tests cover keeping DNS Override on after restart for the same subscription and protected source, and turning it off when that source changes. The fix remembers valid consent without removing subscription DNS protection. Another unconfirmed subscription may have its override off; when you switch back, unchanged consent for the original subscription should remain valid.
The official extension-config docs say that, when DNS Override is on, populated dns fields and hosts on the override page replace the corresponding subscription fields. When it is off, this switch does not make the app change the subscription's dns. Global extensions, subscription extensions, and scripts can still alter the result later in the config chain. If the switch stays on but resolution differs from what you expect, inspect the running config and extension chain instead of repeatedly toggling it.
Restart the app twice with the same subscription; DNS override should stay enabled
First confirm you are using the official v2.5.7 release and that the selected subscription and protected DNS fields match your pre-test baseline. After turning on DNS Override and confirming once, fully quit and restart twice. The override should stay on for this subscription both times.
Inspect dns in the running configuration to confirm that the override values you entered are present, then use the same fixed node to open a real HTTPS site. On Windows, confirm that the actual service component contains the security fix before enabling TUN; keep an unverified older service disabled.
If you need TUN, first confirm that system proxy or ordinary network access works. Once the required permissions and service conditions are met, briefly enable TUN and check domain resolution, complete page loading and connection logs.
If you have a second subscription, check its own override state when you switch to it, then switch back. Do not mistake the automatic shutoff for an unconfirmed second subscription for lost settings on the first. A real change to protected DNS content should trigger confirmation again; do not bypass this safeguard just to keep the switch “always on.”
If overrides still disappear or networking fails, restore the original settings and retain evidence
First turn off TUN and disable local DNS overrides so the app generates its runtime configuration using the current subscription’s DNS according to the official documentation. Confirm that normal networking or the previously verified system proxy is restored. If you also changed extensions or the subscription, undo those changes using the prior backup, then restart and check the runtime configuration. Disabling overrides only removes local overriding; it does not disable core DNS or guarantee that the original subscription is correct.
Do not edit confirmation values in verge.yaml by hand to force the switch on, paste in unknown DNS servers, clear Profiles, or delete the entire app data directory. If v2.5.7 still turns the switch off for the same subscription with all three protected fields unchanged, report the OS and client version, whether the subscription updates automatically, switch states before and after restart, redacted relevant fields, running-config differences, and logs in a project issue.
If the switch stays on but TUN still breaks connectivity, investigate the DNS config chain, upstream resolution, node, and interface separately. Do not combine that with this persistence bug. Our separate macOS TUN DNS residual-config guide covers diagnosis and rollback when the evidence matches that case.
References
- Clash Verge RevClash Verge Rev v2.5.7 official fix for DNS Override turning off after restart
- Clash Verge RevReport #8024: DNS Override repeatedly turns off after restart in v2.5.5
- Clash Verge RevReport #7996: DNS Override setting is lost after restart in v2.5.4
- Clash Verge Revv2.5.7 implementation and tests for protected DNS fields and per-subscription confirmation
- Clash Verge Rev DocsClash Verge Rev extension-config and DNS Override precedence
