Fake-IP Mode Explained: How DNS Mapping Reduces Initial Connection Delays on iPhone

First, separate DNS responses from successful connections

When you open a website on your phone, the app usually looks up the domain’s IP address before connecting. In clients that support Clash Meta (mihomo) DNS features, enhanced-mode: fake-ip changes how that lookup is answered: the core assigns the domain a temporary synthetic address, stores the “domain ↔ synthetic address” mapping, and returns the synthetic address to the app.

The app then connects to that address. Once the client takes over the traffic, the core uses the mapping to recover the original domain, match it against rules, and choose a direct or proxied route. The synthetic address is an internal client-side identifier—not the website server’s real address, and not a destination you can reach on the public internet.

What happens during a request

1. The app looks up the A record for example.com. The query must pass through the client’s DNS processing chain.
2. The core returns an address from the configured Fake-IP range and stores its association with example.com.
3. The app connects to that address. The client intercepts the connection, retrieves the domain, and applies rules such as DOMAIN and DOMAIN-SUFFIX.
4. The core handles the destination connection using the selected outbound. Whether a proxy outbound can connect by domain also depends on the protocol, node, and client implementation.

A DNS response and a successful connection are two different things. Fake-IP lets the app receive an address for later rule matching sooner, but the outbound connection still depends on rule evaluation, connecting to a node, and a response from the destination. This domain-mapping flow cannot work as usual if the app connects directly to a numeric IP, its DNS query bypasses the client, or the subsequent connection is not intercepted.

Fake-IP vs. redir-host: when the real lookup happens

With redir-host, the client typically queries an upstream DNS server for the destination’s real IP before replying to the app. With fake-ip, it returns a synthetic address first, then uses the mapping to recover the domain when it intercepts the subsequent connection. The key difference isn’t whether DNS is used; it’s whether the app generally has to wait for the real domain lookup before getting a DNS response.

“Reducing the initial connection delay” mainly means giving the app a chance to avoid waiting for the real DNS lookup. It doesn’t mean every web request will be faster. If the bottleneck is the node handshake, packet loss, the destination’s response, or app startup, changing DNS mode may not improve the time to first response. A direct connection may still need a real DNS lookup; that time is part of a later step, not something that disappears from the total.

When comparing modes, keep the network, node, and destination the same. First check whether the app can establish a reliable connection, then compare how long the wait feels. A fast DNS response doesn’t mean the entire page loads faster.

How the reserved address range and mapping table work together

A common fake-ip-range example in mihomo configurations is 198.18.0.1/16. 198.18.0.0/15 is reserved IPv4 address space for network device benchmarking, not ordinary public website addresses. Using a portion of this range for local synthetic addresses helps the core identify these connections. Check the active client configuration for the range in use.

The running core maintains the mapping table; it isn’t a permanent directory of website IPs. Don’t assume a synthetic address will always map to the same domain across different sessions. Copying one to another device, saving it in an app for long-term use, or testing it on its own after restarting the client won’t reliably tell you whether the original domain is reachable.

A minimal DNS configuration example

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
  fake-ip-filter:
    - '*.lan'
    - printer.home.arpa

This YAML shows where the fields go; it isn’t a complete configuration for every network. The addresses under nameserver are illustrative—choose resolvers based on your network, subscription configuration, and actual reachability. fake-ip-filter lists domains that should not receive synthetic addresses. Matching syntax and whether your client lets you edit these fields depend on the core and client version. Keep the two-space indentation, and back up the original configuration before making changes.

Changing only enhanced-mode to fake-ip doesn’t guarantee that it will work. The app’s DNS requests must pass through the client, and traffic to the synthetic address must also be intercepted. On phones, this usually involves the system VPN configuration, the client’s DNS settings, and the selected proxy mode. Some clients manage these settings in their interface rather than reading user-edited YAML.

Which domains belong on the filter list?

The key question is whether the app needs the real address, or whether its connections can consistently pass through the same client core. Don’t add every domain to the filter list: the broader the list, the more lookups return to waiting for real DNS results—and the DNS delays you were trying to avoid may come back.

LAN devices: check where their names are resolved

Printers, NAS devices, and routers often use local names such as printer.lan and nas.home.arpa. If a device-management app needs the real LAN address but receives a synthetic one, try filtering that device’s exact domain first, then check whether the current DNS upstream can resolve local names. Filtering only controls whether Fake-IP is returned; if a public DNS server has no record of the printer’s address, adding a filter alone won’t make the name resolve.

Names ending in .local are often discovered over the LAN with mDNS, not through standard DNS queries. If a device appears in the list but won’t connect when tapped, check LAN permissions, mDNS discovery, the domain or IP used for the actual connection, and the proxy rules separately. If the app connects directly to 192.168.1.1, the Fake-IP filter list won’t affect that IP-based connection.

Games and apps: troubleshoot the specific domain

Game login, matchmaking, and voice chat may use different domains and UDP connections. First identify whether the issue occurs during sign-in, matchmaking, or real-time communication. If only one domain fails with Fake-IP but works with a real DNS response, add a filter for that domain alone. Some apps cache DNS results, so after changing the configuration, force-quit and reopen the app; if needed, reconnect the client to clear old connections and cached results from the test.

Don’t assume that a game using UDP means Fake-IP must be disabled. Whether UDP traffic works also depends on how the client intercepts it, the node protocol, the rules, and the server. For features that use numeric IPs, LAN broadcasts, or device discovery, domain filtering may be irrelevant altogether; adding more domains in that case only makes the configuration more complex.

Troubleshooting on iPhone

If switching DNS modes causes connection failures, endless loading in certain apps, or offline LAN devices, troubleshoot in layers: system interception → DNS response → connection rules → individual app. This makes the cause easier to pinpoint than changing your node, subscription, and DNS upstream all at once.

1. Check that the VPN is connected. On your iPhone, go to Settings → General → VPN & Device Management → VPN to check the connection status, then return to the client and confirm that it’s using the expected configuration. Menu names may vary by iOS version.
2. Check that the configuration is enabled. Review the DNS mode, Fake-IP range, and rule mode in the active profile. If a subscription update switched you to a different profile, check the settings in the profile that’s actually enabled.
3. Tell general failures apart from isolated ones. If no websites load, start by checking DNS upstream reachability, VPN interception, and the node. If only one NAS or app is affected, note the domain or LAN address it accesses.
4. Change one thing at a time. Add a filter for a specific local domain, reconnect, and test again. If nothing changes, undo the edit and check LAN name resolution, direct-connection rules, and app permissions.

Rule mode and DNS mode handle different parts of the process: the former chooses the outbound route, while the latter affects how names are resolved and answered. Adding a domain to a DIRECT rule doesn’t guarantee that the app gets a real IP. Likewise, adding a domain to the Fake-IP filter doesn’t automatically make it connect directly. If you need both real LAN resolution and a direct connection, check each setting separately.

Add a filter only when you’ve confirmed that a synthetic address is disrupting the feature. Keep a copy of the original configuration, note each domain you change and the resulting behavior, and keep the rule only if a retest succeeds.