How Fake-IP Preserves Domain Names: DNS Mapping, Use Cases, and Exclusions

1. Fake-IP vs. Real Address Resolution

With Fake-IP enabled, an A-record lookup for a website may return an address such as 198.18.0.2 instead of the website server’s public IP. This is usually a virtual address generated by the core, so it should not by itself be treated as evidence of a DNS failure. Its purpose is to give the subsequent connection a lookup key that the core can use to recover the domain associated with the request.

A regular DNS lookup returns a real address, after which an application may submit only the destination IP to the network stack. When multiple domains share a CDN address, it is difficult to identify the original hostname from that IP alone. Fake-IP creates a “domain-to-virtual-address” mapping during the DNS response; once the connection reaches the same core, the domain can be recovered from that mapping before rules and outbound handling are applied.

Fake-IP is not a proxy node: it is an address marker in the local processing path, not the location of a remote server.
Fake-IP is not DNS encryption: whether the upstream uses UDP, DoH, or DoT is a separate configuration layer.
Fake-IP is not the same as global proxying: with mode: rule, connections still follow rules to destinations such as direct access or a proxy.

198.18.0.0/16 is within the 198.18.0.0/15 address space reserved for network benchmark testing. It is neither a website’s real public address nor a typical home LAN subnet. If the device’s network already uses this range, resolve the routing conflict first instead of adding more interception rules.

2. Five Steps from DNS Query to Outbound Connection

The key to understanding Fake-IP is to separate two paths: where the DNS query goes and where the connection goes after receiving an address. The virtual address is useful only when both paths can reference the same valid mapping.

The application sends a query. For example, a browser requests the A record for example.com; the query reaches the core through the system resolver, DNS forwarding, or TUN DNS interception.
The core assigns a virtual address. If the domain qualifies for Fake-IP handling, the core returns an address from its pool and stores the mapping. This article uses 198.18.0.2 to illustrate the process; the actual assigned address is not fixed.
The application opens a connection. The application connects to the destination port on the virtual address, such as HTTPS port 443.
The core looks up the domain and matches rules. After receiving the connection, the core uses the mapping to identify example.com, giving domain-based rules the information they need to match.
Outbound handling follows the selected route. Direct connections generally need the real destination address; a proxy outbound may send the domain to the remote side for resolution or resolve it locally, depending on the protocol, node options, and core behavior.

Application queries example.com
  → Core DNS returns a virtual address
  → Application connects to virtual address:443
  → The same core looks up example.com
  → Match rules
  → Direct or proxy outbound

Therefore, “DNS returned a Fake-IP” proves only that part of the query path worked; it does not prove that the connection was intercepted. If the application receives a virtual address but sends traffic directly without going through the core, the regular network does not know which website to deliver it to, often resulting in a connection timeout.

Why Can Real DNS Queries Still Occur When a Domain Mapping Exists?

Fake-IP can give an application a virtual response first, but it does not guarantee that the entire connection process will avoid real-IP lookups. Direct outbound connections, rule checks that require a destination IP, and domain resolution performed by the proxy server itself can all trigger resolution. Whether a rule includes no-resolve and whether the core supports the relevant rule option also affect the process. “Reducing some wait time” should not be interpreted as “eliminating every DNS query.”

3. Check DNS and Connection Interception Before Enabling Fake-IP

Fake-IP is best suited to environments that need transparent interception while retaining domain information for rule matching, such as a desktop TUN with correctly configured routing and DNS interception. It is not a universal fix for application connectivity problems.

Method	Source of Domain Information	Priority Check
HTTP System Proxy	Proxy requests usually include the target hostname	Whether the application follows the system proxy; this does not prove that DNS for the entire device is intercepted
TUN Transparent Interception	The domain can be recovered through the Fake-IP mapping	Whether the DNS query and virtual-address connection enter the same core
LAN Gateway	The mapping is created by the gateway’s DNS	Whether the endpoint DNS, gateway routing, and return path are consistent
Application-Built-in Encrypted DNS	It may bypass the core DNS and obtain a real IP directly	The application’s secure DNS, the system’s encrypted DNS, and any existing VPN settings

TUN provides a virtual network interface and interception path, while Fake-IP provides DNS mapping; they operate at different layers. Enabling TUN does not mean every application’s DoH request will become a regular DNS query, and enabling DNS enhanced-mode: fake-ip does not automatically replace all system routing.

Record the client version, core name, and core version, and confirm that the active process is not a different background instance.
Save the currently active configuration along with override snippets maintained separately by the client. Backing up only the original subscription may omit DNS settings.
Check whether another VPN, gateway utility, or security product is also modifying DNS or routing.
For the first test, change only the DNS mode and the required interception settings. Do not change nodes, proxy groups, and rule order at the same time.

4. Fake-IP Configuration Snippet and Field Boundaries

mixed-port: 7890
mode: rule
allow-lan: false

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-mode: blacklist
  fake-ip-filter:
    - "localhost"
    - "*.lan"
    - "*.home.arpa"
  nameserver:
    - 1.1.1.1

Do Not Mix Up the Two Ports

7890 is the example’s combined HTTP/SOCKS proxy port; 1053 is the core’s DNS listening port. Do not enter the DNS port in a browser’s proxy settings. Most system DNS settings also cannot specify a non-standard port directly, so this snippet is suitable for query tools that accept an explicit port; loading the YAML alone will not automatically intercept system DNS.

listen: 127.0.0.1:1053 limits the listener to the local machine. Other devices on the LAN cannot use it as a DNS server. Serving the LAN requires separate planning for the listen address, firewall, and traffic routing. allow-lan: false controls LAN access to the proxy entry point and cannot replace the security settings for the DNS listener address.

The Filter Mode Must Match Core Support

In mihomo builds that support fake-ip-filter-mode, the example explicitly selects blacklist: domains matching the list do not receive Fake-IP and instead use real resolution. With whitelist, the list semantics are reversed, so only matching domains use Fake-IP. Older cores may not support the mode field; an unknown field being ignored is not evidence that the configuration succeeded.

The example ipv6: false narrows the scope of this DNS test. It does not disable IPv6 in the operating system or prove that other resolution paths will not return AAAA records. Reassess this setting in production alongside IPv6 routing and the actual core’s capabilities. Check additional fields against the complete configuration reference.

5. LAN Compatibility Issues and Choosing Exclusions

Some applications need a real address, not merely a marker that can establish a connection. For example, a NAS management tool may check whether a server is on the local subnet, a printer utility may pass the result to a discovery component that bypasses the proxy, and some programs may send the IP address to other devices. In these cases, preserving real resolution for one domain is usually easier to control than excluding every domain.

Excluding Fake-IP Does Not Specify the LAN DNS Server

Adding "*.home.arpa" to the filter list only tells the core to query for a real address. Public DNS usually has no records for hosts on a home network. If the router provides the NAS hostname, the domain must still be sent to the router’s DNS, for example through a supported nameserver-policy entry for targeted resolution, and the router’s DNS service must be reachable.

.local is commonly used by mDNS, which is fundamentally different from sending a regular query to a unicast DNS server. Adding "*.local" to the list does not automatically restore multicast discovery or turn the core into an mDNS forwarder. If casting or printer discovery fails, also check LAN permissions, multicast traffic, and the TUN routing scope.

Start with a specific domain: when one device has a problem, test that device’s hostname first instead of immediately adding a broad wildcard.
Then confirm the resolution source: after exclusion, the response should be a real address from a trusted local DNS server, not a nonexistent-domain response from public DNS.
Finally check the connection rule: receiving a real address does not mean the traffic will automatically go direct; rules may still send the domain to a proxy group.

Different clients may replace or merge list overrides, and the core may have version-dependent default exclusions. After editing, inspect the final active configuration rather than only the new lines in the editor. Do not exclude every domain just to eliminate one compatibility issue; doing so makes it difficult to verify whether Fake-IP is actually being used.

6. Verify in the Order of Query, Mapping, Rules, and Outbound

1. Verify the Core’s DNS Response Separately

On macOS, Linux, or another environment with dig installed, run the following against the local listening address above:

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

If the domain is not excluded, a virtual IPv4 address within the configured range is expected; the exact address is not fixed. If the request times out, first check whether the core is running, DNS is enabled, and 1053 is already in use. If a real address is returned, verify the filter mode, default exclusions, and whether the active configuration actually contains the change. This describes expected behavior; it is not a live test record from this site.

2. Verify Connection Interception with the Actual Application

After confirming that the system or application DNS enters the intended path, open the test domain in a browser while watching the client’s connection log. Check the target domain, matched rule, outbound policy, and connection error—not merely whether the page loads. Running dig directly against the core does not automatically make the browser use the same resolution path.

An explicit HTTP proxy request usually carries the hostname, so “success through the proxy port” verifies only that proxy path; it does not by itself prove that TUN Fake-IP lookup is working. Likewise, the result of ping to a virtual address is not a suitable test for HTTPS availability: ICMP handling differs from TCP connections.

3. Identify Where the Error Occurs

Symptom	Priority Check	Next Step
A virtual address is returned, but no connection appears in the log	Check whether the application is bypassing the core	Check TUN routes, application exclusions, and other VPNs
Some websites fail after the core restarts	Check whether the application still holds an old virtual address in its cache	Close old connections, flush the DNS cache, and query again
The NAS domain still cannot be resolved after exclusion	Check whether the domain was sent to a DNS server that knows the local record	Check targeted resolution and the router’s DNS response
The domain and rule are correct, but the outbound connection times out	Check whether the node, direct destination, or outbound resolution is available	Troubleshoot the next link in the chain instead of expanding the filter list

4. Clear Caches Before Repeating a Single-Variable Test

On Windows, run ipconfig /flushdns to clear the system DNS cache; on Linux with systemd-resolved, run resolvectl flush-caches. Browsers, applications, and the core may have separate caches, and a system command does not clear every layer. Close old connections in the test application and start a new request to reduce interference from stale results.

Supported cores can persist mappings with profile.store-fake-ip, but this is not a substitute for routing configuration and does not guarantee that external caches and mappings stay synchronized. After changing the address pool or clearing the core cache, let the application resolve the domain again.

7. Common Questions and Rollback Options

Does Fake-IP Guarantee That Every Domain Rule Will Match?

No. Matching can be affected when an application connects directly to an IP, uses its own DNS path that bypasses the core, loses the mapping, or is intercepted by an earlier rule. Traffic sniffing can sometimes recover a hostname from the protocol, but it is a separate capability and is not guaranteed to work with encrypted or non-standard protocols.

With Fake-IP Enabled, Are All Domains Resolved by the Proxy Server?

No. Seeing a virtual address only means that the local DNS response used a mapping mechanism. Whether real resolution occurs locally or remotely still depends on the rules, outbound protocol, and node configuration. The proxy server’s own domain also needs a working resolution path; avoid creating a loop that depends on a proxy connection that has not yet been established.

Do I Need to Update the Subscription After Editing the Filter List?

Usually, reload the client configuration or core and have the application query again; updating the subscription is not a required step. If you edit a file generated from the subscription directly, the next update may overwrite the change. Save it through the persistent override mechanism supported by the client, then inspect the final configuration to confirm the list semantics.

If a large number of connections fail, first restore the previously saved DNS and interception configuration, then deal with system and application caches. Changing the mode back to redir-host while retaining stale virtual-address cache entries may prolong the problem; exiting the client while leaving the system proxy or DNS pointed at a stopped local port can create a new appearance of network failure.

When sharing troubleshooting information, retain the client and core versions, query commands and results, matched rules, and error times, while removing subscription URLs, tokens, and node credentials. The goal is to verify that the query and connection enter the same core, the domain mapping is valid, and the rules and outbound route behave as expected—not simply to make the DNS result display an address from a particular range.