FakeDNS Explained: Fake IP Mapping, Use Cases, and When to Enable It in v2rayN

How FakeDNS works: preserve the domain, then choose the route

Fake IP mapping: Standard DNS typically returns a reachable IP address for a domain. FakeDNS instead assigns an address from a designated pool and records the domain-to-fake-IP mapping locally. This address is not the website’s public endpoint; it acts as an index that lets the connection handler identify the domain later. The app connects as usual, and the proxy processing chain uses the mapping to recover the original domain.

End-to-end flow: A fake address is useful only when the DNS request and subsequent connection pass through compatible processing paths. If DNS returns a fake IP but TUN does not intercept that address pool, the app may send the connection over the regular network and eventually time out. Conversely, if an app gets a real IP through its own encrypted DNS, FakeDNS will not have a mapping for that lookup.

Resolving at the exit: Recovering the domain does not mean the entire connection can avoid real DNS. Whether and where the domain is resolved depends on the outbound type, domain handling policy, and server behavior. Direct connections generally still need a reachable IP; proxy outbounds that can pass through domains may leave resolution to the remote end. FakeDNS helps with local domain recognition and routing—it does not replace internet-wide name resolution.

Address pools and ports: A fake IP does not mean DNS is broken

Recognizing the range: Common Xray FakeDNS configurations use the 198.18.0.0/15 address pool, a range reserved for network benchmarking rather than ordinary public websites. These are address and protocol facts, not speed-test results or settings every environment should copy.

Address range: 198.18.0.0/15 spans 198.18.0.0 through 198.19.255.255. The block's total address count does not mean the kernel will store the same number of mappings; actual capacity also depends on pool settings and implementation limits. If an enterprise lab network already uses this range, resolve any routing conflicts first. “Reserved” does not mean “unused on this machine.”

• Expected: A domain lookup returns an address from the pool, the app connects successfully, and connection logs associate the domain with the expected outbound.
• Problem: A lookup returns an address from the pool, but the connection bypasses interception or logs show only the fake IP followed by repeated timeouts.
• Scope check: Listening for or forwarding UDP 53 alone does not cover every query. Traditional DNS may also use TCP, and apps may use encrypted DNS.

When to enable FakeDNS in v2rayN: Distinguish system proxy from TUN first

System proxy: Apps that follow the system proxy settings typically send the destination domain to a local HTTP or SOCKS proxy, though whether the app resolves it locally depends on the app and protocol. If logs already show the domain and routing works as intended, FakeDNS is usually unnecessary. It is not a prerequisite for connecting to VMess or VLESS nodes, and it cannot fix an expired subscription or incorrect TLS settings.

Kernel boundaries: v2rayN is a desktop client, and the core selected for a node may not be the component handling TUN traffic. A node connecting through Xray does not mean you can paste Xray's FakeDNS fields into every TUN configuration. Check the active configuration and startup logs first to identify which component handles DNS, TUN, and routing, then use settings supported by that core.

Android boundaries: v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. Their interface options, configuration generation, and supported fields cannot be inferred from desktop screenshots. Even when option names look similar, check the DNS and traffic interception settings available in the installed version. When moving between platforms, carry over the routing goals—not unverified low-level configuration.

Configuration sequence: You need the address pool, DNS response, and domain recovery

Minimal example: This shows only the top-level Xray fakedns address pool setting to explain the fields; it is not a complete, runnable configuration. The 65535 value for poolSize is the mapping capacity chosen for this example. It is not the size of the address block or a recommendation for every machine. v2rayN may regenerate its files on restart, so check how custom configuration is applied and saved before editing.

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ]
}

1. Record a baseline: Save your current DNS, routing, and TUN settings. Choose a frequently used website and a local network service to compare before and after.
2. Check the DNS entry point: Verify that system and app queries enter the intended processing chain. Defining an address pool in the configuration alone does not make every system query use FakeDNS.
3. Enable FakeDNS responses: In a supported Xray configuration, the relevant DNS queries must also use the built-in fakedns service. Set query rules to match your direct-connection and proxy requirements.
4. Verify domain recovery: With an Xray inbound, check enabled and destOverride in the sniffing settings. The fakedns entry restores the domain from its mapping. Other interception components need their own equivalent mechanism.
5. Test each case: Check regular browsing, local network access, and the target app. Confirm the recovered domain and outbound route before expanding use to everyday traffic.

IPv6 considerations: An IPv4-only pool does not mean IPv6 is handled the same way. An app may query AAAA records first and then connect over IPv6; if that path lacks a matching route and DNS policy, behavior may differ between apps. Test A and AAAA queries and their connection paths separately rather than treating one successful IPv4 test as proof that everything works.

Use cases and compatibility trade-offs: Prioritize domain rules; handle real-IP requirements separately

Routing benefits: TUN typically receives the destination IP, and an IP alone is rarely enough to reliably identify a website's purpose. One domain can map to multiple addresses, and one address can host multiple domains. By retaining the name from the DNS lookup, FakeDNS gives domain rules a better basis for matching. Coverage is still limited to DNS queries that actually pass through the relevant path; it cannot recover domains for every connection.

Compatibility: Some apps check whether a resolved address belongs to an expected range, or pass DNS results to another process or device. A fake address usually has no useful meaning outside the environment that maintains its mapping. Do not share FakeDNS responses with devices that lack compatible interception, or save returned addresses as real server IPs in persistent settings.

Troubleshooting and rollback: Check queries, mappings, and connections in order

Start troubleshooting: If an app stops working while websites still load after enabling FakeDNS, save local logs from the time of the failure and check whether the app uses its own DNS, a fixed IP, or a different network path. Avoid changing the node, routing rules, and DNS all at once; otherwise, even a fix will be hard to trace.

1. No fake address returned: Confirm the test domain matches a FakeDNS query rule. A real address may be expected because of an exclusion policy, or it may come from the app's own DNS or an old cache.
2. Fake address returned, but connection times out: Check that TUN is running, the address pool route uses the right interface, and there are no conflicts with other virtual adapters or enterprise routes.
3. Logs show only the fake address: Check domain recovery for the relevant inbound. Also rule out a lost mapping after restart while the app still has an old DNS result cached.
4. Domain is correct, but traffic uses the wrong outbound: Check rule order and whether process, port, or IP rules match first. At this point, the issue is not just DNS.
5. Browser and app behave differently: Check encrypted DNS, app proxy settings, and caches separately. One successful browser test does not speak for other processes.

Windows cache: Before returning to real DNS, restore the DNS response and interception settings, then clear the system cache and restart the affected app. The command below clears only the Windows DNS client cache; it does not clear a browser's built-in cache or change the node. Long-running apps may keep their own connection pools, so fully quit and reopen them.

ipconfig /flushdns

Verify rollback: Confirm new queries no longer return the old fake address, local network services are reachable, and the system proxy or TUN is in its intended state. If an app still tries to connect to an old fake IP after interception is disabled, clear the app's cache rather than adding the address to a direct-connection rule. Direct routing cannot turn a fake index into a real server.

FAQ: What FakeDNS, sniffing, and privacy can—and cannot—do

Bottom line: If domain-based routing already works through the system proxy, FakeDNS does not need to be a routine toggle. Under TUN, enable it only when domain information is genuinely missing and you can control both DNS and the connection path. Validate the result by checking domain recovery, route matches, and app compatibility.