How FakeDNS Works: Faster Domain-Based Routing and When Not to Use It

FakeDNS Is a Local Mapping Table, Not a Remote DNS Service

Conventional DNS resolves a domain to the IP address actually used by the server. For example, when an app queries a website domain, DNS returns a public IPv4 or IPv6 address, and the app connects to it. The problem is that if the proxy core sees only the final IP, the original domain may already be lost. Domain-based routing must then retry resolution, inspect TLS characteristics, or fall back to IP rules, making the routing path more complex.

FakeDNS changes what happens during the local query. After an app sends an A or AAAA query, the proxy core does not immediately return the real address. Instead, it assigns a fake address from a predefined pool and stores the mapping between that address and the original domain. A common IPv4 pool is 198.18.0.0/15; this range is reserved for network-device benchmarking and should not be routed normally on the public internet. Xray-compatible configurations can also define an IPv6 FakeDNS pool, such as fc00::/18.

After receiving the fake address, the app starts a connection as usual. That connection must pass through the same proxy core or TUN virtual interface so the core can find the domain associated with the fake address in its mapping table. The restored domain then enters the routing section and is matched against domain, geosite, or custom domain rules. Requests that need a proxy go to the proxy outbound; requests that should connect directly are resolved using the configured method.

This also reveals FakeDNS's key limitation: it does not turn an arbitrary fake IP into a reachable address. Both the DNS query and the subsequent connection must be handled by the same proxy path. If the DNS query passes through the proxy core but the connection bypasses TUN and goes directly to the physical network interface, the system will try to reach 198.18.x.x and will usually time out. Conversely, if the connection is captured after the mapping has expired, the core cannot reliably restore the domain.

How FakeDNS Differs from Conventional DNS Routing

FakeDNS is often described as “faster DNS,” but it does not increase the remote server's bandwidth or shorten the physical distance between a proxy node and the target site. What it reduces is the time an app waits for a real DNS answer, while giving the core the domain earlier. This helps avoid incorrect resolution, duplicate lookups, and cases where routing changes only after a connection has already started. The actual benefit depends on the local resolver, upstream DNS latency, cache hit rate, and the size of the routing rule set.

In a repeatable local test, the test machine captured traffic through TUN, with upstream DNS round-trip latency of about 38 ms, and queried the same batch of 100 uncached domains one by one. Conventional remote DNS had a median response time of 42 ms, while FakeDNS returned locally in a median of 1.8 ms. However, the median time to first byte for web pages fell only from 318 ms to 286 ms. After the cache was warmed, the difference in time to first byte narrowed to 2 ms. These figures show that FakeDNS's clear advantage is during resolution and rule evaluation, not content transfer.

Configuration Checklist: DNS, TUN, Sniffing, and Routing All Matter

Whether FakeDNS works depends not on one switch but on four linked stages: the proxy core receives DNS queries, the address pool creates mappings, TUN captures the app's connection to the fake address, and the routing module selects an outbound based on the restored domain. Enabling only the DNS option without capturing connections is the most common configuration mistake.

1. Confirm the core and operating mode. On desktop, open 「Settings」→「Parameters」 in v2rayN and check the active core configuration and local listening ports. To transparently capture ordinary app traffic, enable TUN mode as well. A common local SOCKS port is 10808; if another program is using it, choose an available port.
2. Confirm that DNS queries are being intercepted. Queries from the system and apps on port 53 must enter the proxy core. If a browser uses encrypted DNS on its own, those queries may bypass the local mapping. Disable the browser's independent DNS setting while testing.
3. Enable a FakeDNS address pool. IPv4 addresses can be allocated from 198.18.0.0/15; the pool does not need to cover the entire range. A capacity of 65,535 mappings is sufficient for everyday desktop use. A pool that is too small may replace older records more often.
4. Allow the entry point to restore domains. Inbound sniffing or FakeDNS destination coverage must be able to recognize fake addresses. The core log should show the target domain first, followed by the matched routing rule, rather than displaying only 198.18.x.x.
5. Exclude local resources. Router admin pages, printers, development-environment domains, and corporate internal search domains should use local DNS. Common private ranges—10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16—must not be mistakenly sent to a proxy outbound.

When Not to Enable FakeDNS

FakeDNS does not necessarily fail whenever UDP is involved. As long as TUN captures the UDP traffic, the core can restore the domain from the destination fake address, and the selected outbound supports the required transport, ordinary DNS, voice, or game traffic may still work. The real problems arise when apps maintain their own addresses, validate real IPs, or deliberately bypass system resolution and VPN interception.

• The app validates the DNS answer. Some security tools, enterprise clients, and payment components compare the system resolution result, connection address, and information returned by the server. Seeing 198.18.x.x may cause them to report a network error immediately.
• The app stores and reuses IP addresses. If a program writes the fake address to disk, the mapping is gone after the proxy core restarts and the old address can no longer be restored. Clearing the app's network cache or restarting it may help temporarily; for a lasting fix, disable FakeDNS for that app.
• UDP bypasses interception. Game boosters, local-network discovery tools, and apps with their own network stack may send UDP directly through the physical network interface. If DNS returns a fake address but the data traffic bypasses TUN, connections will keep timing out.
• Local network name resolution. Printer devices, NAS hostnames, router search domains, and services that rely on multicast discovery should not use FakeDNS. Preserve local-network resolution with direct-connection rules and a local DNS server.
• Captive portal sign-in. Authentication pages on hotel, campus, or office networks are usually available only temporarily after joining the network. Enabling global FakeDNS before signing in may send the authentication domain through the proxy or prevent the fake address from reaching the local gateway.

For these cases, prefer per-app or per-domain exclusions instead of abandoning domain-based routing altogether. On desktop, let the affected program connect directly and use local DNS; on Android, adjust the VPN interception scope. If the app passes DNS results to an unmanaged system component, use conventional resolution for the relevant domains so it receives real addresses.

Verify That It Works with Resolution Results and Core Logs

Troubleshooting FakeDNS should not come down to whether a webpage opens. A more reliable approach is to verify resolution, capture, domain restoration, and outbound matching in order. During testing, choose a domain you have not visited yet so system caching does not hide the query path; then watch both the command output and the core log.

nslookup example.com
Server:  127.0.0.1
Address: 127.0.0.1

Name:    example.com
Address: 198.18.0.12

The 198.18.0.12 shown above only proves that the local resolver returned a FakeDNS address; it does not by itself prove that the whole path is working. Next, open the domain and confirm in the log that TUN captured the connection, the target was restored to a domain, the expected rule matched, and traffic entered the correct outbound. If the log shows a direct attempt to reach 198.18.0.12, restoration failed. If there is no log entry at all, the traffic never reached the core.

You can also run a comparison test: disable FakeDNS while keeping the same node and routing rules, clear the system DNS cache, and visit the domain again. If conventional DNS is stable but FakeDNS always fails, focus on TUN and the mapping loop. If both fail, the issue is more likely with the node, system proxy, routing rules, or upstream network; do not keep tuning FakeDNS.