What Is Clash Fake-IP Mode? How DNS Returns Fake Addresses and When to Use It

Fake-IP Is Not a Wrong Address—It Is a Temporary Number Plate

When an app visits a website, it usually queries DNS for the domain's IP address before opening a TCP, UDP, or QUIC connection to that IP. In the traditional flow, DNS must return the real address before the connection can proceed. Fake-IP changes this step: the built-in DNS in Clash or mihomo assigns an address from a reserved pool and stores the domain-to-fake-address mapping in memory.

The usual address pool is 198.18.0.0/16. This IPv4 range is reserved by RFC 2544 for network-device benchmarking and should not be routed on the public Internet. mihomo configurations commonly use 198.18.0.1/16, providing about 65,534 assignable addresses. A browser may see 198.18.0.23, but it will not actually search the public Internet for that host.

When the app later connects to 198.18.0.23:443, the Clash core looks up the original domain in its mapping table, such as www.example.com. The rule engine can then match domain rules like DOMAIN, DOMAIN-SUFFIX, and GEOSITE directly before choosing a proxy, direct connection, or rejection. If the traffic uses a proxy, the domain can be passed through the proxy chain; if the rules require a direct connection, the core resolves the real address through the configured DNS server.

What Happens During a Request

1. The browser queries the A record for api.example.com.
2. Clash DNS returns 198.18.0.23 from the Fake-IP pool and stores the mapping.
3. The browser opens a connection to 198.18.0.23:443.
4. The system proxy, transparent proxy, or TUN mode passes the connection to the core.
5. The core restores the domain and selects DIRECT, PROXY, or another policy from the rule group.
6. When the real IP is needed, the core or proxy server resolves it and connects to the destination.

“Saving one DNS round trip” means the app does not have to wait for a public recursive lookup to finish before receiving a local response and starting the connection. Real resolution has not vanished; it has been deferred, combined with another step, or moved to the proxy side. Overall latency still depends on the DNS server, proxy node, and destination network.

The Core Difference Between Fake-IP and Redir-Host

Redir-Host is another common enhanced DNS mode. It completes a real DNS lookup first and returns the real IP to the app. After the app connects to that IP, the core attempts to recover the domain using DNS mappings, connection details, or domain sniffing. Its results more closely resemble ordinary networking, making it friendlier to LAN devices and a few apps that strictly check DNS responses.

Fake-IP keeps the domain front and center. When rules are evaluated, the core already knows which domain the connection originally targeted, so it does not have to rely only on the destination IP and is less affected when multiple sites share one IP. This is especially clear with CDNs: hundreds of domains may share one edge address, making accurate service matching difficult if you only inspect the IP.

Neither mode is universally better. On desktop devices using TUN traffic interception with mainly domain-based rules, Fake-IP is usually easier to manage. For router sidecar setups, LAN discovery, printer control, or many older apps, test the filter rules first; if problems persist, switch to Redir-Host for comparison.

How to Configure Fake-IP in mihomo

The example below follows the configuration structure commonly used in the mihomo 1.19 series. Some GUI clients split these options across separate settings, but they must ultimately generate the corresponding YAML. Copy your current configuration before editing. Subscription profiles may overwrite local changes during updates, so prefer the client's override, Mixin, or extension-script feature.

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-mode: blacklist
  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - "localhost.ptlogin2.qq.com"
    - "+.pool.ntp.org"
  nameserver:
    - https://223.5.5.5/dns-query
    - https://1.12.12.12/dns-query
  proxy-server-nameserver:
    - https://223.5.5.5/dns-query

Understanding Each Setting

• enable: true: Enables the built-in DNS. Setting enhanced-mode without enabling DNS will not produce the expected result.
• listen: 127.0.0.1:1053: Listens only on local port 1053. A regular user process may not have permission to listen on port 53, and it may conflict with the system DNS service.
• ipv6: false: Does not return AAAA records to apps. If your network has stable IPv6 support and your rules cover IPv6, you can enable it, but check both direct and proxy paths.
• enhanced-mode: fake-ip: Selects Fake-IP enhanced mode. If set to redir-host, DNS returns real addresses.
• fake-ip-range: Specifies the IPv4 address pool. Keep the default in most cases; do not change it to 192.168.0.0/16 or 10.0.0.0/8, which are commonly used by home LANs.
• fake-ip-filter-mode: blacklist: Domains on the list bypass Fake-IP and receive real DNS results. This is the most common behavior.
• nameserver: Resolves ordinary domain names. The example uses DoH, which normally connects over port 443.
• proxy-server-nameserver: Resolves the domain names of proxy-node servers separately, avoiding circular dependencies when resolving node addresses.

How to Verify That Fake-IP Is Working

On macOS or Linux, use dig to query the local DNS port. On Windows, use a DNS tool that supports custom ports, or temporarily change the listening port to the system's port 53 for testing. The commands below do not modify system settings:

dig @127.0.0.1 -p 1053 www.example.com A

# Expected output resembles:
# www.example.com.  1  IN  A  198.18.0.2

If a public real IP is returned, first check whether the active configuration still uses redir-host, then check whether the domain matches fake-ip-filter. If the query times out, use lsof -nP -iUDP:1053 or ss -lunp to see whether the port is listening. GUI clients should also be checked against the active runtime configuration, not just the original subscription file.

After enabling external-controller: 127.0.0.1:9090 in mihomo, you can also query DNS through the controller API. When no controller secret is configured, the request looks like this:

curl "http://127.0.0.1:9090/dns/query?name=www.example.com&type=A"

If the controller has a secret configured, the request must include the corresponding Bearer credential. Port 9090 should never be exposed directly to the public Internet; even LAN sharing at home should have access restrictions.

How to Write fake-ip-filter Rules

fake-ip-filter makes selected domains bypass fake-address assignment and receive real DNS results directly. The domains that need filtering are usually not simply “sites that fail to open,” but services that depend on real addresses, LAN addresses, or special DNS records. An oversized list undermines Fake-IP's domain-mapping advantage.

Types of Domains Worth Filtering

• LAN names: *.lan, +.local, router administration domains, and custom NAS domains.
• Time synchronization: Some NTP clients accept only a directly resolved UDP target; consider filtering +.pool.ntp.org.
• Connectivity checks: Some systems use a fixed domain and response content to determine whether to show a hotel, airport, or campus network login page.
• Device discovery and casting: Printers, TVs, speakers, and casting devices may rely on mDNS, unicast DNS, and LAN addresses working together.
• Apps that explicitly validate DNS addresses: A small number of programs compare the DNS result with the actual connection address, and a reserved address may trigger an error.

dns:
  enhanced-mode: fake-ip
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - "router.asus.com"
    - "miwifi.com"
    - "+.pool.ntp.org"
    - "time.windows.com"
    - "time.apple.com"

*.lan generally matches subdomains, while +.local in mihomo's domain-matching syntax can cover the root domain and its subdomains. Support for wildcard expressions may vary between core versions, so check the runtime log when migrating an old Clash configuration. The safest troubleshooting approach is to start with the complete domain, verify that service is restored, and only then broaden the pattern.

Whitelist Mode Is Not a Universal Optimization

mihomo supports setting fake-ip-filter-mode to whitelist. The logic is reversed: only domains on the list use Fake-IP, while all other domains receive real addresses. This suits special environments that want to enable Fake-IP gradually, but it can easily produce inconsistent rule behavior. Do not enable it casually just to “reduce fake addresses.”

dns:
  enhanced-mode: fake-ip
  fake-ip-filter-mode: whitelist
  fake-ip-filter:
    - "+.example.com"
    - "+.example.net"

When adjusting the filter list, add only one or two entries at a time. Save the configuration, reload the core, clear the system DNS cache, and reproduce the issue. On macOS, run sudo dscacheutil -flushcache; on Windows, run ipconfig /flushdns. Browsers may also keep a separate DNS cache, so fully quitting the browser makes testing more reliable.

When Fake-IP Is a Better Fit

Full-Device Traffic Interception with TUN

TUN creates a virtual network interface that receives more traffic at the network layer than a system proxy. Command-line tools, some game launchers, and apps that ignore system proxy settings can also enter the core. Because the core must intercept the reserved addresses returned by Fake-IP, Fake-IP works most naturally with TUN, transparent proxying, or router redirection.

If Fake-IP is enabled without a system proxy, TUN, or transparent forwarding, an app may send packets directly to 198.18.0.0/16, resulting in connection timeouts. DNS may appear to work, but the missing piece is traffic interception. Check DNS query logs and connection logs together.

Rules Are Organized Mainly by Domain

When the configuration relies heavily on DOMAIN-SUFFIX, DOMAIN-KEYWORD, GEOSITE, or rule sets, Fake-IP preserves the domain context when the connection is established. Compared with guessing a domain after receiving only a CDN IP, this makes it easier to understand why a rule matched.

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,PROXY

In GEOIP,CN,DIRECT,no-resolve, no-resolve means not to trigger an extra DNS lookup solely to match that IP rule. In a Fake-IP environment, this can reduce unnecessary queries, but whether to use it depends on the domain-rule order above it. Rules are matched from top to bottom, and matching stops at the first hit.

You Want to Reduce the Impact of Local DNS Poisoning

The app receives a local Fake-IP first instead of relying directly on the destination address returned by the ISP's DNS. Actual resolution can be handled by encrypted DNS or the proxy chain, making false responses and DNS-path leaks easier to control. Fake-IP is not a standalone security switch, however: if nameserver still points to unreliable plaintext DNS, or proxy-node domain resolution is misconfigured, problems may remain.

When Fake-IP Is a Poor Fit or Requires Caution

Many LAN Devices or Corporate Internal Domains

Corporate internal DNS may resolve git.company.test to 10.20.0.15, while a home NAS may depend on a search domain supplied by the router. If every query is sent to public DoH, internal domains will fail to resolve; even if Fake-IP assigns an address successfully, the real service still cannot be reached.

In this situation, use nameserver-policy to assign an internal DNS server to internal suffixes instead of adding every domain to the filter list. For example, if the internal DNS server is at 10.20.0.53:

dns:
  enhanced-mode: fake-ip
  nameserver:
    - https://223.5.5.5/dns-query
  nameserver-policy:
    "+.company.test":
      - 10.20.0.53
  fake-ip-filter:
    - "+.company.test"

The Side Router Does Not Fully Reclaim the Reserved Range

After the router returns Fake-IP addresses to clients, traffic destined for 198.18.0.0/16 must return to the device running mihomo. Policy-routing, iptables, or nftables rules that omit UDP commonly result in websites opening while QUIC, voice, or game connections fail. Check whether both TCP and UDP enter the TUN or transparent-proxy path.

The App Depends on Real DNS Answers

Network diagnostic tools, DNS management utilities, and some anti-cheat or device-discovery programs may need to see real A, AAAA, PTR, or SRV records. For these programs, switching the entire setup to Redir-Host is often excessive; first add the specific domains to the filter list, or route that program's DNS queries around Clash.

Common Problems and a Practical Troubleshooting Order

DNS Returns a 198.18 Address, but Websites Will Not Open

1. Confirm that the system proxy or TUN is enabled—not just the built-in DNS.
2. Check the connection log for the destination domain; no log entry at all usually means the traffic never reached the core.
3. Check whether 198.18.0.0/16 is being used by another VPN, virtualization app, or corporate route.
4. Temporarily disable QUIC and test over TCP 443 to determine whether only UDP interception is missing.
5. Add the destination domain to fake-ip-filter. If service returns immediately, continue by checking app compatibility.

Only LAN Domains Fail to Open

First query the internal DNS directly, for example dig @192.168.1.1 nas.lan. If it returns 192.168.1.20, internal resolution is working. Next, set nameserver-policy for the suffix and add it to the filter list. Also confirm that private-network rules come before the proxy fallback rule:

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - MATCH,PROXY

Settings Revert After a Subscription Update

A subscription is a remote configuration snapshot. When the client updates it, YAML edited locally may be overwritten. Maintain the DNS section through the client's override feature, such as Settings → Configuration → Global Extensions or the corresponding Mixin page. Names vary by client version, but the principle is the same: the subscription stores nodes and rules, while local extensions store device-specific DNS, TUN, and listening-port settings.

Old Results Remain After Switching Modes

DNS caches may exist at three levels: the operating system, browser, and Clash core. First reload the configuration or restart the core, then clear the system DNS cache, and finally quit the browser completely. Fake-IP record TTLs are often short, but established connections will not be recreated immediately when the DNS mode changes.

Configuration Takeaway: Ensure Traffic Interception First, Then Tune DNS

Fake-IP's value is not the special address itself, but the stable preservation of domain information through rule matching. It makes domain-based routing easier for TUN and transparent proxies and lets real resolution take place along a more suitable network path. Seeing 198.18.x.x does not mean DNS is broken, provided the connection actually enters the Clash core afterward.

A practical setup can start with the default address pool, blacklist filtering, and two reliable DNS upstreams. Route LAN domains through nameserver-policy, and put domains that require real addresses in fake-ip-filter. When something fails, check in this order: “Is DNS listening—does the query return— is the connection intercepted—did a rule match—did real resolution succeed?” This is faster than repeatedly switching nodes.