FakeDNS Virtual DNS Mapping Explained: When to Use It and When to Avoid It

FakeDNS does not make DNS answers more accurate—it preserves the domain identity that would otherwise be lost

When an application accesses a domain, it usually asks DNS for the real address before connecting to the returned IP. If a connection reaches the proxy core with only the destination IP, the domain information may already be gone. Rules based on geosite, full domains, or domain suffixes can no longer match directly and must rely on the destination IP, protocol sniffing, or other supplemental data.

FakeDNS returns a temporary virtual address during the DNS stage and stores the relationship between that address and the domain inside the core. When the application connects to the virtual address, the core can recover the original domain and use domain rules to choose a direct connection, proxy, or block action. In essence, it is a short-lived mapping table—not a public DNS service—and the virtual addresses are never published to the internet.

Xray commonly uses a dedicated reserved IPv4 range for its FakeDNS pool, such as 198.18.0.0/15. This range is not the real address of the destination site; it serves only as an index within the local host or a controlled network stack. The exact pool, capacity, and handling depend on the core configuration and client version, so no single default should be treated as universal.

How a request passes through virtual address mapping

Using v2rayN TUN mode as an example, suppose a browser is about to access docs.example.net. With FakeDNS enabled and DNS traffic captured by TUN, the complete flow generally has six steps:

1. The application sends a DNS query for docs.example.net to the system.
2. The TUN network stack captures the query and passes it to the DNS processing chain defined in the core configuration.
3. FakeDNS assigns a virtual IP from its address pool and records the original domain associated with that IP.
4. The application receives the virtual IP and sends TCP or UDP traffic as if it were connecting to an ordinary address.
5. TUN captures the connection again. The core looks up the mapping and restores docs.example.net.
6. The routing module selects an outbound based on the domain rules; the relevant outbound path then performs the real destination lookup.

Application queries the domain
    ↓
TUN captures DNS
    ↓
FakeDNS returns a virtual IP and stores the mapping
    ↓
Application connects to the virtual IP
    ↓
Core restores the original domain
    ↓
Domain route match → select direct or proxied outbound

“Reduce one DNS round trip” means that the application does not have to wait for a public upstream DNS server to return a real IP before opening a connection. FakeDNS can provide the mapping locally at once. This does not mean the entire request no longer involves DNS resolution. A proxy outbound may resolve the domain remotely, while a direct outbound may call a configured DNS server. What is removed is one real-address lookup at the initial stage—not every DNS lookup along the path.

Mappings have a lifecycle. When a cache expires, the core restarts, the configuration reloads, or a pool entry is reclaimed, an old virtual address may no longer resolve to its previous domain. Do not store FakeDNS results as long-term business data or copy them to another device.

How FakeDNS, sniffing, and real DNS divide the work

Domain sniffing and FakeDNS often appear together, but they obtain the domain at different points. Sniffing runs after a connection reaches the core and attempts to extract a hostname from protocol data, such as the Host header in an HTTP request or the server name in a TLS handshake. FakeDNS intervenes earlier, creating a definite mapping when the application queries DNS.

Sniffing depends on identifiable fields being present in the traffic. Protocol changes, different encrypted handshakes, applications that connect directly to an IP, or an initial packet without a usable domain can all produce an empty result. FakeDNS does not need to infer the domain from application payloads; as long as the DNS query and subsequent connection pass through the same controlled network stack, it can recover the name from the mapping.

Real DNS is still responsible for finding the final reachable address. FakeDNS changes the sequence from “the application resolves the domain, then connects to the real IP” to “the application receives a virtual IP, the core restores the domain, and the outbound resolves it later.” This lets the resolution point follow the routing decision: proxy-bound domains can be resolved by the proxy path, while direct domains can use the locally selected DNS server, reducing mismatches between the resolution location and the actual outbound path.

When FakeDNS is a good fit in TUN mode

Fine-grained domain-based routing

FakeDNS is most useful when rules rely heavily on geosite, domain suffixes, or full domains. Even if an application would normally pass only the real IP to the network stack, the core can recover the domain through the virtual address mapping. For configurations such as “proxy specific sites, connect to common local domains directly, and handle everything else with the default rule,” a stable domain identity makes matching easier to understand.

When DNS resolution should follow the outbound path

The same domain can return different addresses from different network locations. Resolving it locally first and then sending the real IP through a proxy can separate the resolution location from the connection location. FakeDNS gives the application a virtual address first, allowing the core to resolve the real destination after selecting the outbound. This order is usually more appropriate when the proxy side should perform domain resolution.

Taking over programs without built-in proxy settings

TUN mode can handle programs that offer no HTTP or SOCKS proxy option. Combined with FakeDNS, it sends their ordinary system DNS queries and subsequent connections through the same processing path. As long as the program uses the system network stack and its traffic is actually captured, domain rules have a more complete set of matching data.

Reducing reliance on protocol sniffing

Sniffing can still provide supplemental information, but it does not have to handle domain recovery on its own. For applications with fast connection setup, inconsistent initial-packet signatures, or UDP-based traffic, a pre-established FakeDNS mapping is often more direct. Note that FakeDNS does not make every UDP protocol compatible automatically; it only maps the destination. Whether the protocol can use the current outbound still depends on the node, core, and routing configuration.

When to disable or bypass FakeDNS

When LAN names and split DNS require real answers

Corporate intranets, home device names, router administration domains, and split DNS often depend on a LAN resolver returning private addresses. If FakeDNS replaces these answers too early, applications may not receive the real records required for service discovery. A common approach is to send internal domains, private address ranges, and designated DNS servers directly, excluding them from FakeDNS. If the exclusions are difficult to verify, disable FakeDNS first and validate LAN access.

When an application reads or validates DNS responses

Some diagnostic tools, network management utilities, DNS testing programs, and business clients do more than connect after receiving an address: they display, save, compare, or validate DNS responses. They need the real contents of A, AAAA, or other records. Virtual addresses change what these programs observe, so they are not suitable for such queries.

When the connection does not follow the same TUN mapping path

FakeDNS depends on a simple premise: “write the mapping during the query, read it during the connection.” If DNS is captured but the subsequent connection bypasses TUN, the application will try to send the virtual address onto the ordinary network. Conversely, if the connection enters TUN while DNS is handled by another device or a separate encrypted resolver, the core may never receive the mapping. When the two paths differ, unify the capture scope first; if that is not possible, disable FakeDNS.

When the resolution result must be passed to another device

A virtual address is valid only within the mapping instance that created it. Writing it to a configuration file, sending it to another host on the LAN, using it for port probing, or reusing it after the core restarts can all fail. In a gateway deployment, verify that DNS responses and subsequent connections always return to the same instance. If a client may switch to another gateway, returning real addresses is more likely to keep behavior consistent.

When troubleshooting requires visibility into the original DNS path

When the issue involves upstream DNS, split DNS, domain pollution, caching, or IPv4-versus-IPv6 selection, FakeDNS adds another translation layer. Temporarily disable it to see which server receives the query, which records are returned, and which address the connection selects. Once the real resolution path is confirmed, re-enable the mapping and compare the results.

Pre-enable checks in v2rayN

The locations of TUN, DNS, and core settings can change between v2rayN versions, and option names may vary with core capabilities. Instead of copying an old interface screenshot, check the data path. The following sequence works for most configurations:

1. Verify that TUN is actually running. First confirm that ordinary application traffic reaches the core, so DNS variables are not added before capture is working.
2. Verify that DNS queries enter TUN. Standalone DNS tools, browser-specific resolver settings, or other network services may cause queries to bypass the mapping path.
3. Check private-network exclusions. Decide according to your environment whether LAN domains, gateway addresses, printers, and internal services should connect directly or be excluded.
4. Simplify the routing rules. For the first test, keep only clear direct, proxy, and default rules so that multiple rule sets do not obscure the result.
5. Enable FakeDNS afterward. Reload the configuration and issue a fresh query; do not judge the result using an old address from the application cache.
6. Review domains and outbounds in the logs. Confirm that the core restored the original domain and identify which route ultimately matched it.

If v2rayN uses subscription nodes, FakeDNS and the node protocol belong to different layers. Node parameters such as VMess and VLESS determine how the proxy outbound connects to the server; FakeDNS operates in the local DNS and routing stages. A working node does not prove that FakeDNS is configured correctly, and a working FakeDNS mapping cannot fix an incorrect server address, port, security layer, or transport setting.

Similarly, when v2rayNG on Android uses the Xray core, distinguish local VPN capture, DNS settings, and the node protocol. v2flyNG uses the v2fly core; its available capabilities depend on the current core and client implementation. Do not copy a desktop configuration field unchanged to another core and assume identical behavior.

How to diagnose common failures

All domains stop opening after enabling it

First check whether DNS queries enter FakeDNS, then verify that connections to the virtual addresses are captured by TUN. If the system routes the reserved range to an ordinary network adapter, the mapping cannot complete its loop inside the core. Also check for conflicts between the address pool and existing local networks, virtual-machine networks, or other tunnels.

Websites work, but LAN devices are unreachable

This is usually not a node failure; an internal name or private address has likely been handled by the wrong path. Check whether LAN domains should use the local DNS server, whether private ranges should connect directly, and whether service-discovery traffic must remain on the physical network. First create exclusions for clearly defined internal ranges, then compare device-name access with direct-IP access.

The logs show only a virtual IP, not the original domain

This means the mapping was not successfully read during the connection stage. Possible causes include different core instances handling the query and connection, an expired mapping, a stale application cache, or traffic bypassing TUN. Close the application, clear the system DNS cache, reload the core, and perform a completely new query and connection; this is usually more effective than repeatedly refreshing the same page.

Rules match the opposite of what you expect

Check the rule order. Routing usually matches rules in configuration order, so a broad IP, port, or domain rule near the top may take over the connection early. Also distinguish the domain restored by FakeDNS, the domain found by sniffing, and the IP returned by final resolution. During troubleshooting, keep one primary matching condition at a time, then restore combined rules after identifying the cause.

Intermittent failures after running for a while

Check whether failures occur after waking from sleep, switching networks, reloading the core, or keeping connections open for a long time. These events can leave an application's cached virtual address out of sync with the current mapping table. Closing and reopening the application, refreshing the DNS cache, and rebuilding TUN can help determine whether stale mappings are responsible. If the issue is frequent, also check the pool capacity and whether many short-lived domains are being queried.

The final choice: follow the traffic path, not the switch label

FakeDNS is a good fit when DNS queries and subsequent connections are captured by the same TUN path, routing needs a stable domain identity, and final resolution can occur at the outbound stage. In this structure, it removes one real DNS wait before the application connects and gives geosite, domain-suffix, and full-domain rules more reliable input.

The conditions for disabling or bypassing it are equally clear: the program must read real DNS records, the LAN depends on split resolution, the virtual address will be passed to another device, or the query and connection cannot be guaranteed to reach the same mapping instance. FakeDNS is not an acceleration feature where more is always better; it is a routing tool that changes the order of resolution.

For an actual configuration, get TUN, real DNS, and basic routing working independently before adding FakeDNS. Change one layer at a time and use the logs to verify the five stages: “query, mapping, connection, routing, outbound.” This makes it possible to tell whether the failure is in DNS capture, mapping recovery, or rule matching instead of blaming every issue on node quality.