Clash Fake-IP Mode Explained: DNS Mapping, Setup, and Use Cases

How Fake-IP Works: Return a Mapped IP, Then Route by Domain

When Fake-IP is enabled, a DNS lookup for a website may return 198.18.x.x. This is usually expected; it does not mean the website has moved to that address. Clash's DNS module assigns a synthetic IPv4 address from a configured pool and stores a mapping between the domain and that address. When an app connects to it, the core intercepts the connection and looks up the original domain in the mapping.

The typical process has four steps. Understanding the full flow is more useful for troubleshooting than simply memorizing enhanced-mode: fake-ip.

1. An app requests an A record for www.example.com, and the query reaches the core's DNS service.
2. The DNS module assigns an address from the pool, such as 198.18.0.2, and records the domain mapped to it. The specific address assigned can vary.
3. The app connects to the synthetic address on TCP port 443. The traffic reaches the core through TUN or another transparent interception mechanism.
4. The core recovers the domain and selects an outbound route based on the rules. A direct or proxy connection then resolves the real address and connects as needed.

Fake-IP makes the domain available to domain-based rules when a connection is established, reducing reliance on local real DNS answers in some cases. It does not eliminate the need for real DNS in every connection: direct destinations, rules that need IP information, and proxy server hostnames may still trigger lookups. Fake-IP is not an encryption protocol and does not turn plaintext DNS into encrypted DNS.

Fake-IP vs. redir-host: DNS Answers and Domain Recovery

redir-host returns the real address resolved by the upstream server, while fake-ip returns a synthetic address for eligible queries. Both modes can work with routing rules, but apps receive different addresses and the core obtains the domain in different ways.

These modes do not have a fixed speed ranking. Initial lookup latency, the proxy server's DNS environment, and whether rules trigger IP lookups can all affect connection times. For a meaningful comparison, run repeated tests on the same network, through the same node, and against the same site—not just one page load.

mihomo DNS Configuration: Minimal Example and Requirements

The following is a mihomo DNS snippet, not a complete configuration with proxies and rules. It listens on 127.0.0.1:1053 so you can test it independently. Standard system DNS settings usually accept only a server address and use port 53 by default, so you generally cannot enter port 1053 as the system DNS server.

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "localhost"
    - "*.lan"
    - "*.local"
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

• enable turns on the built-in DNS service. Setting a mode without enabling DNS will not produce the expected mapped responses.
• listen sets the listening address and port. A loopback address is accessible only from the local machine; it does not automatically serve the entire LAN.
• ipv6: false simplifies AAAA query handling in this example. It does not disable the operating system's IPv6 adapter or routing.
• fake-ip-range defines the synthetic IPv4 pool. Check the range against existing VPNs, test networks, and routing plans to avoid overlaps.
• nameserver specifies the upstream server for queries that need real DNS resolution. The IP addresses in this example use traditional DNS, so the upstream must be reachable from your current network. Encrypted DNS requires separate configuration.

Check These Three Things Before Applying the Configuration

1. Check which core is actually running. Review the client's core information and startup logs. Clash, Clash Meta, and mihomo do not support exactly the same fields, so do not copy newer options into an older version without checking compatibility.
2. Make sure you are editing the active configuration. Subscription files may be overwritten during updates. Prefer the client's override or merge feature, then inspect the final configuration after reloading it.
3. Make sure both DNS and connections reach the core. A successful query to port 1053 only confirms that the DNS service is available. Connections to synthetic addresses also need to be intercepted by TUN or another transparent forwarding mechanism.

fake-ip-filter: Exclude Only Domains That Need Real Addresses

With mihomo's default blacklist filtering behavior, domains matching fake-ip-filter do not receive Fake-IP addresses; they use real DNS resolution instead. This is not a proxy rules list and does not select DIRECT or a proxy group. The outbound route is still determined by routing rules and other configuration.

The example above uses *.lan and *.local for common LAN suffixes. Check the documentation for your core to confirm supported domain patterns and special rules. If your configuration sets fake-ip-filter-mode, verify its behavior first before interpreting the filter list.

Add entries for specific issues; don't copy a long list wholesale

• Corporate intranet domains: If an internal service needs to resolve to 10.20.0.15, start by excluding its full domain name. Make sure queries are also sent to corporate DNS; otherwise, the real lookup may still return no result or the wrong address.
• Apps that validate destination addresses: Some remote access tools, device discovery apps, and game components check DNS responses. Test the specific domain causing the issue before widening the match.
• LAN device names: Printers, NAS devices, and casting devices may use local domain names, but discovery can also rely on mDNS multicast, broadcast, or other protocols. Filtering a domain only addresses the DNS response.

If only nas.home.arpa fails, try adding that exact name first; it is easier to verify than excluding the entire suffix. The broader the exclusion, the more connections use real DNS resolution—and the more important it is to maintain correct intranet DNS and routing rules. NTP domains do not need to be excluded across the board, either. Add an exception only when a device or app has a reproducible compatibility issue, and target the time server domain it actually queries.

How to Test: Check DNS Responses, Connections, and Rules Separately

Do not rely on whether a page opens in your browser. The browser may use its own secure DNS or have a cached address, so a working page does not prove it used the Fake-IP path. First send a test query explicitly to the local DNS server, then inspect the app's connection.

Step 1: Send an Explicit A Record Query to the Core

# macOS / Linux: dig must be installed
dig @127.0.0.1 -p 1053 www.example.com A

# Check the AAAA response too, and verify the IPv6 setting in the example
dig @127.0.0.1 -p 1053 www.example.com AAAA

If the A record falls within the configured 198.18.0.0/16 pool, the query received a mapped address. Do not expect it to always be 198.18.0.2, and do not add the response manually to your hosts file. Test filtered domains separately; they should return a real address from the upstream server or an appropriate DNS status—not an address from the pool.

Step 2: Clear Old Caches, Then Test the Same Destination

# Windows: run this in a terminal
ipconfig /flushdns

# Linux systems using systemd-resolved
sudo resolvectl flush-caches

# macOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

These commands clear the system's DNS cache, but may not clear caches held by browsers, apps, or the core. Close and reopen the test app; if needed, clear the DNS cache in the client, then test with a new connection. After restarting the core, old synthetic addresses may no longer map to the same domains, so existing browser connections may briefly fail.

Step 3: Check the Domain and Outbound Route in Connection Logs

Check the client's connection list or logs to confirm the destination domain, matched rule, and outbound route. For more detail, temporarily set log-level to debug, then restore your usual level after testing. Before sharing logs, remove subscription URLs, access tokens, proxy credentials, and sensitive domains.

Common Issues: Troubleshoot in Order of the Connection Flow

If real DNS resolution also fails, first check whether the upstream DNS server is reachable—do not just expand fake-ip-filter. If DNS works and the connection log shows the correct domain but the proxy connection times out, investigate the proxy node and outbound rules next. Fake-IP is early in the connection flow; it cannot fix an unavailable node or invalid proxy credentials.

Queries may bypass the core's standard DNS entry when using browser Secure DNS, Android Private DNS, or an app's built-in DoH. Hijacking port 53 does not handle every DNS request sent over HTTPS. For testing, use a single resolution path first, then decide which DNS setup to keep. Avoid changing multiple variables at once.

When to Use Fake-IP and How to Roll Back

Fake-IP is a good option to test first on desktop systems where TUN is already stable and rules need to route by domain. For corporate VPNs, complex LANs, or tools that must display the real destination IP, check routing and DNS requirements first and keep redir-host if needed. On Android, the VPN interface is often shared with other VPN apps, so changing DNS mode alone will not resolve interface conflicts.

1. Start with a targeted fix: For a single failing domain, document how to reproduce the issue, try an exact-match filter, and verify the real DNS response.
2. Then check interception coverage: If many connections to synthetic addresses time out, fix routing, DNS interception, or permissions instead of adding more filter entries.
3. Consider switching modes last: Test enhanced-mode: redir-host only after confirming that an app needs a real address or the network cannot reliably intercept synthetic addresses.

Save a recoverable copy of the configuration before switching modes. After the change, reload the configuration and clear caches. Judge the result by three things: DNS responses match the selected mode, connections match the correct rules, and everyday apps and intranet services work reliably. A minimal, well-understood configuration is easier to maintain than a growing list of filters from unknown sources.