Start your 3-day free trial
Sign up to experience all premium features at no cost.
*Available only to new users. Each user is limited to one trial.
Mihomo Fake-IP vs Redir-Host: Diagnose DNS Compatibility
Ryan Foster
October 11, 2026· 10 min read
Mihomo Fake-IP vs Redir-Host is a choice about the address returned to an application, not a choice between a safe and an unsafe internet. Fake-IP gives an application a synthetic address that Mihomo can associate with a domain; Redir-Host returns a resolved address. Diagnose compatibility by tracing the same domain through the resolver, application, capture path, and outbound connection.［1］［2］
Key Takeaways
- A synthetic DNS answer is a mapping token, not the website's public address.
- Browser DNS, application DNS, and the system resolver may take different paths.
- Change one mode or exception at a time, then check a fresh connection.
- Keep local services and management access working throughout the change.
When does Mihomo Fake-IP vs Redir-Host matter?
Use this guide for a Mihomo instance you administer, with the DNS fields checked against stable v1.19.32 and the official configuration reference. It is a documented diagnostic procedure, not an author end-to-end test or a promise that every client wrapper behaves identically. Record your actual core and wrapper versions; a wrapper may regenerate the effective YAML and overwrite an edit.［1］［3］
The planning overview for self-managed networks helps establish who owns that configuration and its recovery. If the real question is which applications enter the proxy, compare TUN coverage with system-proxy coverage before changing DNS. DNS mode cannot capture a connection that never reaches Mihomo.
Have a private backup, the previous resolver settings, and an independent management connection. On a shared machine, agree on a maintenance window and do not change another person's proxy. If an everyday proxy or VPN client is already in use, leave its state unchanged and use a separate authorized test device; overlapping capture layers make the comparison ambiguous.
Step 1: Fix the domain and the resolution path
Choose one public domain you are authorized to request and one local service you control. Record the hostname, record type, client, time, selected Mihomo profile, DNS listener, and the exact failure. A timeout, a certificate error, and an application refusing an address are different observations; write down which happened rather than calling all three a DNS leak.
For a local-only DNS listener at port 1053, this command asks that listener directly. Replace the documentation domain with your chosen hostname and the port with the actual listener. Run it only on the host where that listener exists; loopback on a second device is a different machine.
dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA
Save the answer type and TTL privately. Do not upload a subscription, complete configuration, or browsing log to a public checker. Compare this query with the system resolver and the failing application, keeping the network and domain fixed. A browser with its own encrypted DNS may not use the system resolver, so an explicit dig answer does not establish the browser's path.
Do not configure the operating system's normal DNS field with 127.0.0.1:1053: many such fields accept an address without a custom port. Use the already supported wrapper integration, or keep this as a direct diagnostic query. Publishing the listener on every interface simply to make the query work adds an unrelated exposure.［1］
Step 2: Read the effective mode and mapping
Inspect the configuration actually loaded by the core, including wrapper overrides. The following is a partial field example for an existing, working DNS setup, not a complete internet-proxy profile. Preserve your authorized upstream resolvers, routing rules, IPv6 policy, and existing exceptions.
dns:
enable: true
listen: 127.0.0.1:1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter-mode: blacklist
fake-ip-filter:
- 'printer.home.arpa'
Replace printer.home.arpa with the exact local hostname you manage, or omit this illustrative exception. In blacklist mode, a matching filter entry avoids a Fake-IP answer; it does not create a DNS record or select a reachable local resolver. Existing filter modes can have different meanings, so do not paste a blacklist list into a whitelist or rule-mode configuration.［1］
In Fake-IP mode, distinguish the address handed to the application from the destination eventually resolved or selected for the outbound connection. The mapping needs to remain meaningful to the Mihomo instance receiving the connection. A synthetic answer copied to another host, retained after a profile change, or sent through a bypass path can fail even when the public domain is healthy. Redir-Host changes this address behavior; it does not remove DNS policy or routing decisions.［2］
An address in 198.18.0.0/15 is not proof of public reachability or proof of malicious hijacking. Keep normal server-side SSRF protections: never broadly permit special-use or private destinations because a desktop proxy uses synthetic DNS. A server fetching a URL needs its own trusted resolution and destination validation; this desktop explanation grants no security exception.
Step 3: Separate Mihomo DNS compatibility failures
Use the same requested resource across application paths. Start new application connections rather than comparing an old browser socket with a fresh command-line query. Do not change browser encrypted DNS, the upstream resolver, capture mode, and DNS mode together; the result would not identify the cause.
| Observation | What to compare | What the result does not prove |
|---|---|---|
| Direct listener query returns a synthetic A record | Effective mode and filter match | That the browser uses this listener |
| Browser works but a native app fails | App resolver, proxy support, cached addresses | That all native apps require Redir-Host |
| A local printer name fails | Local DNS authority and exact exception | That all private names should use public DNS |
| A works but AAAA differs | DNS IPv6 setting and actual IPv6 route | That IPv6 traffic is protected |
| Both modes time out | Upstream reachability and bootstrap resolution | That switching modes can repair the upstream |
For Ubuntu resolver ownership and split DNS, follow the system-resolution troubleshooting path. For privacy claims, distinguish an address-format difference from a DNS request leaving the intended resolver path. Neither a synthetic answer nor a successful page load alone establishes where every lookup went.
For a LAN exception, verify that the authoritative local resolver still answers the hostname and that its returned address is reachable over the intended local route. Keep management and discovery traffic outside the experiment unless they are the explicitly authorized target. An mDNS name may use a different discovery mechanism from ordinary unicast DNS; a filter entry cannot replace that mechanism.
Step 4: Change one variable and repeat a fresh request
Make a private copy of the effective configuration and note how the wrapper persists changes. If evidence points to one local hostname, first try the narrow exception with its correct local resolver. If the application rejects synthetic addresses more broadly, compare enhanced-mode: redir-host while preserving the upstream, capture rules, and network.［1］
Validate the edited configuration using the selected core or wrapper's documented check before loading it. A parser success only establishes accepted syntax; it does not establish routing, credentials, or application compatibility. If the wrapper offers no clear way to recover the old profile, stop instead of experimenting on the only management path.
For fake IP troubleshooting, refresh only the test application's connections and relevant test cache through its documented controls. Persistent Fake-IP mappings and normal DNS caches are separate state. Do not delete a shared cache database, reset every application, or restart unrelated networking services to manufacture a clean comparison.
If the changed mode helps one application, retain the exact evidence: hostname, query path, answer class, application result, and unchanged controls. If it fails, restore the previous configuration before trying another hypothesis. To investigate capture and routing separately, use the Linux transparent-capture comparison.
Step 5: What reader verification is sufficient?
Use this acceptance table as expected behavior to check, not as results already observed by the author. Record each actual outcome and any untested branch. A local DNS answer, a proxy log entry, and a destination response are complementary observations; none substitutes for the other two.
| Check method | Expected observation | Failure action |
|---|---|---|
| Query the chosen listener for A and AAAA | Answers match the effective policy | Check loaded profile and resolver errors |
| Repeat the original app action with a new connection | Intended resource works through the recorded path | Restore the change and compare app DNS |
| Request the owned local service | Local identity and management remain reachable | Restore local DNS and the narrow exception |
| Inspect only the test flow in local logs | Domain and selected outbound fit the intended rule | Check capture and mapping ownership |
| Reopen the profile through its owner | The intended persistent setting remains | Fix wrapper persistence before keeping the change |
If the experiment also changes an internet exit, check that request's visible IP, and separately verify DNS, IPv6, and failure behavior. An IP-check page describes its own request, not all applications. Do not infer anonymity, speed improvement, or universal coverage from this diagnostic.
Step 6: Restore configuration and test-local state
Load the saved profile through the same owner that applied the change. Restore any test-only resolver or application-DNS preference you deliberately changed, then close the test connections. Remove only the exception added for this experiment if it was not retained intentionally.
Clear only test-related cached entries where the application supports that scope. If a cache cannot be cleared selectively, wait for its documented expiry or use an isolated test profile instead of deleting shared state. Confirm the original DNS answer class, local service access, and management connection after recovery.
Finally remove temporary detailed logs and protect any retained diagnostic record. A backup containing proxy credentials is still a credential-bearing file. If recovery cannot be confirmed, stop further changes and use the independent management channel; do not compensate by disabling the firewall or another proxy.
Summary
- Identify the resolver and capture path before comparing address modes.
- Keep upstream policy stable while testing a mode or exact exception.
- Verify the original application and local services with fresh connections.
- Restore configuration and test-local cache state before another experiment.
FAQ
Does a Fake-IP answer mean DNS hijacking?
A synthetic answer can be intentional when the application uses your configured Mihomo DNS listener. Confirm the resolver owner and effective policy before attributing the address to an attacker.
Is Redir-Host always more compatible?
Redir-Host can help an application that cannot use synthetic destinations, but compatibility also depends on resolution, capture, and routing. Compare the failing task rather than assuming one universal winner.
Can a fake-ip-filter entry fix every local hostname?
A filter changes synthetic-address handling; it does not supply an authoritative local record. Keep the appropriate LAN resolver and route, and test the exact service identity.
Why does dig disagree with my browser?
A browser may use its own encrypted resolver or an existing connection. Compare a fresh browser request with the actual DNS setting instead of treating a direct listener query as browser evidence.
Should I disable IPv6 to simplify the test?
Do not disable IPv6 as a universal repair. Record A and AAAA behavior and the available IPv6 route; a missing AAAA answer does not establish how every application connects.
May a server allow Fake-IP ranges through its SSRF filter?
A desktop proxy mapping does not make special-use addresses safe server destinations. Preserve destination validation and use a trusted server-side resolution path rather than exempting the range.
Must I clear every cache after changing modes?
Refresh test connections and the relevant cache through documented controls. When selective clearing is unavailable, wait for expiry or isolate the test rather than destroying shared application state.
Disclaimer: The procedure is based on the official references below. No complete author deployment or compatibility test is claimed; apply changes only to an authorized environment with a recovery path.
Sources:
- Mihomo — DNS configuration — https://wiki.metacubex.one/config/dns/
- Mihomo — DNS resolution process — https://wiki.metacubex.one/config/dns/diagram/
- Mihomo — v1.19.32 configuration source — https://github.com/MetaCubeX/mihomo/blob/v1.19.32/config/config.go
Sources checked 11 October 2026.
Related articles:
