Fake IP Mode Explained: DNS Mapping, Redir-Host, and LAN Compatibility

1. What Fake IP Does: Mapping Addresses to Domain Names

Fake IP is a DNS mode used by Clash-based cores. When an app looks up an IPv4 address for a domain, the core can assign an address from a designated pool and record the mapping between the domain and that fake address. The address is used to intercept connections on the local device or managed network; it is not the website server’s public IP address.

A common configuration uses 198.18.0.1/16 as the address pool, which falls within the 198.18.0.0/15 benchmarking address range. This is different from private LAN ranges such as 192.168.0.0/16, and these addresses should not be sent directly over the public internet. Seeing one in a DNS response does not, by itself, mean DNS is misconfigured.

How a Connection Is Handled

1. The app looks up example.com, and the query reaches the core’s DNS service.
2. The core assigns an address from the pool and creates a mapping. For example, it might assign 198.18.0.2; the specific address can vary.
3. The app connects to this fake address, and TUN or another transparent interception path sends the connection back to the same core.
4. The core looks up the domain in its mapping table, then uses the rules to choose a direct or proxy route.
5. A direct connection usually still needs the real IP address. Whether a proxy can pass the domain to the remote server depends on the outbound protocol and configuration.

The key requirement is that the DNS query and subsequent connection form a complete loop. If a device gets a fake address from Clash but traffic to that address never returns to the core that owns the mapping, you may see “DNS responds, but the page won’t load.” Simply opening a DNS listening port does not complete this loop.

What Fake IP Can—and Can’t—Speed Up

Fake IP can reduce the time an app spends waiting for a real DNS response and make it easier for the core to match rules against the original domain. It does not reduce physical network latency or guarantee faster loading on every site. DNS lookups for direct connections, proxy handshakes, TLS setup, and server response times can still dominate, so faster fake address assignment does not necessarily mean faster page loads.

2. Fake IP vs. redir-host: DNS Responses and Interception Requirements

Choose a mode based on how traffic is actually intercepted. On a desktop with TUN enabled and DNS queries handled by the same core, the Fake IP path is relatively straightforward. Printers, TVs, and game consoles can behave differently; changing DNS alone without setting up transparent proxy routing is not enough to apply a desktop configuration as-is.

A system proxy follows a different path. HTTP proxy requests may include the domain directly and might not use the local DNS result. A website loading in a browser does not prove that system DNS or TUN is working correctly. Likewise, a failed diagnostic command does not necessarily mean the HTTP proxy is broken.

3. Minimal DNS Setup and fake-ip-filter Syntax

This is a DNS configuration snippet, not a complete setup with proxies, proxy groups, and rules. The example uses local port 1053 to avoid taking over the commonly used system port 53. TUN DNS hijacking or system DNS forwarding must be configured separately. Standard DNS settings in an operating system usually do not let you specify a custom port.

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:
    - '+.lan'
    - '+.local'
    - '+.home.arpa'
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

What Each Field Does

• enable: Enables the core’s DNS service. The client may also have a separate DNS override switch, so check the final configuration in effect.
• listen: Accepts queries from the local machine only; it does not expose DNS service to the LAN.
• ipv6: false: Controls how this DNS module handles AAAA queries. It does not disable IPv6 in the operating system or guarantee that other resolvers will not return IPv6 addresses.
• enhanced-mode: Sets the DNS enhanced mode. This example uses fake-ip.
• fake-ip-filter: With the commonly used default blacklist behavior, matching domains are not assigned fake addresses; instead, DNS returns their real resolved addresses.
• nameserver: The example lists two upstream addresses. Their order does not mean “mainland China first, overseas as backup.” Actual behavior also depends on the core implementation and other DNS fields.

+.home.arpa matches the domain and its subdomains. home.arpa is the domain namespace for home networks. .local is commonly associated with mDNS; some queries are sent over UDP multicast on port 5353 and do not pass through a standard DNS listener like this one. Adding a domain to the filter list does not replace mDNS forwarding or device discovery.

mihomo offers more granular filter modes, such as fake-ip-filter-mode. Before copying a configuration, check that your core supports the field: whitelist mode changes what the filter list means, so its entries can no longer all be described as “excluded.” Field support varies across the original Clash, different forks, and releases.

4. LAN Device Compatibility: Check DNS, Routing, and Discovery Separately

NAS Domain Resolves to a Fake Address

For example, a NAS might have the real address 192.168.1.20 and the home domain nas.home.arpa. If a lookup returns an address starting with 198.18, first check whether the domain matches a filter entry, then check whether it is being resolved by your home DNS server. Both need to be configured correctly to reliably get the private IP.

In mihomo, use nameserver-policy to choose a resolver for home domains. This snippet assumes the router’s DNS server is 192.168.1.1 and that the device running the core can reach it. Merge the snippet into the existing dns object; do not create a second top-level dns key.

dns:
  nameserver-policy:
    '+.home.arpa': '192.168.1.1'

This snippet does not include the filter list shown earlier, so keep fake-ip-filter when merging it. Also check that the router does not forward the same query back to Clash, which could create a DNS forwarding loop.

Printer, TV, and Casting Device Discovery Fails

Device discovery may use mDNS, SSDP, or broadcast—not just standard DNS. mDNS commonly uses 224.0.0.251:5353, while SSDP commonly uses 239.255.255.250:1900. A device may not be discoverable even when DNS works if the client is on guest Wi-Fi, a different VLAN, or a network with wireless client isolation enabled.

• First, try opening the device’s management page using its actual private IP to confirm basic connectivity.
• Then look up the device’s domain and check whether it returns the expected private IP.
• If only automatic discovery fails, check multicast, broadcast, and network segmentation. Don’t keep expanding the DNS filter list.

Phone Gets a Fake IP, but the Connection Goes Through a Different Gateway

A fake IP mapping belongs to a specific core instance. If a phone queries DNS through gateway A but sends the connection through gateway B, B usually won’t have A’s mapping. The same issue can occur if A restarts while the phone continues using a stale cached address. Use a consistent DNS and transparent proxy path across the home network; don’t distribute a computer’s Fake IP DNS service as standalone public DNS for every device.

5. Troubleshooting: Trace DNS Responses to the Actual Route

Step 1: Query the Core’s DNS Directly

If dig is installed on Linux or macOS, you can query the local port used in this example. These commands are for testing; output may vary:

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

Under a normal Fake IP assignment flow, the first query should return an address from the pool. With the filter and home DNS policy set up correctly, the second should return the actual home network record. If a query times out, check the DNS listener and process first. If it returns NXDOMAIN, check that the record exists and that the correct resolver is being used.

Step 2: Check Which Resolver the System Actually Uses

On Windows, use ipconfig /all to check the DNS addresses assigned to network adapters, and nslookup example.com to test the default query path. Browser secure DNS, built-in app DoH, VPNs, and other virtual network adapters can all change that path. It’s not unusual for command-line tools and browsers to use different resolvers and return different results.

ipconfig /all
nslookup example.com
ipconfig /flushdns

ipconfig /flushdns clears only the Windows DNS client cache; it does not clear caches held by browsers, apps, or the core’s mapping table. After changing modes or restarting the core, restart apps that may still hold old connections, then repeat the same query. Don’t assume a setting failed just because refreshing the page didn’t help.

Step 3: Check Rule Matches and Private Network Ranges

In the client’s connections list or logs, check the destination domain, destination address, matched rule, and outbound route. To route home network traffic directly, you can use a rule snippet like this, placed before broad proxy rules and the final MATCH:

rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - 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

This is not a complete ruleset; merge it into the existing rules list. no-resolve means the core will not trigger an extra DNS lookup just to match this IP rule; it can still match when the destination IP is already known. If the core has recovered the domain for a connection, an earlier domain rule can match it without relying on an IP rule as a fallback.

Don’t add the entire Fake IP address pool to direct-routing rules in an attempt to make the operating system connect to those addresses directly. Fake addresses must first reach the core that maintains their mappings; they cannot be routed as if they were real website addresses.

6. Common Questions and When to Switch Modes

Does pinging an address starting with 198.18 mean the website is down?

No. It may simply be the fake address assigned to the domain. ICMP follows a different path from proxied TCP and UDP traffic, so ping results alone cannot tell you whether a website is reachable. Check the DNS response, connection logs, and the app’s actual requests together.

Can fake-ip-filter fix errors with all games and smart devices?

No. It only changes address assignment for matching domains. UDP forwarding, NAT type, hard-coded IPs in apps, certificate errors, and multicast isolation need to be investigated separately. Add a filter entry for a specific domain only after confirming that the app depends on a real DNS address.

Do I have to enable TUN when using Fake IP?

Not necessarily. TUN is a common way to intercept connections, but router-based transparent proxying can do the same job. The requirement is that traffic to the fake address is handled by the core that maintains its mapping—not that a particular switch in the interface is turned on.

When should I consider switching to redir-host?

Try redir-host if a specific device keeps validating DNS addresses, needs to pass resolved addresses to other devices that don’t use this core, or you can’t yet make the DNS and connection paths consistent. After switching, clear relevant caches and reconnect, then check domain rules and the real DNS resolution path again.

A stable setup has three things in sync: the expected resolver handles the domain, the connection reaches the right core, and the outbound route follows the rules. Verify one app and one domain first, then expand the filter list or change modes. This is usually easier to troubleshoot than changing DNS, TUN, and an entire subscription at once. For core fields, see the Protocol Reference; for networking terms, see the Quick Glossary.