Connectivity Troubleshooting · Clash Technical Blog

Mihomo Fake-IP reload fix: v1.19.33

Does a new domain take over an older domain's Fake-IP after a Mihomo configuration reload? Check the running core and DNS listener, compare queries within the same range, obtain the v1.19.33 fix through a supported channel, then verify mappings, connections and recovery.

Read the articleBack to blog
  • Mihomo
  • Fake-IP
  • v1.19.33
  • Configuration reload
  • DNS mappings
On this page
Published
Estimated reading time
About 9 minutes

Your configuration is unchanged, but pages sometimes disconnect or reach the wrong destination after a reload. Clearing the DNS cache may seem like the first step. With Mihomo's Fake-IP mode, check a more specific sequence first: an old domain keeps its address immediately after the reload, then receives another address after queries for new domains.

Why does an old domain change address after the reload initially looks fine?

The project's #3281 includes a macOS reproducer for v1.19.32 and alpha-9f053c4: reloading the same configuration retains mappings, but subsequent allocations for new domains can start again at the beginning of the pool and take over old addresses. This does not mean every reload immediately changes every Fake-IP.

A Fake-IP is a virtual address the core gives an application. The core must also map it back to the original domain. A stalled page or two different DNS answers alone cannot establish this defect; the reported causal connection to AdGuard stalls was also unproven.

Separate similar symptoms first

What you observeWhat to check next
After a reload within the same process and range, new queries displace retained mappingsCheck the version and compare before-and-after queries as described here.
Addresses change after a process exit, cache flush or change to fake-ip-rangeThose actions changed the conditions; the result cannot establish this defect.
The answer is a real public address, or the query never reaches the core's DNS serviceCheck the listener, query type, hosts entries and Fake-IP filters first.

What does v1.19.33 actually fix?

The v1.19.33 release notes include the fix from #3283. After copying the old mappings, the fixed source preserves both the allocation offset and cycle state only when the old and new pools cover the same range. This prevents allocation from restarting at addresses that were just retained.

The regression test checks that allocating an address to a new domain after copying the pool retains existing domain and reverse mappings. It does not promise that addresses never change: capacity eviction, range changes and process restarts require separate checks.

profile.store-fake-ip saves Fake-IP mappings. Enabling it does not mean this allocation-state fix is installed, and it is not a verified workaround for this defect. Do not toggle it or delete cache files just to run the comparison.

How do you query the actual Fake-IP without changing the conditions?

Use the client's core information or the current startup log to identify the Mihomo version actually running. The graphical application's version is not the core version; running mihomo -v in another directory does not prove the client uses that file.

Send queries to the actual dns.listen endpoint. The example uses 127.0.0.1:1053 on this computer; use it unchanged only if that matches the listener you verified. Otherwise substitute the server address and port. Do not change your listener configuration to match the example.

Record the conditions, then reload once

  1. Preserve the configuration and current state

    Keep an independent backup of the configuration and client data. Record the core version, address range, filters and persistence setting. Choose a time when interruptions are acceptable and pause automatic subscription updates so another configuration change does not interfere.

  2. Record an existing domain's address

    Use the A query below to record the Fake-IP for the old domain example.com. It must actually use this core's Fake-IP allocation. If a hosts entry or filter returns a real address, choose a domain suitable for the comparison.

  3. Reload the same configuration through the existing interface

    Use the configuration reload operation your client or service already supports. Keep the process and fake-ip-range unchanged; do not exit the application, flush the cache or select another configuration. Confirm that the operation actually reloads the core configuration.

  4. Query a new domain, then query the old one again

    Query a domain this core has not allocated before, then query the old domain again and compare addresses and the corresponding logs. example.net is only an example; if it was queried before, replace it with a domain you control that has not been queried.

Before-reload query example: replace the listener and domain before use
nslookup -type=A -port=1053 example.com 127.0.0.1

After reloading the same configuration, run the following two queries in order. If the tool is unavailable, use an equivalent DNS query tool already on your system. Do not substitute browser cache results or treat real addresses returned by a public DNS server as core mappings.

After-reload query example: replace the listener and domains; new, then old
nslookup -type=A -port=1053 example.net 127.0.0.1
nslookup -type=A -port=1053 example.com 127.0.0.1

A single new query that does not displace a mapping cannot prove an older core is unaffected. Existing allocations and query order influence the result. Record each domain, address and time. Do not force reproduction with large numbers of production-domain queries or mistake normal capacity eviction for this defect.

How do you obtain and actually run the fix?

First check whether the application or service supports updating its core separately. If it does, select a version containing this fix through its approved release channel and retain the original files and configuration. Otherwise wait for, or choose, a stable client package whose maintainer explicitly confirms inclusion. Do not overwrite application internals yourself.

The v1.19.33 release confirms inclusion of this fix, but a recently updated client does not prove its core was updated. Check the new startup log or core information afterwards to confirm that the intended version is actually running.

Establish a fresh comparison after updating

  1. Keep a recoverable original state

    Match the independent backup to the original version and configuration, and confirm how to restore it before updating. Do not overwrite your only backup or let another version write directly into your only data directory.

  2. Confirm the new process's running version

    Start the updated core as its maintainer requires. Check the version actually running, the configuration actually loaded and the DNS listener.

  3. Repeat the before-and-after queries within the new process

    An upgrade usually restarts the process, so the old and new processes need not assign identical addresses. Establish the old domain's mapping again first. Then, within the same new process, reload the same configuration, query a new domain and query the old domain again.

How do you verify the result without treating one success as a complete fix?

Check both mappings and real connections

  • Record the version of the core actually running, rather than only the graphical application's version.
  • Send A queries to the same dns.listen endpoint before and after the reload; the domains must not be excluded by hosts entries or Fake-IP filters.
  • Compare a reload within the same new process and address range, without flushing the cache, exiting the process or changing the configuration midway.
  • After a modest number of new-domain queries, retained mappings have not been displaced prematurely. Also check new requests from the relevant website or application.
  • Restore the original automatic update schedule and observe again. If it fails, keep version details, configuration differences and redacted query records.

If mappings remain intact but connections still fail, check the actual routing, upstream resolution and application connection records. Do not attribute every DNS or AdGuard failure to this fix. This article relies on the official report, fix and regression test; it does not replace a live reproduction in your client environment.

How do you roll back and retain useful evidence?

If the new version causes other compatibility problems, restore the saved original core or client through the same supported update mechanism, then restore the independent backup appropriate to that version. Stop the affected operation before switching so two versions do not write to the same data directory.

Rolling back may reintroduce this defect; it is not a final fix. After restoring the configuration and automatic update schedule, check the running version, DNS listener and real connections again. Do not hide unexplained differences by clearing your only cache or deleting subscriptions.

When reporting to the maintainer, include the full core version, operating system, reload method, actual address range, persistence setting and ordered before-and-after query results. Remove subscription credentials, secret, private domains and personal information. The original issue's status alone does not establish whether your installed package contains the fix.

References