What Is V2Ray FakeDNS? How It Works, How to Enable It, and When to Use It

FakeDNS explained: return a virtual IP, then recover the domain

A regular DNS query asks, “What real addresses belong to this domain?” FakeDNS instead answers, “Use this virtual IP to represent the domain you just queried.” For example, when an app queries example.com, FakeDNS assigns an address from its pool and stores the mapping. When the app connects to that address, the proxy entry point looks up the domain and applies the domain rules to choose a direct or proxied outbound route.

The key is not that the address is “virtual,” but that the whole chain works: the component handling the connection must be able to access the mapping created when answering the DNS query. If one process handles DNS while another handles the connection without sharing the mapping, the second process sees a destination that cannot be reached on the public internet. Even if both programs are proxies, do not assume they share mappings automatically.

Regular DNS vs. FakeDNS

Regular DNS can also work with domain-based routing. When an app uses an HTTP proxy or passes the domain to a SOCKS proxy, the proxy may already know the domain, so FakeDNS may not help. It is more useful when TUN or a transparent proxy intercepts a connection addressed to an IP, but routing rules still need the original domain.

FakeDNS is not encrypted DNS. DoH and DoT change how DNS queries are transported; FakeDNS changes how domain information is carried over to subsequent connections. After a query goes through FakeDNS, direct connections may still need real DNS resolution, and proxy server domains must also resolve normally. This does not mean that all DNS queries disappear or that all traffic goes through the proxy.

IP pool and ports: three numbers that are easy to mix up

198.18.0.0/15 covers 198.18.0.0 through 198.19.255.255, for a total of 131,072 addresses. That does not mean the mapping table stores that many entries at once. The example’s poolSize sets the mapping pool capacity; the address range, mapping capacity, and DNS cache lifetime are three different things.

Ports are easy to confuse, too. System DNS queries commonly go to UDP or TCP port 53; the proxy’s internal DNS listening port can be configured separately. Local HTTP and SOCKS listening ports are not DNS ports. Pointing system DNS at an HTTP proxy listener will not enable FakeDNS.

• Choose an address pool that does not overlap with subnets already used by your VPN, corporate network, or test network.
• If you change the address pool, check that your TUN routes or transparent forwarding rules cover the new range.
• A larger mapping pool will not make websites load faster. First make sure queries and connections can complete over the same chain.

Before enabling FakeDNS, check who handles DNS and who handles connections

v2rayN is the client interface; Xray is one possible proxy core it can run. The TUN feature in the interface may also be handled by a separate component, so using a VLESS or VMess node does not mean Xray necessarily handles TUN DNS. The protocol describes how the node connection works, not how DNS interception is set up on your device.

1. In v2rayN, check the settings for the active core under Settings → Parameter Settings, then check the startup logs to see which process actually launched. Menu names and groupings can change between versions, so rely on the current interface and logs.
2. If the interface has a Settings → DNS Settings page, first confirm which core it configures. A DNS option with the same name is not necessarily a global switch.
3. Note the current system proxy status, TUN status, and DNS settings before making changes. Change one thing at a time and keep a copy of the original config so you can roll back.
4. If you use v2rayNG or v2flyNG, check which core is actually running and whether it supports the config you need. Do not assume desktop client menu paths are the same on Android.

Xray config example: mapping and destination recovery are both required

The snippets below are for Xray cores that support these fields; they are not complete, standalone node configs. Check the documentation for your installed core version before using them. Files generated by the client may be overwritten when you save settings or switch nodes, so use the client’s supported custom config options instead of repeatedly editing temporary files.

Part 1: Define the address pool and select FakeDNS

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

The top-level fakedns object defines the mapping pool, while "fakedns" in dns.servers selects the built-in FakeDNS service. This minimal snippet shows only how the fields relate; it does not include real DNS resolution for node server domains, local network domains, or direct destinations. For a production config, choose regular resolvers for the appropriate use cases rather than sending every DNS request to the virtual IP pool.

Part 2: Recover the domain at the connection entry point

{
  "sniffing": {
    "enabled": true,
    "destOverride": [
      "fakedns"
    ]
  }
}

Merge the second snippet into the inbound object that actually receives destination connections; do not add it as a new top-level field. "fakedns" in destOverride recovers the destination domain from the FakeDNS mapping. Do not set it only on the entry point that receives DNS queries and leave out the one that receives web or app connections.

• Make sure the node server address can be resolved first, to avoid a circular dependency where connecting to the proxy requires DNS resolution through that same proxy.
• Do not match virtual-IP connections against domain rules while leaving the virtual destination in place for a direct connection. The destination must be correctly recovered before choosing an outbound route.
• If you have IPv6 queries, plan separately for AAAA records and IPv6 traffic. Configuring an IPv4 address pool alone does not show that IPv6 traffic is being intercepted.

How to verify FakeDNS is working—not just returning a virtual IP

A complete check needs to confirm the DNS response, connection interception, and final access result. Seeing 198.18.x.x only shows that one query returned a virtual IP; it does not prove that the browser connected successfully or that domain routing used the expected rule.

1. Clear old state. Close the test browser, apply the config, and restart the relevant core. On Windows, run the command below in a terminal to clear the system DNS cache. You may also need to clear the app’s own cache.
2. Query a test domain. Run nslookup example.com and note the returned address and the DNS server shown. If you use IPv4 FakeDNS, check whether the A record falls within the configured address pool.
3. Test the app’s path. Reopen the browser and visit the same domain. The browser’s Secure DNS feature may bypass the system query path, so temporarily disable it for comparison rather than assuming the command-line result applies to every app.
4. Check the routing result. Check the core’s access logs for the destination domain and outbound tag. Log formats vary by version; look for the expected recovered domain, not just a “connection successful” message.
5. Check direct and proxied routes. Test one destination covered by each existing rule and confirm that the recovered domain uses the expected outbound route. Do not use the virtual IP’s geolocation to decide whether a destination should be direct or proxied.

ipconfig /flushdns
nslookup example.com

If nslookup returns a real IP, the query may not have reached FakeDNS, or that domain may be configured to use a regular resolver. If it returns a virtual IP but the website will not load, first check the virtual subnet route and mapping recovery. Do not start by replacing your subscription or changing node settings in bulk.

Common issues: virtual IPs, browser bypasses, and lost connectivity after disabling

When to use FakeDNS and how to roll back

FakeDNS is a good fit when a transparent proxy needs reliable domain information, cooperating components handle both DNS and connections, and you are prepared to maintain exception rules. It is not an extra feature of a subscription node, nor does it require the server node to use a particular protocol. Most configuration happens on the device, where traffic is intercepted and routed.

• Good fit: TUN setups that need domain-based routing but cannot retain domain information through app proxy requests alone, or transparent proxy setups with a clearly defined DNS interception and destination recovery path.
• Stick with regular DNS: You only use the browser’s system proxy, rely on local network name discovery, need real-address diagnostics, or have DNS managed by corporate network policies.
• Test compatibility first: Games, real-time communications, virtual machines, and setups that combine multiple VPN layers. Check for virtual subnet conflicts, and make sure UDP and IPv6 follow the same interception policy.

To roll back, restore the original DNS settings and interception rules first, and confirm that new queries return normal results. Then exit the relevant TUN or transparent proxy chain and clear system and app caches. Finally, test both domain resolution and regular connectivity. Do not remove only the address pool while apps are still receiving stale virtual answers, or stop only the proxy process while leaving virtual subnet routes in place.