FakeDNS uses virtual IPs to preserve domain information, making it useful when you need domain-based routing after traffic is captured by TUN. It is neither a speed boost nor a replacement for real DNS resolution. This guide explains how it returns an address, captures the connection, restores the domain, and selects an outbound route—then covers when to enable it, what to check, and how to roll back. For users with a working connection who are adjusting DNS and routing.
How FakeDNS Preserves Domain Information
A standard DNS query resolves a domain name to the address of its server. The app then connects to that address, and the network stack usually sees only the destination IP. When multiple domains share an IP, that address alone may not reveal which domain the app originally requested. FakeDNS changes the response: it assigns a virtual IP and keeps a local record of the domain mapped to it.
For example, an app queries example.com, and FakeDNS assigns it an address from its pool. When the app connects to that address, the proxy core looks up example.com in the mapping table and uses the domain to evaluate routing rules. This address is just a marker in the local processing chain—not a new address for the website, and never an address to use for a remote proxy node.
Virtual IP Pools vs. Real DNS
In Xray FakeDNS settings, 198.18.0.0/15 is a commonly used example of an IPv4 address pool. It spans 198.18.0.0 through 198.19.255.255 and is reserved for network benchmarking—not for directly reachable public destinations. It is not the same as a private address range used on a home network.
The size of an address pool is not the same as the number of mappings it can hold. The number of addresses in a subnet does not mean the current core will retain the same number of mappings. Capacity, eviction policies, and whether mappings survive a restart depend on the implementation. Do not assume a capacity shown in one example is the default for every client.
- Virtual response: Gives the app a destination marker that can be recognized locally, without first obtaining the website's real IP.
- Real resolution: The connection still has to reach the actual service. When a domain is sent to a remote proxy, it can be resolved remotely; for a direct connection, real DNS resolution usually still happens locally.
- Encrypted DNS: Changes how DNS queries are transported. It is a separate concern from returning virtual IPs, and neither replaces the other.
How TUN Works with Domain-Based Routing
TUN sends IP traffic matching its routing conditions through a virtual network interface, but it does not inherently preserve the domain an app queried. FakeDNS gives the core a way to map a destination virtual IP back to its domain, so domain rules can be applied. It is particularly useful for apps that do not use the system HTTP proxy but can be captured by TUN.
TUN with Virtual IPs
- DNS response
- A component with mapping support returns a virtual IP
- Traffic entry point
- Virtual network interface and its routes
- Domain source
- Address mapping between the query and connection
- What to check
- Whether traffic to the address pool returns to the same processing chain
TUN captures the connection; the mapping restores the domain. Both must work to complete the flow.
System proxy passes the domain through
- DNS response
- A virtual IP may not be needed
- Traffic entry point
- HTTP or SOCKS proxy used by the app
- Domain source
- Destination hostname included in the proxy request
- What to check
- Whether the app passes the domain to the proxy
If the app already passes the domain to the proxy, FakeDNS is usually unnecessary.
Once the domain is restored, routing rules still determine the outbound path. FakeDNS does not automatically proxy all traffic or create a direct-connection allowlist. Domain and IP rules—and their order—can still affect the result. For routing by IP geolocation, check whether the rule evaluates the address obtained through real DNS resolution.
When to Use FakeDNS
First identify what information is missing from the current connection, then decide whether to enable FakeDNS. A useful test: the app's connection can be captured, but the core logs show only the destination IP, so the expected domain rule is not matched—and the app's DNS query can also be routed through the same processing chain. Test FakeDNS only if both conditions are met.
| Use case | Recommendation | What to check first |
|---|---|---|
| TUN captures traffic; routing relies mainly on domain rules | Worth testing | Both DNS queries and connections to virtual IPs are captured |
| Browser uses the system proxy normally | Usually keep the current setup | Whether proxy requests already include the domain |
| Office VPN and internal domains used together | Plan exclusions first | Corporate DNS, internal subnets, and route priority |
| App needs to store or verify the real IP | Prefer real DNS resolution | Whether a virtual IP affects the app's behavior |
| Destination is already a literal IP address | A mapping cannot recover a domain that was never provided | Route the connection directly using IP rules |
FakeDNS may reduce the need to wait for real DNS resolution before deciding how to route a connection, but that does not guarantee faster downloads or lower latency. If an app uses its own encrypted DNS, its queries may bypass the local mapping service. Even when regular DNS requests are captured, the app may still receive a real IP instead of a virtual one.
Check These Four Parts of the Processing Chain Before Enabling FakeDNS
In the v2rayN desktop app, check the current TUN, DNS, and routing options under Settings; the exact submenu depends on your version. On Android, v2rayNG uses the Xray core, but VPN authorization only confirms that the app can create a traffic entry point—it does not prove FakeDNS mapping is working. On either platform, record the original settings first, and change one variable at a time.
- Back up your current configuration. Save your DNS servers, routing rules, and core details. Confirm that the node works with FakeDNS disabled, so an existing connection issue is not mistaken for a mapping problem.
- Check the DNS entry point. Find out which resolver the target app uses. Standard DNS commonly uses UDP or TCP port
53; checking that port alone cannot tell you whether a browser is using built-in encrypted DNS. - Check routing for the address pool. If you use
198.18.0.0/15, make sure the range is not in use on your office network and is not routed around the physical network adapter by an earlier rule. Some networks may use this range in practice, so do not use it as-is if there is a conflict. - Check domain restoration. Review the current core's inbound, sniffing, or mapping settings to confirm it can recover a domain from a virtual IP. Xray fields such as
fakedns,ipPool, andpoolSizeserve different purposes. Adding an address pool alone is not enough—you also need an inbound configuration that uses the mapping.
Sniffing and FakeDNS are not the same thing. Sniffing may identify a domain from an HTTP hostname or TLS handshake information; mapping relies on a previously recorded DNS query. Different traffic exposes different information, so do not assume sniffing can recover the domain from every encrypted connection. If the client generates its configuration automatically, manual edits to the generated file may also be overwritten on the next launch.
How to Verify Virtual IPs and Rule Matches
For testing, choose one ordinary domain and one internal destination that should connect directly. Close existing connections, then query and connect again. Do not judge the result from a page that was already open: connection reuse and DNS caching may preserve results from before the change.
- Step 1: Check the DNS response. On Windows, run
nslookup example.com. If the tool's resolver path actually goes through FakeDNS, the response should fall within the configured address pool. A different result does not necessarily mean the feature is broken; first check whether the tool bypassed the resolver path used by the app. - Step 2: Check the core logs. Visit the domain again and see whether the logs show the original domain, the matched rule, and the outbound. Available fields vary by log level. Temporarily increase the log level if needed, then restore it afterward.
- Step 3: Check direct connections. Test an internal domain and a local network service to make sure they are not being sent through the proxy by mistake. Record the domain, DNS response, matched outbound, and whether the connection succeeded. Change only one setting at a time.
Direct-Connection Conflicts and How to Roll Back
The most common failure is that an app receives a virtual IP, but its connection takes a path that cannot access the mapping. For example, a process may be excluded from TUN while still using the intercepted system DNS, or a corporate VPN may take over the address-pool range. These are not node speed issues; switching nodes repeatedly usually will not help.
One app that should connect directly stops working after enabling FakeDNS. What should I do?
First check whether the process is excluded from TUN. If it must connect directly, make sure it receives a real DNS response and that its connection also takes the direct route. DNS exclusions and traffic exclusions must be configured together: excluding the process while continuing to give it virtual IPs is not enough.
Why do connections still time out after I turn off FakeDNS?
The app or operating system may still have an old virtual IP cached. Restore the original DNS settings and restart the affected app. On Windows, run ipconfig /flushdns in Command Prompt to clear the system DNS cache, then reconnect. The browser's own cache and existing long-lived connections may also need to be cleared or recreated separately.
Some connections fail after restarting the client. What should I do?
Check whether the app retained an old DNS result while the core rebuilt its mapping table. Close existing connections, clear the relevant caches, and query again. Some implementations may persist mappings, but this depends on the backend; do not assume mappings are identical before and after a restart.
Does seeing a virtual IP prove that DNS isn't leaking?
No. It only shows that this particular query received a virtual response. Other apps, record types, or a browser's own resolver may behave differently. Check the system resolver, the app's encrypted DNS, and IPv6 AAAA queries separately, then verify the actual routing.
If your goal is reliable access rather than testing the mapping mechanism, prefer settings that are easy to understand and roll back. If the system proxy already passes domains correctly, there is no need to add FakeDNS. If you need domain-based routing with TUN, verify DNS, mapping, routing, and outbound selection one at a time. For connection failures you cannot identify, continue with the connection troubleshooting steps instead of changing every network option at once.