Clash Fake-IP Mode Explained: Redir-Host Differences and Use Cases

Fake-IP does not forge public destinations; it preserves the domain context

When an application accesses a website, it typically looks up the domain's IP address first, then establishes a TCP or UDP connection to that address. In a traditional DNS flow, the real address is handed directly to the application—for example, example.com resolves to a public IPv4 address. Once traffic enters the proxy core, the target may appear only as an IP. If rules match domains, GEOSITE, or domain suffixes, the core must recover the domain through sniffing, DNS mappings, or an additional lookup.

Fake-IP changes the local DNS response stage. After mihomo receives the application's query, it assigns a synthetic address from a reserved pool, commonly 198.18.0.1/16 by default, and stores the “synthetic address—original domain” mapping in its internal table. The application then connects to the synthetic address. TUN, transparent proxying, or a controlled network stack sends that traffic back to the core, where mihomo can identify the original domain from the mapping.

Application queries www.example.com
        ↓
mihomo DNS returns 198.18.0.23
        ↓
Application connects to 198.18.0.23:443
        ↓
mihomo looks up www.example.com in the mapping table
        ↓
Select a policy group and node by domain rule
        ↓
Connect to the real destination through the proxy node

198.18.0.0/15 is a reserved address range for network equipment benchmarking, not a public range used by real internet websites. mihomo commonly uses 198.18.0.1/16 as its Fake-IP pool. A synthetic address serves only as an index within the local proxy path; it must not be sent directly to a regular gateway or routed beyond the core.

Why Fake-IP is usually more direct than Redir-Host

Redir-Host still returns the real DNS result to the application. The application connects to the real IP, and the core then associates it with a domain using existing DNS records, hostnames in the traffic, or sniffing. The benefit is behavior close to standard system DNS, making it easier to support LAN devices, some games, and software that accepts only real addresses. The trade-off is waiting for the upstream DNS response on the first lookup, while caching, CDN addresses, and concurrent requests can make domain-to-connection matching more complex.

Fake-IP can answer immediately from the local address pool instead of waiting for public resolution to finish before returning a result to the application. “Saving one lookup” means the application does not have to wait for a real address before opening a connection; it does not mean DNS is never needed anywhere in the path. If the proxy server's domain must be resolved locally, or the final outbound connection needs the destination IP, mihomo still resolves it according to proxy-server-nameserver, nameserver, and the policy configuration.

What actually happens in one request

1. The application sends an A or AAAA query to system DNS, commonly over UDP or TCP port 53.
2. System DNS traffic is sent to mihomo's DNS module instead of being forwarded uncontrolled to the router or the ISP's DNS.
3. mihomo assigns a Fake-IP to the domain and writes the mapping to its in-memory cache.
4. The application connects to that address, for example 198.18.0.23:443.
5. TUN routing or transparent proxy rules hand the connection back to mihomo.
6. The core restores the domain and matches it against DOMAIN-SUFFIX, rule sets, process rules, and other criteria.
7. Only after selecting a DIRECT or proxy policy does the core establish the corresponding real outbound connection.

mihomo Fake-IP Basics and Configuration Fields

When configuring the core, enable Fake-IP in the YAML dns section. If a GUI client provides an override, open “Settings” → “Configuration” or “Settings” → “Preferences,” then find the DNS or global extension settings. Menu names vary by client and version; the YAML actually generated and passed to mihomo is the source of truth.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://223.5.5.5/dns-query
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://223.5.5.5/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost"
    - "time.*.com"
    - "time.*.gov"
    - "+.stun.*.*"
    - "+.stun.*.*.*"

What the core fields control

• enable: Enables mihomo's built-in DNS module. If only enhanced-mode is set while the DNS module is inactive, application queries may still bypass it and reach the system upstream.
• listen: The DNS listen address and port. The example uses 1053 to avoid requiring regular user privileges to bind 53. On a router, dnsmasq must also forward requests to this port.
• enhanced-mode: fake-ip: Returns synthetic addresses for eligible domains. Switching to redir-host returns the real DNS results instead.
• fake-ip-range: The synthetic address pool. After changing it, also check TUN routes, firewall rules, and side-router policies so the entire range is handled by mihomo.
• default-nameserver: Usually contains directly reachable IP addresses used to resolve the hostnames of DoH or other DNS servers, preventing a resolution loop.
• nameserver: The upstream for regular domain resolution. Whether requests use the proxy also depends on DNS follow policies and outbound settings.
• proxy-server-nameserver: Handles proxy node hostnames specifically. When a node address is a domain, this separates node resolution from ordinary destination resolution.
• fake-ip-filter-mode: blacklist: Domains in the list do not use Fake-IP and receive real results instead. Switching to whitelist logic reverses the list's meaning, so check both together when migrating a configuration.

Which domains should fake-ip-filter exclude?

The purpose of fake-ip-filter is not to exclude every commonly used website. It returns queries that require real addresses to the normal resolution path. A filter that is too broad gradually removes Fake-IP's benefit of quickly associating domains; one that is too narrow may give LAN discovery, time synchronization, login checks, or real-time communications synthetic addresses they cannot use directly.

LAN hosts and local domains

NAS devices, printers, router admin pages, and home automation devices often use .lan, .local, or custom internal suffixes. If a device returns 192.168.1.20, the application often needs to connect directly to that real LAN address. Add the relevant suffixes to the filter list and ensure the local DNS server can answer those names.

.local is also commonly used with mDNS. mDNS uses multicast and UDP 5353, so it is not the same as ordinary unicast DNS. Adding a filter alone may not fix discovery across subnets; VLANs, guest Wi-Fi networks, and side-router setups also require checking multicast forwarding and firewall boundaries.

STUN, gaming, and real-time communications

Some games, voice-calling apps, and WebRTC software use STUN to determine the public exit address and NAT type. They may use the DNS result directly for UDP probes or verify candidate addresses returned by the server. If enabling Fake-IP causes connected-but-silent voice calls, disconnects after room matching, or a NAT type change from open to strict, first filter the relevant STUN domains instead of switching all DNS back to Redir-Host.

Gaming acceleration does not automatically mean Fake-IP must be disabled. Many game launchers that rely on HTTPS login, content downloads, and domain-based routing work normally with Fake-IP. The key questions are whether the game itself depends on UDP, whether it strictly validates server addresses, and whether the related traffic is fully intercepted by TUN. During troubleshooting, test launcher login, resource downloads, matchmaking, and live gameplay separately.

Network checks, time synchronization, and device login

• System connectivity-check domains may use specific status codes or fixed addresses to determine whether an authentication page should be opened.
• NTP commonly uses UDP 123; some devices directly verify the returned address or bypass the system proxy.
• Smart TVs, game consoles, and IoT devices may accept only real A records and may not send subsequent traffic through mihomo on the computer.
• Corporate internal domains may use split-horizon DNS, returning different results on the company network and the public internet; send them to the designated internal DNS.

Add filters one failing domain at a time and record the reason for each addition. A maintainable list usually contains local domains, service domains with confirmed compatibility issues, and essential probe domains—not hundreds of rules copied from an unknown source.

Can Fake-IP work in TUN mode? It depends on complete interception

Fake-IP addresses have no public routing meaning, so application connections must enter mihomo. After enabling TUN on a desktop client, the core typically creates a virtual network interface and installs routes; router transparent proxying may rely on policy routing, nftables, or iptables. Enabling DNS enhanced mode without intercepting 198.18.0.0/16 commonly results in fast resolution but web pages that time out.

Four paths to check together

1. DNS query path: Does the application's query actually reach mihomo? Browser security DNS, Android Private DNS, and manually configured LAN DNS can all change the path.
2. Fake-IP routing: Does 198.18.0.0/16 point to the TUN or transparent proxy path rather than the default gateway?
3. Rule matching: Does the domain restored from the connection match the expected rule, and did the final policy group select an available node?
4. Real outbound path: Can the node hostname, destination hostname, and IPv4/IPv6 paths be resolved and reached correctly?

If IPv6 is enabled but the configuration intercepts only IPv4, the application may prefer AAAA results and take another path. During testing, temporarily set ipv6: false to narrow the scope. Once the IPv4 Fake-IP path works, add the required IPv6 routes and DNS policies. For long-term use, decide based on whether the local network has a stable IPv6 exit rather than hiding routing problems by simply disabling the option.

Use concrete commands to verify Fake-IP and rule matches

Do not judge the configuration only by whether a webpage opens. First query mihomo's DNS listen port directly, then inspect system routes and core logs. The examples assume DNS listens on local port 1053 and the mixed proxy port is the common 7890.

nslookup www.example.com 127.0.0.1
dig @127.0.0.1 -p 1053 www.example.com A
curl -x http://127.0.0.1:7890 https://www.example.com/

If dig returns 198.18.x.x, the domain has entered the Fake-IP flow. If it returns a real public address, check whether the domain matches fake-ip-filter, whether the active configuration is still redir-host, and whether the query actually went to the configured listen port.

Local query response times should usually be measured in milliseconds. On the same device and network, run 10 consecutive queries and compare the first response—for example, a local Fake-IP response may take 2–8 ms, while the first real DoH lookup may take 30–150 ms. Device performance, upstream distance, and caching affect the numbers; compare differences in the same environment rather than treating a fixed latency as a universal standard.

Common failures and troubleshooting order

When to enable Fake-IP—and when to start with Redir-Host

Cases that favor Fake-IP

• Desktop use with TUN intercepting most applications and a need for reliable domain-rule matching.
• Subscriptions with many domain rules, rule sets, and domain-based policy groups.
• Noticeably slow first lookups from the local upstream DNS, with a need to reduce application wait time for real resolution.
• Applications that must use the proxy despite system proxy settings, with both TCP and UDP managed by mihomo.
• A willingness to maintain a precise filter list for LAN services, games, and real-time communications.

Cases where starting with Redir-Host is safer

• The device sends DNS to mihomo, but actual connections do not pass through TUN or a transparent proxy.
• Corporate networks that rely heavily on split-horizon DNS, fixed real addresses, and internal security appliances.
• LANs with many legacy devices whose behavior cannot be observed and whose filter domains cannot be maintained individually.
• Troubleshooting UDP, gaming, or device discovery where an ordinary-DNS-like baseline is needed first.
• Existing routing rules cannot guarantee that 198.18.0.0/16 always returns to mihomo.

The two modes are not a matter of a newer or older core; they are different DNS interception strategies. After mihomo took over from the old Clash Meta core, it continued expanding DNS, rule-set, and TUN capabilities, but the mode should still follow the network topology. Desktop, side-router, main-router, and container environments have different DNS entry points, so copying the same configuration does not guarantee the same result.

A practical migration and tuning sequence

When switching from Redir-Host to Fake-IP, keep the existing proxy rules and nodes at first and change only the DNS enhanced mode, avoiding multiple variables at once. After loading the configuration, query three targets: an ordinary public domain, a LAN domain, and a known filtered domain. The public domain should return a synthetic address; the latter two should return real addresses as designed.

1. Back up the working configuration and record the DNS listen port, TUN setting, and system proxy port.
2. Enable enhanced-mode: fake-ip, keeping the default address pool or explicitly planning a custom range.
3. Confirm that system routes cover the entire Fake-IP address range.
4. Start by adding clear local filters such as *.lan and *.local.
5. Test the browser, instant messaging, games, NAS, and TV box separately; do not test only one website.
6. Use logs to add the smallest possible filters, and annotate each rule with the corresponding failure.
7. Remove obsolete filters so the list does not keep growing until it effectively becomes Redir-Host.

If switching causes many problems, reverting to Redir-Host as a baseline is a valid engineering troubleshooting step. Once you confirm the issue occurs only with Fake-IP, check the DNS entry point, address-pool routing, filter list, and UDP interception. Tracing the path layer by layer is more likely to reveal the real cause than repeatedly changing subscriptions, nodes, or the entire configuration.