Fake-IP Mode Explained

The note is generated by CatDesk.

What is Fake-IP

Fake-IP is a DNS resolution strategy used by proxy tools like Clash (Mihomo), Clash Verge, and similar transparent proxy software. Instead of performing a real DNS lookup when an application requests a domain, the proxy immediately returns a fabricated IP address from a reserved subnet (typically 198.18.0.0/16). The proxy maintains an internal mapping table between these fake IPs and the original domains, so when traffic is later routed to a fake IP, the proxy knows which domain the traffic was actually destined for.

The Problem Fake-IP Solves

In a traditional proxy setup (called “redir-host” mode), the flow looks like this:

App requests google.com
  → System DNS resolves google.com → 142.250.80.46 (real IP)
  → Proxy sees traffic to 142.250.80.46
  → Proxy matches rules and forwards accordingly

This approach has two significant issues:

DNS Leak — Even though your traffic goes through the proxy, the DNS query itself was sent in plaintext to your local DNS server. Your ISP (or anyone on the network) can see every domain you visit.

DNS Latency — Every new connection must wait for DNS resolution to complete before the proxy can route it. If the DNS server is slow, your browsing feels sluggish.

How Fake-IP Works

With fake-ip mode enabled, the flow becomes:

App requests google.com
  → Clash intercepts the DNS query
  → Clash immediately returns 198.18.0.5 (fake IP from pool)
  → Clash records: 198.18.0.5 → google.com
  → App connects to 198.18.0.5
  → Clash intercepts the connection, looks up 198.18.0.5 → google.com
  → Clash applies routing rules using the domain name
  → Remote proxy server does the REAL DNS resolution

The key insight: the application never touches a real IP address. The proxy resolves the domain on the remote end (the proxy server), so your local network never sees the actual DNS query or the real destination IP.

Configuration

A typical fake-ip configuration in Clash/Mihomo:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

dns:
  enable: true
  listen: 0.0.0.0:53
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  fallback:
    - https://dns.google/dns-query
    - https://dns.cloudflare.com/dns-query

The fake-ip-range defines the pool of fake IP addresses. The 198.18.0.0/16 range is ideal because it belongs to a reserved block (RFC 2544 benchmarking) that no legitimate internet service would use, so there’s no conflict with real traffic.

The fake-ip-filter: When Fake-IP Breaks Things

Fake-IP is elegant but not universal. Some applications and network scenarios break when they receive a fake IP instead of a real one.

When fake-ip causes problems

Internal/corporate networks — If your company uses internal DNS to resolve domains like *.sankuai.com to private IPs (e.g., 10.x.x.x or 33.x.x.x), and you have IP-based routing rules like IP-CIDR,10.0.0.0/8,DIRECT, the rule will never match because the domain was mapped to 198.18.x.x instead of the real internal IP.

LAN services — Local network devices (printers, NAS, smart home hubs) that rely on mDNS or local DNS to discover each other will fail if they get a fake IP.

System services — Windows network discovery, macOS Bonjour, NTP time sync, and captive portal detection all need real IPs to function.

Applications with IP validation — Some apps verify that the resolved IP makes sense (e.g., belongs to a known range), and will reject connections to 198.18.x.x.

WebSocket/long-lived connections — If the fake-ip cache entry expires while a connection is still active, reconnection logic may fail.

The solution: fake-ip-filter

The fake-ip-filter is a list of domain patterns that should bypass the fake-ip mechanism entirely. For these domains, Clash performs a real DNS resolution and returns the actual IP to the application.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

dns:
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    # Internal corporate domains — need real IPs for DIRECT routing
    - '*.sankuai.com'
    - '*.meituan.com'
    - '*.mt.com'
    - '*.dpfile.com'

    # LAN and local discovery
    - '*.local'
    - '*.localhost'
    - '*.lan'

    # Windows network services
    - '*.msftconnecttest.com'
    - '*.msftncsi.com'
    - 'WORKGROUP'

    # NTP time sync
    - 'time.*.com'
    - 'ntp.*.com'
    - '*.ntp.org.cn'
    - '*.pool.ntp.org'

    # Music and streaming services (some validate IPs)
    - '*.music.163.com'
    - '*.126.net'

    # Game platforms (anti-cheat systems check IPs)
    - '*.battlenet.com'
    - '*.blizzard.com'

When a domain matches fake-ip-filter, Clash uses the configured nameserver to resolve it to a real IP. This ensures that IP-CIDR rules in your routing configuration can match correctly.

Fake-IP vs Redir-Host: Comparison

Fake-IP Cache and Lifecycle

Fake-IP addresses are not permanent. The proxy maintains a mapping pool with a limited size (65,535 addresses for a /16 range). The lifecycle:

1. App requests example.com → Clash assigns 198.18.0.42
2. Mapping stored: 198.18.0.42 ↔ example.com with a TTL
3. When TTL expires or the pool is full, old mappings are evicted (LRU)
4. If the same domain is requested again after eviction, it may get a different fake IP

This is usually transparent, but can cause issues with applications that cache DNS results aggressively on their side.

Real-World Example: Meituan Intranet + Proxy Coexistence

This is a practical case where fake-ip-filter is essential. The Meituan intranet uses private IP ranges (10.0.0.0/8, 33.0.0.0/8) that must be accessed directly (not through any proxy). Without fake-ip-filter:

Browser requests mlp.sankuai.com
  → Clash returns 198.18.0.99 (fake)
  → Rule "IP-CIDR,10.0.0.0/8,DIRECT" does NOT match 198.18.0.99
  → Traffic goes through proxy → proxy can't reach internal server → connection fails

With fake-ip-filter including *.sankuai.com:

Browser requests mlp.sankuai.com
  → Clash resolves via internal DNS → 10.192.19.165 (real)
  → Rule "IP-CIDR,10.0.0.0/8,DIRECT" MATCHES
  → Traffic goes directly to 10.192.19.165 → success

Additionally, the system proxy bypass list must include the internal IP ranges so that traffic to these IPs doesn’t even enter the proxy stack:

1

system_proxy_bypass: localhost,127.0.0.1,192.168.0.0/16,10.0.0.0/8,33.0.0.0/8,11.0.0.0/8,172.16.0.0/12,*.local,*.sankuai.com,*.meituan.com

Debugging Fake-IP Issues

When something doesn’t work with fake-ip enabled, here’s how to diagnose:

Check if a domain is getting a fake IP:

1
2
3

nslookup mlp.sankuai.com
# If the answer is in 198.18.x.x range → fake-ip is active for this domain
# If the answer is a real IP → domain is in fake-ip-filter or DNS is not going through Clash

Check the Clash log — Look for DNS resolution entries. Clash logs which domains were resolved via fake-ip and which went through normal resolution.

Verify your rules match — If a domain should go DIRECT but isn’t, it likely needs to be in the fake-ip-filter so that IP-CIDR rules can see the real IP.

Test with redir-host temporarily — Switch to redir-host mode. If the problem disappears, it confirms the issue is fake-ip related, and you need to add the problematic domain to fake-ip-filter.

Summary

Fake-IP is an optimization that trades compatibility for speed and privacy. It works beautifully for general web browsing and proxy routing, but requires careful configuration of the fake-ip-filter for any domain that needs to resolve to a real IP — particularly internal corporate domains, LAN services, and applications that validate IP addresses. The key rule: if a domain’s real IP is needed for correct routing or application logic, put it in the filter.