FakeDNS returns an address that lets a local proxy identify a domain—not the destination server’s real address. This guide is for v2rayN users configuring TUN mode or troubleshooting virtual IP and DNS issues. Follow the query, mapping, and outbound steps to decide whether FakeDNS fits your setup, then check caches, routing rules, and address conflicts in a reproducible order.
What Is FakeDNS? Keeping a Domain Hint in an IP Address
A standard DNS lookup resolves a domain to the destination service’s real IP, and the app connects to that address. FakeDNS instead assigns a virtual IP from a predefined pool, stores the domain-to-IP mapping locally, and returns the virtual IP to the app. Think of it as a claim ticket: only a component with access to the mapping can recover the domain it represents.
For example, an app queries example.com, and FakeDNS might return 198.18.0.10 from its pool. The app connects to that address on port 443; the interception component looks up the mapping, recovers example.com, then passes it to routing and outbound handling. This is an illustrative example: the domain is not permanently tied to that address, which is not a publicly reachable service.
The key is not that FakeDNS “makes up an address,” but that the component returning the address and the one handling the subsequent connection must share or coordinate mapping state. If DNS returns a virtual IP but the connection goes to a regular gateway, it will usually fail. FakeDNS does not encrypt traffic; proxy protocols such as VMess and VLESS operate at a different stage.
Virtual IP Pools: Address Count Isn’t Mapping Capacity
In V2Ray/Xray FakeDNS configurations, a commonly used IPv4 pool is 198.18.0.0/15. This range is reserved for network device benchmarking, not ordinary public internet destinations. The three figures below describe the address range, an example mapping capacity, and the standard DNS service port—not performance benchmarks.
ipPool sets the available address range; poolSize sets the mapping pool capacity. They are not interchangeable. With many domains, long runtimes, or mapping eviction, an old address may no longer match the current mapping; eviction behavior depends on the implementation. Apps may also retain stale DNS results, so a virtual IP cached before the core restarts may no longer be recognized correctly.
Troubleshooting: Check for Address Conflicts Before Expanding the Pool
If a corporate VPN or lab network already uses 198.18.0.0/15, check the active routes and pool for conflicts first. Increasing poolSize cannot fix overlapping routes or restore mappings lost in a restart.
Why FakeDNS Is Often Used with TUN
TUN receives IP packets at the network layer, where the visible destination is usually an IP address—not the domain the app originally requested. Since multiple domains can share a real IP, it is difficult to reliably recover the original domain from the IP alone. FakeDNS keeps the domain in a mapping table, making it easier to apply domain-based routing to subsequent connections.
TUN and FakeDNS are not a matched pair of switches. TUN can work with real DNS resolution, and FakeDNS can be used with other interception-capable paths. TLS or HTTP sniffing may reveal domain information in some cases, but it does not cover every protocol or encrypted connection and is not a direct substitute for a mapping table.
- Best for: Intercepting apps that ignore system proxy settings while retaining domain-based routing.
- Check first: Make sure the app’s DNS queries enter the configured DNS processing chain and that connections to returned virtual IPs follow the same interception path.
- No need to enable it by default: If your browser passes domains through an explicit proxy and the system proxy meets your needs, keep your current setup.
- It cannot fix: Apps that connect directly to a hard-coded real IP without a domain lookup. FakeDNS cannot recover a domain that was never queried.
Reading the Configuration: DNS Assignment and Connection Recovery Must Work Together
The cards below identify related fields in an Xray-style configuration. They are not complete, runnable configurations and should not be pasted into arbitrary client fields. The client may overwrite manual edits when it generates its configuration; if TUN uses a different DNS implementation, its field names and behavior may differ too.
DNS assignment
- Top-level configuration
fakednsarray- Address pool
ipPool: 198.18.0.0/15- Mapping capacity
poolSize: 65535- DNS server entry
- Use
fakednsindns.servers
The assignment side must actually handle app queries. Defining a pool without connecting it to the DNS request path will not automatically take over system resolution.
Inbound recovery
- Inbound sniffing
sniffing.enabled: true- Recovery type
destOverride: ["fakedns"]- Target handling
- Recover the domain, then pass it to routing and outbound handling
- What to verify
- Inbound target, domain, and outbound logs
The recovery side must be able to access the corresponding mapping. Don’t send an unrecovered virtual IP to a regular direct outbound.
In v2rayN, start by checking the current base configuration under Settings → Parameter settings, then review the DNS and TUN options available in your version. Option locations and names can change. Focus on identifying what handles DNS, assigns virtual IPs, and receives connections rather than searching mechanically for a checkbox with a matching name.
v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core, but desktop configuration fields should not be copied directly into Android app settings. Refer to the options exposed by the client, the included core version, and runtime logs. A subscription usually provides node details; that does not mean it has configured DNS interception for the entire device.
What Does “One Fewer Lookup” Actually Mean?
FakeDNS can eliminate the local lookup for the real destination IP that would otherwise happen before an app connects. It does not mean DNS is no longer needed at any point. If a proxy outbound sends the domain to a remote server, the remote server may resolve it. For a direct route, the local outbound usually still needs the real IP to connect.
| Connection path | Result returned to the app | Where resolution happens next | Notes |
|---|---|---|---|
| Standard DNS, then direct | Real IP | Usually resolved before connecting | App connects using the resolved address |
| FakeDNS, then proxy | Virtual IP | May be resolved by the proxy server | Depends on whether the outbound passes the domain |
| FakeDNS, then direct | Virtual IP | Usually still needs local real-IP resolution | Avoid returning another virtual IP and creating a loop |
| App’s built-in encrypted DNS | Depends on the app’s resolution path | May bypass local FakeDNS | Intercepting port 53 alone is usually not enough |
Treat domain rules and IP rules separately. Once the domain is recovered, domain rules can match it directly. IP geolocation rules may still need a real address, and whether that triggers a lookup depends on the routing policy. Don’t treat 198.18.0.10 as evidence of the destination server’s location, and don’t assume enabling FakeDNS routes all DNS through the proxy.
Troubleshooting: Verify Routing in Outbound Logs, Not by Virtual IP Location
Choose one service that should go direct and another that should use the proxy. Start fresh connections to each and check which outbound is actually used. If you see only an IP from the pool and no expected domain or outbound, fix the recovery path before changing domain rules.
Compatibility Issues: Check Caches, Bypasses, and Special Networks
The most common failures are not “every site is slow.” Instead, a few apps stop working, existing connections fail after a core restart, or a corporate intranet suddenly becomes unreachable. Change one condition at a time and keep a working baseline you can restore; changing the node, DNS, and routing all at once makes the cause hard to identify.
Why does a lookup return an address starting with 198.18, yet the website still opens?
If your current configuration uses this address pool, that result is expected. Check the logs to confirm the domain is recovered and the correct outbound is selected. Don’t enter the address as a node server address or send it to another device as a real destination.
Why can’t some apps connect after restarting the client?
Completely quit the affected app, then reopen it so it performs a fresh DNS lookup. If it still reuses an old address, clear the system DNS cache. On Windows, run ipconfig /flushdns. On Linux with systemd-resolved, run resolvectl flush-caches. These commands do not clear every app’s own cache.
Why do browsers work while games or LAN discovery fail?
First disable FakeDNS while leaving the rest of the configuration unchanged, then test again. Some apps rely on real IPs to determine network scope, and LAN discovery may depend on broadcast or multicast. Set up real resolution and direct-route exceptions for local domains and internal networks, then verify that TUN does not intercept those exceptions incorrectly.
Why is an app still querying external DNS after FakeDNS is enabled?
Check the browser’s “Secure DNS” or the app’s built-in encrypted DNS settings, and review the IPv6 query path. For troubleshooting, temporarily switch to system DNS and test again. Intercepting port 53 does not prove that encrypted DNS is going through FakeDNS.
Another common mistake is to run ping against a virtual IP and judge node quality by packet loss. The address represents a mapping, not a real server, and ICMP may be handled differently from TCP or UDP. Test the target app’s actual connection and record DNS lookup time, connection time, and download throughput separately.
Enable or Roll Back: Compare the Same Requests
Whether to use FakeDNS depends on whether it completes your current interception path—not on how many options you enable. First record the client version, current node, TUN status, DNS handler, and address pool. Then use the steps below to run a repeatable comparison.
- Establish a baseline: Disable FakeDNS. Keep the same node and network, then test one proxied destination, one direct destination, and one LAN service. Record which succeed and which fail.
- Enable only the mapping path: Confirm that DNS assignment and inbound recovery are both enabled. Don’t switch nodes or rewrite the entire routing setup at the same time.
- Start fresh connections: Quit and reopen the test app. Clear the system DNS cache if needed to avoid mixing old real addresses with new virtual ones.
- Check three things: Does the lookup return an address from the pool? Does the connection recover the original domain? Does the final outbound match your routing expectations? If IPv6 is enabled, check AAAA lookups and IPv6 connections separately.
- Test rollback: Disable FakeDNS, restore the previous DNS settings, and restart affected apps. If problems remain after rollback, check TUN routes, the system proxy, or node connectivity instead of attributing everything to DNS.