FakeDNS is worth considering if v2rayNG connects successfully but needs better domain detection or a different DNS path. First understand how virtual IPs are mapped back to domains, then check Android VPN routing, domain rules, and app-level DNS. Enable it one setting at a time and verify the results. FakeDNS cannot fix a broken node or guarantee that every app's DNS queries go through the proxy.
How FakeDNS Works: Preserving Domain Names with Virtual IPs
A standard DNS lookup replaces a domain name with the server's real IP address, and the app then connects to that IP. Once traffic enters a transparent proxy path, the core may see only the destination IP and lose track of the domain the app originally requested. Domain-based routing rules may no longer match, leaving the core to rely on sniffing, IP matching, or the default outbound.
FakeDNS keeps a mapping between domain names and virtual IPs. When an app queries a domain, FakeDNS assigns an address from its pool. When the app connects to that address, the core looks up the domain and selects a direct or proxied route. The virtual IP is not the website's server address and should never be sent directly to the public internet.
A common IPv4 pool for Xray FakeDNS is 198.18.0.0/15, ranging from 198.18.0.0 to 198.19.255.255. This range is reserved for network device benchmarking. It is neither a publicly reachable website address nor a typical private address range for home networks. Seeing an address in this range in a DNS response does not, by itself, mean DNS has been poisoned.
DNS Leaks and Lookup Delays: What FakeDNS Can and Can't Do
For intercepted queries, FakeDNS can generate a local response without asking an external DNS server for the real IP at that stage. This reduces the chance that the local DNS resolver sees the requested domain and avoids the time the app would otherwise spend waiting for that external lookup. The website connection still needs to find the real server, however. Resolution may happen on the proxy server or when a direct outbound connection requires it.
| Traffic path | What FakeDNS does | What to check |
|---|---|---|
| Standard DNS query reaches the core | Returns a virtual IP locally and keeps the domain mapping | Whether UDP/TCP port 53 queries actually enter the processing chain |
| Send the domain through the proxy outbound | Makes the restored domain available to the next connection stage | Server-side resolution policy and DNS egress |
| Select a direct route based on rules | Restores the domain so rules can match | How the direct route resolves the real address |
| App-level encrypted DNS | Its domain queries may not be intercepted | In-app DoH and Secure DNS settings |
| App connects directly to a fixed IP | Without a corresponding query, there is no domain to restore | IP rules and the default outbound |
Whether a DNS leak matters depends on your routing policy. If some domains are meant to connect directly, resolving them on the direct route is not necessarily a configuration problem. The key question is whether domains that should go through the proxy are still being sent to the local network's resolver. A DNS test showing one provider does not prove that every app on the device uses the same path.
Bottom Line: Verify the DNS Path Before Comparing Load Times
Keep the same node and routing rules, then test the target app with FakeDNS on and off. Comparing initial load times is meaningful only if the query reaches FakeDNS and the subsequent connection maps back to the correct domain. A virtual IP arriving sooner does not mean the website itself will load faster.
Before Enabling FakeDNS in v2rayNG: Check the VPN, DNS, and Domain Restoration
On Android, v2rayNG usually uses the system VPN service to create a virtual network interface and pass traffic to the core. This is similar in principle to TUN-based interception on desktop, but the app may not have a separate switch labeled “TUN mode.” First make sure the VPN is running and the target app is included. Then adjust FakeDNS—don't assume that v2rayN's desktop menus apply.
Check the client settings
- Setting
- Sidebar: “Settings” → “Enable FakeDNS”
- Related options
- “Enable local DNS” and DNS settings
- Traffic coverage
- Check the selected apps under “Per-app proxy”
- Apply changes
- Stop the connection, then restart the VPN
Names and menu groups may vary by version. Check the version you have installed, and don't assume similarly named switches do the same thing.
Check the core's processing chain
- DNS response
- The query is sent to FakeDNS
- Address pool
- Common IPv4 range: 198.18.0.0/15
- Domain restoration
- Check the sniffing configuration associated with fakedns
- Routing criteria
- Match domain rules after restoring the domain
Client-generated configurations usually handle the required settings together. In a custom configuration, adding an address pool alone is not enough.
Note your DNS, traffic sniffing, and routing settings before enabling “Enable FakeDNS” under “Settings.” If your version prompts you to configure related dependencies, follow its instructions. Don't enable every DNS option “just to be safe.” Custom configurations may not use the fields generated by the app, so verify the active configuration rather than relying on the switches shown in the UI.
- Standard setup: Prefer the FakeDNS options provided by the client. Don't manually combine them with an unrelated DNS configuration from an unknown source.
- Custom setup: Check that DNS uses
fakedns, and that the relevant inbound'ssniffinganddestOverrideinclude the required FakeDNS restoration handling. - Per-app proxy: Make sure the test app is covered by the VPN. After changing the selection, reconnect the VPN and restart the app.
- System DNS: Search for “Private DNS” in Android Settings and note its current state. If you use custom encrypted DNS, check how it interacts with the VPN rather than assuming a UDP port 53 rule can intercept every query.
Domain-Based vs. IP-Based Routing: Check Rule Order Too
One benefit of FakeDNS is that it restores the domain, giving domain-based rules something to match. For example, once the core has restored the destination domain, it can try the relevant domain rule before evaluating other rules. FakeDNS does not decide which sites should connect directly or add missing rule resources for you.
Routing rules are usually evaluated in the order they're configured. If a custom rule sends the entire virtual IP pool direct before the destination has been restored, traffic may be routed to an unreachable address. Another common mistake is treating an IP's geographic location as the domain's category. A virtual IP is only a local mapping marker; it cannot be used to determine the real server's location.
- Confirm domain restoration first. Use available logs or the active configuration to check whether the inbound restores FakeDNS addresses. Don't start by adding a direct-route rule for
198.18.0.0/15. - Then check domain rules. Make sure the order of specific domains, domain lists, and the default outbound matches your expectations. Watch for broad rules that match too early.
- Check IP-based routing last. With domain resolution strategies such as
IPIfNonMatchorIPOnDemandenabled, routing may still trigger a real DNS lookup. That alone does not mean FakeDNS has stopped working. - Test local network access separately. Printers, router admin pages, and internal domains may depend on local DNS. Keep explicit LAN access rules and check whether the VPN route covers the relevant addresses.
Enable or Roll Back: Test One Variable in the Same App
FakeDNS may help when the node connects normally, but domain rules often fail to match after traffic interception or intercepted standard DNS queries take noticeably longer. If DNS resolution and routing are already stable, enabling it may make no visible difference. For connection refusals, TLS handshake failures, or subscription update problems, troubleshoot the underlying issue first. FakeDNS is not a general-purpose fix for these errors.
- Establish a baseline. Turn FakeDNS off and keep the node, routing, and network unchanged. Check how the browser, target app, and a LAN service behave. Note whether each opens and uses the expected outbound route, not just whether it feels “fast” or “slow.”
- Change only FakeDNS-related settings. Enable the feature under “Settings” and any required dependencies the client recommends, then stop and restart the VPN. Don't change the node, DNS service, or routing mode at the same time.
- Clear stale connection state. Fully close and reopen the test app. If it may be using cached DNS, force-stop it before testing. Also check the browser's “Secure DNS” setting.
- Check both stages. A standard DNS test may show an address from the pool; the actual connection must then succeed. If the lookup works but the connection fails, focus on mapping restoration, VPN coverage, and stale caches.
- Roll back fully if something breaks. Restore the original settings, restart the VPN, then reopen the app. If it still has an old virtual IP, wait for the app's cache to expire or restart the device. Don't work around the issue by pinning a virtual IP permanently.
Bottom Line: Keep FakeDNS Enabled Only If Restoration, Routing, and Rollback Work
If only some apps stop working, check their encrypted DNS settings, per-app proxy coverage, and caches before adding more global rules. If you're unsure how the active configuration handles traffic, restoring the original settings is easier to troubleshoot than changing several DNS and sniffing options at once.
FakeDNS Troubleshooting: Unexpected IPs, App Failures, and Network Changes
The DNS response starts with 198.18. Is something wrong with my node?
First check whether “Enable FakeDNS” is turned on under “Settings.” If the address falls within the configured pool, it's an expected virtual response. Then try opening the target site. Check VPN coverage, sniffing settings, and stale app caches only if the connection can't be mapped back. Don't judge a node by the address alone.
The browser works, but another app keeps loading. What should I do?
Under “Per-app proxy,” check whether the app is covered. Then look for a separate Secure DNS setting in the app itself. Keep the same node, turn FakeDNS off, restart the VPN, and force-stop the app before trying again. If it fails only when FakeDNS is on, check whether the app bypasses the return path for virtual IPs.
A DNS test still shows a local resolver after I enable FakeDNS. Is that a leak?
Check the route used by the tested domain first: it may be set to connect directly, or the app may be resolving it through its own encrypted DNS. Retest with a domain expected to go through the proxy, and check “Secure DNS” in the browser and “Private DNS” in Android settings. Interpret the result alongside the intended route; the resolver's name alone isn't conclusive.
A site stopped opening after I switched from Wi-Fi to mobile data. Do I need to re-import my subscription?
Stop and restart the VPN, then close and reopen the app to rule out stale connections or mismatched mapping caches. A subscription provides node settings; it doesn't clear an app's DNS cache. Investigate network connectivity and node settings only if the node itself also fails to connect.
Can I copy v2rayNG settings directly to v2flyNG?
Don't copy them based on feature names alone. v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. Even if both support similar features, supported fields, defaults, and configuration generation may differ. Check the support offered by your installed client and core, and verify DNS, inbound, and routing settings separately when migrating.