What Is Clash Fake-IP? DNS Mapping, fake-ip-filter & Use Cases

The short version: Fake-IP maps domains to synthetic addresses; it is not a proxy exit

In Fake-IP mode, the Clash core returns a synthetic address to the app, then maps that address back to the domain when it intercepts the connection. The app may see an address such as 198.18.0.2, but that address is neither the actual website nor the proxy exit. Seeing it does not mean DNS has been tampered with, nor does it tell you whether the request went through a proxy.

This mechanism depends on two things working together: DNS queries must go to the core, and connections to synthetic addresses must also be routed back to that same core. Desktop clients commonly use TUN to capture traffic; routers may use transparent proxy rules. Adding enhanced-mode: fake-ip to a config alone does not set up all system routes and DNS forwarding automatically.

Five steps from DNS mapping to connection recovery

Here’s what happens when an app accesses example.com:443, assuming the same mihomo instance handles both DNS and the connection.

1. The app sends a DNS query. It requests the IPv4 address for example.com, and the query reaches the core’s DNS service. If the app uses encrypted DNS that is not intercepted, this step may bypass the core.
2. The core assigns a synthetic address. If the domain is not on the filter list, the core assigns an address from the Fake-IP pool, such as 198.18.0.2, and stores the domain-to-address mapping. A valid existing mapping may be reused.
3. The app connects to the synthetic address. Following the usual network flow, the app connects to 198.18.0.2:443. TUN or transparent proxy rules route the connection back to the core instead of sending it directly to the public internet.
4. The core retrieves the original domain. It looks up the mapping and recovers example.com, then applies domain rules, selects a policy group, and handles the connection accordingly.
5. A real connection is made through the selected route. When using a proxy, the proxy may resolve the domain if the protocol and implementation support sending it as a domain name. For direct connections, the local core usually still needs to resolve the real address. The exact behavior depends on the rules and DNS settings.

198.18.0.0/15 is a special-purpose range reserved for network device benchmarking, not a range of public website addresses. Common configs use 198.18.0.1/16 from this range as the address pool. If your organization already uses it, resolve any routing conflicts first rather than applying the default blindly.

Why keeping the domain helps with rule matching

When the core sees only a shared CDN address, it may not be able to tell different websites apart based on the address alone. Fake-IP mappings preserve the domain as a clue for matching rules such as DOMAIN and DOMAIN-SUFFIX. Rules are still evaluated in order, however: an earlier process rule, IP range rule, or other match may determine the route first.

First-packet latency: what wait time can be avoided?

Fake-IP can give an app an address sooner, allowing it to start connecting before a real A record is available. Compared with a flow that must wait for the real DNS result, this can shorten the delay before connection setup begins—but it does not guarantee faster loading for every website.

For example, suppose an uncached real DNS query takes 80 ms. Fake-IP can let the app start setting up a connection without waiting those 80 ms first. This is an illustrative figure, not a measured speed gain; direct DNS resolution, proxy negotiation, the TLS handshake, and the server response may all take additional time.

How to make a meaningful comparison

• Keep the network, proxy node, and rule mode the same. Test cold and warm caches separately rather than comparing the two together.
• Use your browser’s Network panel to inspect DNS, connection, and TLS stages, and check the core logs too. The DNS time shown by a browser may not include later resolution by the core.
• Record the median across multiple page requests, and distinguish DNS response time from time to first byte. A single speed-test download is not a substitute for comparing DNS performance.

Minimal DNS config and test commands

This is a config snippet, not a complete setup for internet access. It enables the core’s DNS service and listens on local port 1053 only; your existing config must still provide proxy nodes, rules, TUN, and system DNS interception. IPv6 is disabled here to limit testing to IPv4 A records. For normal use, enable it according to your network’s IPv6 interception capabilities.

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:
    - "localhost"
    - "+.lan"
    - "+.local"
    - "+.home.arpa"
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

Both upstream DNS addresses must be reachable from your current network. In corporate, campus, or home networks with split DNS, use the appropriate internal resolver; sending every query to public DNS may break internal domain resolution. Listening on 127.0.0.1 accepts queries from this device only, so it is not suitable as a DNS server for other LAN devices to access directly.

Test the core first, then the system resolver

On a device where the core is already running, use the commands below to specify the server and port explicitly. Use the first command on Windows; the second works on macOS or Linux with dig installed. They are alternatives, so there is no need to run both.

nslookup -port=1053 example.com 127.0.0.1

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

1. Check that the returned address falls within the configured Fake-IP pool. If the request times out, first verify that the core is running, the port is available, and DNS is enabled in the effective configuration.
2. Next, query the same domain using the system’s default resolver. If the query to the specified port succeeds but the system query returns something different, the app or system is not using this DNS path yet.
3. Find the browser request you just made on the client’s Connections page. Check the destination domain, matched rule, and selected policy group. A synthetic DNS response confirms only that resolution worked; it does not prove the connection was intercepted.

fake-ip-filter: which domains should return real addresses?

fake-ip-filter controls which DNS queries do not receive synthetic addresses. With the common default blacklist behavior, domains on the list return real DNS results instead. Newer mihomo versions also support extended settings such as filter modes. If your config includes fake-ip-filter-mode, check what it means before assuming the list contains exclusions.

The filter list does not choose between direct and proxy routes, nor does it select an internal DNS server. A domain on the list can still use a proxy according to the rules; a domain routed as DIRECT is not automatically excluded from Fake-IP.

LAN domains also need the right upstream resolver

+.home.arpa matches the domain and its subdomains, making it suitable for home networks that use this naming convention. .lan is a common local convention, but not every router uses it. .local is generally associated with mDNS; adding it to the filter list does not give a regular DNS upstream mDNS discovery capabilities. If printer discovery fails, also check multicast and local network access permissions.

Add game and verification domains only when evidence points to them

Don’t filter an entire gaming platform or every CDN domain. Note when the problem occurs, then locate the relevant request in the connection and DNS logs and add only the specific domain causing trouble. The login.example.com below is just an example of the syntax; replace it with a target confirmed in your logs rather than using it as a game fix.

dns:
  fake-ip-filter:
    - "localhost"
    - "+.lan"
    - "+.local"
    - "+.home.arpa"
    - "login.example.com"

Merge these entries into the existing dns object. Do not create a second top-level dns key in the same YAML file. If the server updates your subscription periodically, save changes using the client’s override or merge feature, then check the effective configuration after each update.

Common problems: DNS works, so why can’t I connect?

The DNS response is a 198.18 address, but the page keeps timing out

First check whether the connection is reaching the core. System proxy settings usually cover only apps that honor them; they do not automatically intercept every connection to a synthetic address. With TUN, check that it is running, routes were installed successfully, and another VPN has not taken over routing. For testing, leave only one network tool responsible for interception to avoid sending DNS and traffic through different instances.

Some websites still fail after the client is closed

The app or operating system may still have a synthetic address cached after the core that maps it back has exited. Restore the system DNS and routes first, then close affected apps and clear the DNS cache. On Windows, run ipconfig /flushdns; on Linux with systemd-resolved, run resolvectl flush-caches. Browsers may keep their own cache, so restart the browser if clearing the system cache is not enough.

Adding a domain to the filter list has no effect

1. Make sure you edited the active config and that another config or global override has not replaced your changes.
2. Check the filter mode and domain syntax. Make sure you added the domain actually being queried, not just the main domain shown in the browser’s address bar.
3. After applying the config, clear old DNS caches in the app and operating system, then query again and retest.
4. If the domain now returns a real address but the connection still fails, check the rules, UDP support, server status, or internal DNS. Don’t keep expanding the filter list.

The browser works, but a game or command-line app doesn’t

They may use different DNS paths, or one may honor system proxy settings while the other sends packets directly. App-specific DoH, hard-coded IPs, and LAN multicast may not follow the same processing path. Domain sniffing can provide some connection details, but it cannot recover domains from every protocol or replace full DNS and route interception.

A connection that uses an IP address directly never performs the “query a domain and assign a fake address” step in the first place. In that case, check IP rules, process rules, and connection logs instead of expecting an entry in fake-ip-filter to fix it.

Use cases and pre-change checklist

Fake-IP is usually a good starting point for everyday browsing, domain-based routing, and devices already using TUN reliably. In environments that depend on internal DNS, special discovery protocols, or address consistency checks, include real DNS resolution, internal upstreams, and routing in the same troubleshooting plan.

• Check the core first. Note the client and core versions, and confirm the current core supports the config fields you plan to use.
• Then verify both paths. DNS queries must reach the core, and connections to synthetic addresses must return to that same instance.
• Keep filters narrowly scoped. Add only domains confirmed to need real addresses, and document why each one is included.
• Check subscription overrides. After updating a subscription, inspect the effective config to make sure your manual fix was not overwritten.
• Change one type of setting at a time. Start with the filter and observe the result. Don’t change DNS, nodes, rules, and TUN settings all at once.