Connectivity Troubleshooting · Clash Technical Blog

FlClash v0.9.2: clear DNS cache

Some sites stop working after a network change in FlClash? Use Tools → DNS queries in v0.9.2 to clear the core cache, distinguish system caches and Fake-IP, then compare the same domain, real requests and recovery steps.

Read the articleBack to blog
  • FlClash
  • v0.9.2
  • DNS cache
  • Network changes
  • Domain resolution
On this page
Published
Estimated reading time
About 8 minutes

After switching from Wi-Fi to mobile data, or changing a computer’s network, the node may still connect while some sites time out. An old DNS answer is one possibility; the new network, DNS upstream or node may also be responsible. Record a comparison before clearing anything.

Changed networks, but only some domains fail?

The FlClash v0.9.2 release adds manual DNS cache clearing and clearing on network changes. This guide follows that version’s interface and fixed source for Android and desktop clients. Cache clearing does not resolve every connection failure after switching networks.

When a cache comparison is useful

What you observeWhat to do next
The ordinary network works, but the same domain fails through FlClashKeep the same Profile, node and domain. Record the query, then clear once and compare.
The ordinary network also fails after FlClash stops handling trafficRestore the new network or system name resolution first. An application cache cannot repair connectivity.
One node fails, while another reaches the same domainCheck the node and outbound path first. An unreachable site alone does not establish a stale cache.
Fake-IP mappings behave unexpectedly just after configuration reloadInvestigate Fake-IP and reload behavior separately. This button does not reset the Fake-IP pool.

What does the button clear?

The DNS queries page calls clearDnsCache in the FlClash core, which ultimately runs dns.ClearAll(). It clears DNS answers held by the core and resets relevant DNS upstream client connections so subsequent queries can obtain fresh results.

The client core branch used by this release also makes desktop clients reread the system nameserver list. This does not run a Windows or macOS system DNS flush command, or guarantee that browser and other application caches are cleared.

Clearing DNS answers and clearing Fake-IP mappings are separate operations; the fixed source has a distinct FlushFakeIP method. Do not treat this as deleting the virtual address pool, or change fake-ip-range, reimport subscriptions or erase app data for this operation.

The DNS query list is an observation history. Clearing the cache does not delete those records. Existing entries do not mean the button failed: inspect new query times and actual requests rather than waiting for the list to become empty.

Record the same domain before clearing

Change one condition at a time

  1. Record the version and current network

    Confirm that the app is actually v0.9.2. Note the OS, network type, switch time, current Profile, node and existing DNS overrides. If an older version lacks this button, do not guess at a similarly named setting elsewhere.

  2. Check whether the ordinary network works

    Briefly stop FlClash from handling traffic and try the original destination on the same network. Test directly only where permitted. Pause work that requires a proxy; successful direct access does not prove the proxy has recovered.

  3. Return to the original configuration and record a new query

    Request the target with the same Profile and node. Find its domain on the DNS page under Tools and note A or AAAA, time, source, response code and answer. If there is no record, first check whether the request uses FlClash DNS.

The OS or browser may retain answers and connections. Without a new DNS entry, refreshing a page alone cannot show whether the core resolved it again. Compare fresh query records and restart that application’s request if needed, without changing several DNS settings at once.

Use Tools → DNS queries in v0.9.2

Clear once, then check immediately

  1. Open the DNS queries page

    Open Tools, select DNS queries, and confirm that the page contains query records. The broom button at the top has the tooltip “Clear DNS cache”. Navigation placement may vary with window width.

  2. Clear the cache once

    Click the broom and wait. Success says “DNS cache cleared”; failure says “Failed to clear DNS cache”. Success means this core operation returned successfully. You still need to test access to the site.

  3. Repeat the original request

    Keep the same network, Profile, node and DNS settings. Request the same domain again and compare the new time, source, response code and answer for the same record type. Then verify the actual HTTPS page or business request.

If clearing fails, retain the log and check whether the core is running; do not click repeatedly or delete all configurations. If the entry is missing, back up and check the official v0.9.2 release and OS support. Use the normal update channel, rather than replacing the app’s internal core yourself.

Why verify after automatic clearing?

Clearing on network changes is built into this release. Its source provides no automatic-clear switch that users must enable. This does not mean every Wi-Fi status message, page refresh or event on every platform runs the same operation.

On desktop, the relevant network callback clears DNS after about 200ms of coalescing only when the core is connected and the VPN-presence state has not changed. That operation does not directly close all active connections.

Android uses native network observation. Changes to the preferred network’s DNS list update the system DNS used by the core. Switching from an existing preferred network A to B follows resetNetwork, closing active connections before clearing DNS. Automatic clearing does not guarantee uninterrupted existing connections; desktop behavior cannot be assumed on Android.

If the problem remains after switching networks, compare one manual clear with the same target. Record local recovery only when fresh queries and real access support it. Do not repeatedly disconnect the network merely to force a callback.

How to verify beyond the success message

Checks after clearing

  • The version, network, Profile, node and DNS overrides are recorded, with no simultaneous configuration changes before and after clearing.
  • The same domain and A or AAAA record type have a new query time. Record the source, cache flag, response code and answer.
  • The IP need not change, and the first entry need not say cached “No”. Concurrent requests can fill the cache first, and a correct DNS answer may still be the same address.
  • The original HTTPS page or business request actually completes, with the expected outbound shown in connection records. A node latency number or VPN icon is insufficient.
  • Recheck the same target after a later natural network change. If the problem returns, correlate network, query and connection timestamps.

If fresh queries still time out, are refused or fail resolution, check the current network, DNS upstream, rules and node. A before-and-after difference alone does not establish the cache as the only cause. One clear is not a promise of a permanent fix.

If it still fails: recovery and reporting

The button cannot undo a cache clear; later queries rebuild it. If you only cleared the cache, keep the original Profile and DNS settings. Restore original values for any additional comparison changes. A failed clear does not require restoring a full application backup.

If an update causes other compatibility problems, stop the affected operation and use the original supported method to restore the corresponding version and separate backup. Avoid two versions sharing one data directory. After pausing traffic handling, check ordinary connectivity and keep proxy-dependent work paused.

Report the app and OS versions, network change and time, before-and-after queries for the same domain and record type, the clear result, and the real request’s outbound and error. Redact subscription tokens, passwords and private domains from public evidence; keep original backups locally.

References