Installation and Migration · Clash Technical Blog

FlClash v0.9.0: DNS and profile migration

Missing DNS toggles or custom overrides in FlClash v0.9.0? Back up, migrate DNS fields and independent custom profiles, verify final configs after switching and restarting, and restore a working subscription if migration fails.

Read the articleBack to blog
  • FlClash
  • v0.9.0
  • DNS
  • NTP
  • Custom profiles
On this page
Published
Estimated reading time
About 10 minutes

After upgrading FlClash to v0.9.0, the DNS page no longer has its old master override switch, and groups or rules from custom overrides may be missing. Following the old workflow can produce unexpected settings. First identify which kind of profile each setting affects, then plan the migration.

Why did the old override controls disappear?

The v0.9.0 release explicitly removes the DNS/NTP override toggles and legacy custom overrides. These are configuration changes: a missing switch does not establish that a subscription has failed, and the upgrade does not promise to convert old custom content into a new profile. DNS resolves domain names to addresses; NTP synchronizes time. Identify which settings you actually changed.

These steps are for desktop and Android users migrating from an older release. Labels may differ with the interface language. If the menus or version differ, check the installed version rather than following another client’s menu paths.

Identify the type of profile first

What you want to changeWhere it applies in v0.9.0
DNS for URL or file profilesThe app DNS page overrides selected fields in these profiles. Unselected fields still participate in merging the original configuration with defaults.
DNS/NTP in a custom profileConfigure these inside that custom profile. DNS is on its main content page and NTP is under More. Do not assume the app DNS page also overrides it.
Groups and rules from legacy custom overridesRebuild these in an independent custom profile. The new profile does not automatically layer onto the active subscription.

Keep a backup and a working profile before upgrading

Before upgrading, open Tools, then Backup and restore, and choose Backup under Local. Copy the exported file outside the app data directory. Separately preserve the original subscription address or file, custom groups, rules, and their order. Backups may contain private addresses or credentials; redact them before sharing.

The legacy custom-override migration removes the groups, nodes, and rules saved for those overrides, leaving the original subscription to run as a standard profile. Restoring an old backup in v0.9.0 also reads and migrates old data; it does not guarantee that legacy custom overrides reappear.

If you have already upgraded without an old copy, back up the current state and keep any working subscription. Do not delete data or repeatedly overwrite your only copy. Missing values can only be recovered from existing files, screenshots, or independent backups; this guide cannot reconstruct lost rules.

Complete these three checks before and after the upgrade

  1. Record the app version and active profile

    Check the actual FlClash version. Record the active profile name, selected node, proxy mode, and system proxy or TUN state. Preserve the previous DNS settings and any NTP values you need to keep.

  2. Check that the backup was saved

    Find the exported file, copy it to an independent location, and confirm it is readable and not empty. Keep the original backup unchanged and use a copy for later tests. Data available only inside the app is not an independent backup.

  3. Choose a time when a brief interruption is acceptable

    Use only the project's official Release for your platform. Keep the original subscription, then migrate and test one change at a time. Do not reset DNS, rules, the core, and every proxy control together.

How do per-field DNS overrides affect the original profile?

Global DNS settings affect URL and file profiles only. Open Tools → Advanced configuration → DNS, use Add override entry to select a field, and edit its value. To change only nameserver, add only nameserver and leave the other fields unselected.

To undo an override, remove its entry on the DNS page and check Final config again. Changing the value to an address that looks like a default still leaves an override in place; it does not hand control back to the subscription. Record the existing selected fields so you can undo this test.

Unselected fields do not guarantee a final file identical to the subscription: the implementation also merges DNS defaults. When the original dns is not enabled, it supplies defaults for enabling it, fake-ip, and nameserver. Compare the original configuration, selected fields, and Final config instead of relying on the missing switch.

For a standard profile, open More in its profile menu to reach Final config; a custom profile offers Final config directly in its menu. Check enable, enhanced-mode, and nameserver in the dns section. The downloaded subscription text is not necessarily the effective runtime configuration.

Change one DNS field at a time

  • Preserve the original values and list of selected fields.
  • Add and edit the required field, then confirm its value in Final config.
  • If the result is wrong, remove the entry you just added and recheck Final config and access to the same domain.

Rebuild legacy custom overrides as an independent profile

Open Profiles, Add profile, then Custom. This creates an independent Profile. Only one profile is active in the list, so creating an empty custom profile does not automatically give it the original subscription's nodes, groups, or rules.

The new custom profile can reference nodes from the original URL or file profile, but it does not copy that profile’s groups or rules. Keep the original profile and reference only the providers you need. Follow the steps below to add them.

To change custom DNS, use that profile’s own DNS page. For NTP, open More, then NTP, and set the selected fields.

Finish rebuilding before activating the new profile

  1. Give the new profile a distinct name

    Keep the original subscription as a working profile and name the new migration copy clearly. Do not delete the subscription or treat the new profile as an override layer that can be enabled alongside it.

  2. Rebuild groups, node references, and rules

    Open node selection in the new profile’s proxy group, choose Add nodes, and select the original profile name under Proxy providers. Rebuild rules from your records and point them to existing groups. The External resources page is for checking or editing referenced providers; it does not import a complete subscription. Keep using the original subscription if old values are missing or resources fail to load.

  3. Check content warnings and Final config

    Fix missing resource references, configuration errors, and empty groups, then check groups and rule order. NTP merges only selected fields. Check required fields and values against your original configuration; an empty selection does not recreate all previous NTP settings.

  4. Select the new profile in the list

    Activate the custom profile only after its content is complete, then test a real connection. The selected item, Final config, and the node actually used must all belong to the same Profile.

Verify profile switching, restarts, and real requests

A successful save or node latency test confirms only part of the workflow. Use the same profile, node, and destination domain for comparison. Inspect Final config and connection logs, then check whether the rules you depend on actually match.

App DNS fields affect URL and file profiles. If you keep several such profiles, switch through each and check it; test custom profiles separately. One working profile does not establish that the others preserve their intended DNS behavior.

Post-migration checklist

  • The app version and active profile are correct; the original subscription and independent backup are still available.
  • The final dns values for enable, enhanced-mode, and nameserver match the selected fields and your original configuration expectations.
  • Frequently used domains resolve and web pages or apps complete real requests, with no repeated resolution or configuration errors in the logs.
  • Custom groups contain selectable nodes, important rules match correctly, and no external resource references are missing.
  • After switching to other URL or file profiles, recheck the effect of app DNS fields. Verify custom DNS/NTP separately.
  • After fully quitting and restarting, the profile, selected fields, node, and result of the same request remain correct.

If migration fails, return to a working subscription first

Switch back to the original subscription you kept, remove the DNS override entries added during this test, and retry the same request. If TUN still cannot connect, pause TUN. Use the system proxy temporarily only if the previous setup already supported it; its coverage differs and does not prove TUN is repaired.

Before returning to an older version, save the new state, then use the official older app for your platform with a pre-upgrade backup. Open Local restore under Tools, Backup and restore. To recover old groups and rules, check Restore all data. Older versions may not read newer backups or databases; never let the old app overwrite your only data copy.

Restoring an old backup in v0.9.0 still performs migration. Restore all data does not automatically revive legacy custom overrides. Confirm the backup version, contents, and restore mode first, and keep the original file. If restoration fails, do not repeatedly overwrite the working state with the same copy.

Without a reliable old backup, keep the original subscription working and rebuild missing content one item at a time, or wait for a documented migration method. Report the actual version, profile type, selected DNS/NTP fields, redacted Final config snippets, and the shortest useful error log. Do not send a subscription Token, credentials, or a complete private backup.

These menus and migration behaviors follow the official v0.9.0 release, pinned source code, and migration tests; upgrades have not been verified on physical devices across every platform. If menus differ or migration problems remain, keep the actual logs and follow subsequent project guidance.

References