1. Fake-IP Changes DNS Responses, Not Your Proxy Exit

In Clash or Clash Meta (now called mihomo), dns.enhanced-mode determines how the built-in DNS resolver answers queries. The most common options are fake-ip and redir-host. Neither selects a subscription, changes the proxy protocol, or replaces rule mode or TUN mode.

Fake-IP assigns a synthetic address to a domain and stores a “domain ↔ synthetic address” mapping. When an app connects to that address, the core looks up the original domain before matching rules and handling the outbound connection. This address is neither the website server’s real IP nor the proxy node’s IP.

Why do Fake-IP addresses often start with 198.18?

A common configuration uses 198.18.0.1/16 as the Fake-IP pool. It falls within 198.18.0.0/15, a range reserved for benchmarking network devices—not for direct access to public websites. The /16 prefix means the pool uses part of that reserved range; it does not mean the entire reserved range consists of this one block.

Seeing 198.18.x.x in a DNS response does not, by itself, mean the response has been tampered with. What matters is whether the connection reaches the same core that holds the mapping. If an app gets a synthetic address but bypasses TUN and any other traffic interception path, the connection will usually fail.

2. From DNS Query to Connection: How the Modes Differ

How Fake-IP typically works

  1. An app sends a DNS query for a domain such as example.com, and the query reaches the core’s DNS resolver.
  2. The core assigns or reuses a synthetic IPv4 address and returns it to the app.
  3. The app connects to that address, and TUN or another traffic interception method routes the connection back to the core.
  4. The core looks up the domain from its mapping, checks the rules in order, and selects a direct or proxy route.
  5. The core resolves the real IP only when needed. If the proxy protocol and outbound settings allow the domain to be sent as-is, the remote end can resolve it instead.

This can reduce the time an app waits for a real DNS response before connecting, while making it easier for the core to identify the original domain. It does not mean “DNS is never used again for the connection.” Direct connections, IP-based rules, some outbound protocols, and specific resolution policies may still trigger a real DNS lookup.

How Redir-Host typically works

Redir-Host usually queries an upstream resolver for the real IP first, then returns that address to the app. When the connection arrives, the core can use the association in its DNS cache to recover the domain. Recovery may be incomplete if the query did not pass through the core, the cache has expired, or multiple domains share an IP address. Traffic sniffing can provide additional information for some protocols, but it does not work for every connection.

Comparison Fake-IP Redir-Host
IPv4 address returned to the app Usually a synthetic address from the pool Usually the real address returned by the upstream resolver
Does the response wait for a real DNS lookup? A standard synthetic response usually does not wait Usually waits when there is no cached result
Information available for domain-based rules Primarily comes from the synthetic address mapping Depends on DNS associations, explicit proxy metadata, sniffing, and similar sources
Common compatibility concerns Address validation, LAN discovery, and connections that bypass interception Real DNS latency and whether the resolved address matches the outbound route

For explicit proxy connections using HTTP CONNECT or SOCKS domain requests, the core may receive the destination domain directly, without the system DNS flow described above. So browsing through a proxy configured only in your browser does not, by itself, confirm that Fake-IP DNS interception is working.

3. Choose by Use Case, Not as a Speed Boost

Fake-IP may reduce DNS wait time on the first connection, but it will not increase your subscription’s bandwidth, lower a proxy node’s cost multiplier, or fix a congested route. If downloads are slow, check DNS latency, connection setup time, and sustained transfer speed separately rather than treating them as one problem.

4. fake-ip-filter: Return Real Addresses Only for Specific Domains

With the default blacklist behavior, fake-ip-filter means that listed domains receive normal DNS responses instead of synthetic addresses. It is not a proxy-bypass list. Connections to filtered domains still go through rules; if they need to go direct, check that the relevant rule routes them to DIRECT.

Here is a partial mihomo example. 127.0.0.1:1053 is a local listening address for manual testing; it does not automatically become your system DNS server. When merging this into an existing configuration, keep only one top-level dns: section and preserve any DNS policies, upstream servers, and other fields your setup needs.

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:
    - localhost
    - "+.lan"
    - "+.home.arpa"
  nameserver:
    - 1.1.1.1
    - 9.9.9.9

The upstream addresses here are examples; choose resolvers that are reachable on your network and suit your LAN requirements. In mihomo’s domain-matching syntax, +.home.arpa matches the domain itself and its subdomains. If you use an older Clash core, first check which fields and matching syntax it supports; do not assume it supports fake-ip-filter-mode.

Good candidates to test as exceptions

.local usually involves mDNS, which differs from ordinary unicast DNS. Adding these names to the filter list does not make TUN forward multicast discovery traffic automatically. If casting or printer discovery fails, also check LAN permissions, the multicast path, and your firewall.

5. Configure LAN DNS and Rule Routing Separately

“Return a real address,” “which DNS server to query,” and “which route a connection takes” are three separate questions. For example, if a NAS uses nas.home.arpa and your router is at 192.168.1.1, add a DNS policy to the example above and put the direct rule before any broader rule that might match first.

# Merge the following fields into the existing dns section; do not create a second dns section.
dns:
  nameserver-policy:
    "+.home.arpa": "192.168.1.1"

# Add the following entries to the existing rules and check their order.
rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT

This shows where to merge the settings; it is not a complete configuration you can use to replace a subscription. Replace 192.168.1.1 with your actual LAN DNS server. If your network cannot reach it, a correct filter list still will not produce a valid response.

Subscription updates may overwrite manual changes. If you use the client’s override, extension, or merge features, check the final generated runtime configuration: Are the filter entries still there? Were the DNS policies merged? Is the direct rule ahead of fallback rules? A “saved successfully” message in the UI does not mean the core has loaded the new fields.

6. Verify the Setup with DNS Queries and Connection Logs

Step 1: Check the Active Core Configuration

Note the core name and version shown by the client. Check the runtime configuration for enhanced-mode, listen, the filter list, and TUN DNS hijacking settings. The client UI may generate or modify fields, so rely on the loaded configuration and logs. If the core reports an unknown field, fix the compatibility issue before testing further.

Step 2: Query the Local DNS Listener Directly

If the listener is configured as in the example above, run this on a system with dig installed:

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 nas.home.arpa A

On Windows, use nslookup interactively and specify the port:

nslookup
> server 127.0.0.1
> set port=1053
> set type=A
> example.com
> nas.home.arpa
> exit

If the first domain is not filtered, it should usually return an IPv4 address from the pool. The second should return its LAN address only if that record is configured on your LAN DNS server. Do not copy a specific 198.18.x.x address as the expected result; assignments can change with the mapping state.

Step 3: Check the DNS and Connection Paths Your System Actually Uses

  1. Close the app’s existing connections, retry the request, and check the client’s Connections page for the destination domain, matched rule, and outbound route.
  2. If a manual DNS query works but the app cannot connect, check whether system DNS queries reach the core and whether TUN intercepts connections to synthetic addresses.
  3. If the app uses its own encrypted DNS, note the current setting, then temporarily disable it for comparison. The app’s in-app DoH queries may bypass the core’s regular DNS listener.
  4. If only IPv6 is failing, check AAAA queries, IPv6 routing, and interception settings separately. A successful A-record test does not confirm that IPv6 is working.

After switching modes on Windows, run ipconfig /flushdns to clear the system DNS cache, then restart the test app. Browsers, apps, and the core may also keep their own caches or persistent connections, so simply refreshing a page may not trigger a fresh DNS query.

7. Troubleshooting: Identify Which Part Is Failing

After closing the client, websites still try to connect to a 198.18 address

Check for stale DNS cache entries, existing connections, and system network settings that were not restored. Restore your normal DNS and proxy settings, clear the system cache, and close and reopen the app. Do not try to add a public gateway for a synthetic address: without the mapping and traffic interception, it is not a directly reachable website address.

The LAN site is still unreachable after adding a filter

First query the real DNS response for the filtered domain. If it returns NXDOMAIN or times out, the problem is with the DNS path. If it returns the correct LAN IP, check the connection rules, routing, and firewall. The filter list only prevents a synthetic address from being returned; it does not discover your LAN DNS server or automatically allow LAN traffic.

Web pages work, but ping to a synthetic address fails

ping uses ICMP, which is different from the TCP or QUIC requests used by websites. How ICMP is handled depends on the core and interception method, and pinging a synthetic address does not measure proxy-node latency. Focus on real app access, connection logs, and tests targeting the service itself.

Switching to Redir-Host fixed the issue. Should you keep it?

You can keep the working configuration while investigating what changed. If only one service is affected, try a precise filter and the correct LAN DNS setup first. If many apps depend on real DNS addresses, Redir-Host can also be a long-term option. Choose based on reproducible connections, expected rule matches, and manageable maintenance—not on which mode sounds more advanced.