FakeDNS Explained: How It Works, When to Use It, and What to Check

How FakeDNS Works: Preserving Domains with Virtual IPs

FakeDNS is neither a proxy protocol nor encrypted DNS. Regular DNS returns the real address for a domain; FakeDNS assigns a virtual IP from a dedicated pool and records the domain-to-IP mapping. When an app connects to that address, the traffic-intercepting core uses the mapping to recover the original domain before routing the connection and selecting an outbound.

Xray must handle both the DNS request and the subsequent connection. For example, an app looks up example.com and gets 198.18.0.1 from the pool. The connection to that address must then pass back through the core that holds the mapping. This IP is an illustrative assignment, not the domain’s real address or a server address to enter in a node configuration.

TUN and Domain-Based Routing: What FakeDNS Solves

With v2rayN’s system proxy, apps typically use an HTTP or SOCKS proxy directly and can pass the domain to the proxy. TUN captures traffic at the network layer, where the core may see only the resolved IP. FakeDNS helps preserve the domain information needed to match domain-based routing rules in this situation.

v2rayNG receives device traffic through Android’s VPN interface, but VPN capture does not automatically enable FakeDNS. Whether DNS reaches the core, whether the core assigns a virtual IP, and whether the connection’s domain is recovered are three separate conditions. TLS or HTTP sniffing can also reveal some domain information, but its effectiveness depends on the protocol and app behavior; it isn’t a reliable replacement for every connection.

VLESS and VMess handle proxy connections; FakeDNS handles local DNS and destination information. Switching proxy protocols won’t fix a broken mapping path. v2flyNG uses the V2Fly core, so check configuration options and field support against the actual core. Don’t assume an Xray example works unchanged across all three clients.

Address Pools and Config Fields: Three Numbers to Know

Xray’s FakeDNS configuration can use 198.18.0.0/15 as an IPv4 address pool. This subnet is reserved for benchmarking and isn’t a regular address range for reaching public services. The total number of addresses in the subnet and poolSize are different things: the prefix length determines the former, while the latter sets the mapping pool’s capacity in the implementation.

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

This Xray snippet shows only the top-level address pool definition; it is not a complete, runnable configuration. Integration also requires a fakedns server entry in the built-in DNS settings and support for restoring domains on the inbound that receives connections, such as sniffing.destOverride support for fakedns. Adding the address pool alone won’t redirect system DNS automatically.

• Check the generated config first: v2rayN’s TUN implementation may use a different processing path from a regular proxy inbound. Check the configuration accepted by the component currently running instead of pasting Xray fields into every config file.
• Check for address conflicts: If a corporate VPN, test network, or static route already uses 198.18.0.0/15, plan a different address pool and routing setup to avoid overlap.
• Check IPv6 separately: An IPv4-only address pool doesn’t mean AAAA queries are handled correctly. Check the current implementation’s IPv6 behavior to avoid sending dual-stack apps down an untested path.

When to Use FakeDNS

FakeDNS is most useful for transparent traffic interception when routing depends on domains that aren’t available directly from the app. It can reduce the impact of prior real DNS resolution on domain detection, but it doesn’t guarantee faster page loads. The selected outbound, server reachability, and resolution of the real destination can all affect the connection.

Use extra caution with FakeDNS for intranet domains. Corporate services may require a designated DNS server to return private IPs. Using regular DNS for these queries and setting the relevant connections to go direct often preserves existing access behavior more reliably. Configure exceptions in the DNS and routing implementation you actually use; adding a direct-route rule alone won’t change how DNS queries are resolved.

Before Enabling FakeDNS: Check DNS, Outbounds, and Caches

1. Record a baseline. Note the client version, core version, DNS settings, and TUN or VPN status. Visit a domain and save the logs so you can compare results later.
2. Check the DNS entry point. Confirm whether system DNS is intercepted. Secure DNS in browsers and app-level DoH may bypass it. For testing, you can temporarily set the test app to use system DNS, then restore its original setting afterward.
3. Confirm that connections return to the core. Check whether the active TUN or VPN routes the virtual IP pool. With per-app proxy settings on Android, an excluded app might receive a virtual IP but be unable to send its connection back through the core.
4. Check how real destinations are resolved. If the proxy server address is a domain, it needs a working bootstrap DNS path; it can’t rely on the proxy to resolve its own address before the connection is established. Direct connections may also need a real IP address.
5. Change one variable at a time. Keep the node and routing preset unchanged, and adjust only the FakeDNS settings first. Don’t switch the core, protocol, DNS, and routing rules at the same time, or it will be hard to pinpoint the failure.

The settings screens in v2rayN and v2rayNG can change between versions. Rely on the active configuration and logs, not the location of a toggle in an old screenshot. If the current version doesn’t expose the required settings, stick with a verified mode. Custom configurations require understanding DNS, inbounds, and routing—not just adding a field.

Testing and Rollback: Check Resolution and Connections Separately

Test FakeDNS in two steps: first inspect the system’s DNS response, then check the actual connection to the same domain. On Windows, run the command below in Command Prompt. nslookup tests the DNS path it currently uses; it doesn’t show whether the browser’s own DNS uses that same path.

ipconfig /flushdns
nslookup example.com

• Resolution: If the query should be handled by FakeDNS, check whether the returned address falls within the configured virtual IP pool. If it returns a real address, first check whether a regular-resolution exception applied before treating it as a failure.
• Connection: Visit the same domain in the test app and check the destination domain, routing rule, and outbound tag in the logs. The virtual IP should not be sent directly over a regular network as the final address of a public service.
• Compare: Also test an intranet domain and a connection made directly to an IP to confirm that exceptions still work. Keep test conditions the same so changes in node performance aren’t mistaken for a FakeDNS failure.
• Roll back: Restore the original DNS and interception settings first, then reconnect the client, flush the system cache, and fully quit and reopen the test app. If an Android app still holds an old result, force-stop it before launching it again.

FakeDNS mappings are generally runtime state. After a core restart, mapping eviction, or configuration change, an app may still have an old virtual IP cached while the new core no longer knows which domain it belongs to. Switching nodes repeatedly usually won’t help; clear the cache and reconnect first. Windows’ ipconfig /flushdns clears only the system DNS cache, not every app’s own cache.

Common Questions: Virtual IPs, App Conflicts, and Battery Use

Enable FakeDNS only when you can verify domain recovery and correct routing. If v2rayN, v2rayNG, or v2flyNG is already working reliably, there’s no need to change it just to add a feature. Before putting FakeDNS into everyday use, make sure you understand the DNS entry point, virtual IP routing, regular-resolution exceptions, and cache recovery.