Clash Fake-IP Mode Explained: 198.18 Addresses, fake-ip-filter & Use Cases

How Fake-IP works: return a mapped address, then handle the real connection

With Fake-IP enabled, a domain lookup may return 198.18.x.x. This usually isn't a DNS error—the core is returning an address mapped locally to that domain. To understand why, separate two steps: DNS tells an app which address to connect to, while proxy rules decide where that connection goes. They work together, but they're not the same setting.

The configuration examples in this guide target the mihomo core, which builds on Clash Meta. Client interface labels and configuration-merge behavior vary, and older Clash cores may not support every DNS extension field. Before making changes, check the core information and active runtime configuration in your client; don't rely only on what appears in the saved file.

What happens when an app visits a domain

1. An app requests the IPv4 address for example.com, and the request reaches mihomo's DNS service.
2. The core assigns an address from the Fake-IP pool, maps the domain to that address, and returns it to the app.
3. The app connects to that address. The connection must be intercepted by the same core that holds the mapping, for example through a correctly configured TUN route.
4. Using the mapping, the core resolves the domain, matches it against the rules, then connects to the actual destination directly or through a proxy.

The main benefit: for queries that can be assigned a Fake-IP directly, DNS doesn't have to wait for an upstream server to return the real address. The domain also remains available for rule matching. However, direct connections, IP-based rules, and some proxy protocols may still require real DNS resolution. The details depend on the rules, outbound route, and core behavior. Faster DNS replies don't mean every website loads faster.

What is 198.18.0.1/16? The address pool and reserved range

198.18.0.0/15 is a special-purpose IPv4 range reserved for network device benchmarking. It spans 198.18.0.0 through 198.19.255.255 and isn't a globally routable public range for regular websites. A common setting, 198.18.0.1/16, uses one /16 pool within that range for Fake-IP. Don't confuse the /16 with the full /15.

Setting 198.18.0.1/16 doesn't mean every domain gets 198.18.0.1. The core manages the pool and its mappings, so different domains can receive different addresses. This isn't a proxy server address: don't use it to test a node or enter it as a subscription URL.

• Seeing a reserved address? First confirm that it came from a Fake-IP response instead of immediately switching DNS servers.
• Your corporate or lab network already uses this range? Routes may conflict. Check the routing table and address-pool plan.
• Changing the address pool? Also check TUN routes, forwarding through any gateway device, and app caches. Don't just edit one line in the YAML.

Don't switch the pool to 192.168.1.0/24 just because it looks more like a real IP range. It may overlap with your home router, printer, or NAS network. The reserved range keeps this mapping separate; it isn't meant to make the numbers look familiar.

Fake-IP vs. redir-host: choosing a DNS mode

redir-host usually returns the real address resolved upstream, then handles the connection using DNS mappings and related information. fake-ip mainly returns a locally mapped address. These are DNS enhancement modes, not the client’s Rule, Global, or Direct proxy modes.

You don't have to commit to one mode everywhere. For everyday browsing with TUN interception, try Fake-IP first and add exceptions only for services that need them. For corporate VPNs, complex LANs, or apps that probe IP addresses, test whether real DNS results are easier to manage. Judge by whether access, logs, and routing agree—not just by the time taken for a single DNS query.

mihomo DNS configuration: a minimal example and how to test it

This is a dns configuration snippet, not a complete subscription. Merge it into your existing configuration and avoid adding a second top-level dns: key. The example listens on 127.0.0.1:1053 for isolated testing. It won't change your system DNS to that port or enable TUN automatically.

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

nameserver lists example upstreams; it doesn't mean both will be reachable on your network or that encrypted DNS is configured. Choose upstreams based on your network and resolution needs. If you switch to DoH or DoT, also consider bootstrap resolution for the server hostname, connectivity, and your existing DNS routing policy to avoid query loops.

Test the core first, then the system DNS path

After saving the configuration and confirming that the core loaded it successfully, run these commands in an environment with dig installed. The -p 1053 option explicitly selects the test port so you don't accidentally query another DNS service in use by your system.

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com A +short

With no other filters or policy overrides, the first command should show 198.18.x.x in the answer section, and the second should print only the address. The actual address depends on the core's runtime state and doesn't need to match a screenshot exactly. If the connection is refused, check that DNS is enabled, the listening port, and the core logs before changing proxy nodes.

1. Confirm that a direct query to the core returns the expected A record.
2. Check that the client's TUN DNS hijacking or system DNS forwarding really points to the core.
3. Start a new connection from an app and check the domain, matched rule, and outbound route in the connection panel.
4. If you see an old result, clear the app and system DNS caches, then test again with a new connection.

How to use fake-ip-filter: real DNS results don't mean a direct connection

With the example's explicitly configured blacklist mode, domains matched by fake-ip-filter aren't assigned Fake-IPs; they use real DNS resolution instead. mihomo versions that support this field also offer other filter modes, where the behavior may be reversed. When migrating a configuration, check the mode and list together. If an older core reports that the field is unsupported, follow that core's documentation and verify the meaning—don't just suppress the error.

In this example, '+.lan' matches lan and its subdomains; '+ .local' works the same way. This is mihomo domain-matching syntax, not a regular expression you can combine arbitrarily. Keeping the quotes makes the entries easier to maintain and helps avoid YAML parsing issues with special characters.

Keep these three settings separate

• Which address is returned: controlled by Fake-IP mode and its filter policy.
• Which DNS server handles the query: controlled by upstream DNS settings, nameserver-policy, and related options.
• Where the connection goes: controlled by rules and proxy group selection.

So adding a NAS domain to the filter list won't make the core query your home router automatically, nor will it add a DIRECT rule. If the domain exists only in your router's DNS, you still need to send the query to the right LAN DNS server and make sure the connection can reach the relevant subnet.

When maintaining the list, add only the domain scope needed by one service at a time, and record how resolution and access behave before and after. Adding an overly broad public domain suffix can send many requests that would otherwise use Fake-IP through real DNS instead, making later troubleshooting harder.

LAN and gaming: add exceptions only for specific problems

NAS, printers, and .local device discovery

LAN services typically use one of two paths: unicast DNS from your router to resolve device names, or mDNS to discover devices on the local network. .local is commonly used with mDNS, which usually uses UDP 5353, not the regular DNS port 53. Adding +.local to the filter list won't fix every multicast discovery issue.

If you can reach a NAS by its LAN IP but not by hostname, first check the DNS resolution path. If the device doesn't appear in a discovery list at all, also check the firewall, network isolation, multicast, and TUN routing. Different layers call for different troubleshooting tools.

Game login, match traffic over UDP, and latency displays

Games may use DNS results for region detection, server lists, connectivity checks, or latency displays. Some checks can't handle reserved addresses. If so, try real DNS resolution for only the affected domains; this is easier to troubleshoot than disabling Fake-IP entirely.

• Can't log in: Check login-domain resolution, the HTTPS connection, and which rule matched. Don't assume UDP is the cause.
• Can log in but can't join a match: Check whether game traffic over UDP is intercepted and whether the node and outbound route support the required UDP traffic.
• Latency looks wrong but the game is playable: Check whether the game uses ICMP or a separate probe domain. The displayed value may not reflect the actual match connection.
• Only breaks after switching modes: Fully quit the game and launcher, clear their caches, then establish a new connection.

Don't add every game domain to the filter list by default, and don't assume that allowing UDP guarantees lower latency. Fake-IP handles address mapping; network distance, outbound congestion, NAT type, and game server status still matter independently.

Troubleshooting order when Fake-IP connections fail

Change one variable at a time and keep the runtime logs. Check each step from configuration through to the connection; this is usually more effective than repeatedly switching global modes.

1. Check the active configuration: Confirm enhanced-mode is set to fake-ip, subscription updates haven't overwritten local changes, and the core loaded the configuration without errors.
2. Check the query path: Query 127.0.0.1:1053 directly, then compare the result with your system or browser. Secure DNS in the browser or an app's built-in DoH may bypass the expected system DNS path.
3. Check what traffic is intercepted: Standard TUN DNS hijacking is generally configured around traditional DNS traffic; it can't automatically treat all encrypted HTTPS DNS as regular port 53 queries. Connections to fake addresses must also reach the core.
4. Check mappings and caches: After a core restart, configuration switch, or address-pool change, an app may still have an old fake address. Clear its cache and restart the affected app first; then decide whether to adjust the core's Fake-IP mapping persistence settings.
5. Check the rules: If a connection has the right domain but takes the wrong route, check rule order and proxy groups instead of changing DNS alone. Rules that depend on the destination IP may also trigger real DNS resolution.
6. Check dual-stack networking: Test A and AAAA records separately and verify IPv6 interception. A successful IPv4 query doesn't mean the IPv6 path is configured correctly.

Keep a configuration you can explain: where DNS queries enter, why each filter entry exists, which server handles real DNS resolution, and which rule routes each connection. Fake-IP helps reduce DNS wait time and preserve domain associations; it doesn't replace routing, rules, or network quality checks.