V2Ray FakeDNS Explained: Virtual IPs, Traffic Sniffing, and Use Cases

How FakeDNS works: preserving domain names with virtual IPs

Standard DNS resolves a domain to a real, reachable IP address. FakeDNS instead assigns a virtual IP to selected A or AAAA queries and stores the domain-to-address mapping locally. The application treats the result like a normal DNS response and connects to that address. The proxy core intercepts the connection, looks up the mapping to recover the original domain, then passes it to routing and outbound handling.

“Recovery” here means looking up a local mapping—not sending a PTR reverse lookup to a public DNS server. For example, an app queries example.com and gets an address from the pool. When the core sees the app connect to that address, it uses the same mapping table to recover example.com. The specific address depends on runtime state, so don’t hard-code a virtual IP in a rule.

A virtual IP is only a marker in the local interception path, not the website server’s real address. It cannot be used directly from another device or sent through a standard gateway to the public internet expecting a response. Even when routing selects a direct outbound, the domain must first be recovered so the appropriate DNS and connection handling can resolve the real destination.

Address pool and ports: know which of the three numbers is which

198.18.0.0/15 covers 198.18.0.0 through 198.19.255.255. It is reserved for benchmark testing, not ordinary private networks. It can serve as a virtual address pool because it is not intended for normal public destinations. However, enterprise networks, labs, and other tunnels may use it, so check for routing conflicts before enabling it.

poolSize sets the mapping pool capacity; it is not a DNS cache duration or a concurrent-connection limit. The 4096 value here is only an example, not a recommended setting for every device. If the pool runs short or an entry is evicted while an app still holds the old address, domain recovery may fail. Don’t just clear the browser cache—consider the lifetimes of the core’s mappings and the system DNS cache too.

• Address pool: Defines which destination addresses are treated as virtual targets. It must not overlap with addresses already in use.
• Mapping capacity: Sets how many mapping entries can be retained. Diagnose behavior in practice; don’t judge performance by the number alone.
• DNS entry point: Standard DNS commonly uses UDP/TCP port 53, but a core’s built-in DNS module does not necessarily listen on port 53 locally.

FakeDNS, sniffing, and TUN: three different jobs

TUN receives IP traffic routed through a virtual network interface; it does not ensure that every connection includes a domain name. Standard sniffing tries to identify domains from supported protocol data, such as HTTP Host headers and TLS handshakes. FakeDNS recovers domains using mappings created earlier. Both can provide domain information, but they get it from different sources and are not interchangeable.

If an app connects directly to an IP, uses encrypted DNS that bypasses interception, or reuses a real address cached before FakeDNS was enabled, FakeDNS has no chance to create a mapping. Seeing the connection handled by IP rules does not, by itself, mean FakeDNS is broken. Conversely, if the DNS query reaches FakeDNS but the target connection bypasses TUN or the transparent inbound, the app may fail when it tries to connect to the virtual IP.

Xray config example: address assignment and inbound recovery go together

These snippets show how Xray-style fields relate; they are not complete, runnable configs. V2Ray is a commonly used umbrella term, but exact fields and behavior depend on the core actually in use. v2rayN is a client; v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. Don’t copy the same JSON across cores just because the client names look similar.

The first snippet is a top-level config fragment: it declares an IPv4 pool and tells the built-in DNS to use FakeDNS. It shows only the basic relationship. It omits node-server domain resolution, LAN domain exceptions, IPv6, and the DNS traffic entry point, so don’t use it to replace a complete config generated by your client.

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

The second snippet belongs in the inbound that receives connections to virtual targets; it enables mapping lookups to recover domains. Only fakedns is included here to make the essential relationship clear. Before adding sniffing types such as HTTP or TLS, check support in your core. Don’t use this object as a standalone top-level config or attach it to an inbound that cannot receive the target connections.

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

• If a node server is specified by domain, it needs a resolution path that returns its real address. A virtual IP cannot be used as the final address for connecting to the node.
• Once routing has recovered the domain, geosite: rules have a domain to match. geoip: rules match IPs; a virtual IP does not identify the target website’s geographic location.
• An IPv4 pool alone does not cover AAAA queries or IPv6 connections. Test dual-stack networks separately.

When to use FakeDNS: useful for transparent interception; keep standard system proxy setups simple

HTTP proxies and SOCKS requests that support remote DNS resolution can pass the domain straight to the proxy, so adding FakeDNS may not solve any additional problem. FakeDNS is most often useful with transparent interception, where only IP packets arrive and the domain context is more likely to be lost. Before enabling it, work out what the traffic is actually missing: domain information, node connectivity, outbound DNS resolution, or the correct routing order.

FakeDNS is not DNS encryption, and it does not guarantee that all DNS traffic goes through the proxy. It changes only the DNS response seen by the app; where the real resolution happens and which transport it uses still depend on outbound and DNS policies. Node protocols such as VMess and VLESS do not, by themselves, determine whether FakeDNS works, and there’s no need to re-import a subscription for this.

How to verify the full path, from DNS response to outbound connection

1. Keep a baseline. First confirm that the same node can reach the target in standard proxy mode, and back up the current config. Don’t change your subscription, routing rules, and DNS settings all at once.
2. Check the interception path. Enable your chosen TUN or transparent interception setup, then confirm that both the app’s DNS queries and its subsequent connections follow the expected path. In Windows, check the active network interface under Settings → Network & internet, but don’t treat the DNS value shown for the physical adapter as proof that interception is working.
3. Clear stale cache entries. Close the test app. In Windows, run ipconfig /flushdns at a command prompt to clear the system cache, then reopen the app. Check the browser’s own cache and encrypted DNS settings separately.
4. Check actual DNS queries. Trigger a lookup from the app and use DNS logs to confirm whether the response came from the configured pool. nslookup example.com can help, but it may use a different query path than the browser. One result cannot tell you how every app behaves.
5. Check domain recovery and routing. In available logs, look for the original virtual target, the recovered domain, the matching rule, and the outbound tag. Log detail varies by core and client; raise the log level temporarily if needed, then restore it after testing.
6. Test exceptions. Check internal sites, IPv6 destinations, and direct-routing rules separately. Opening one proxied website is not enough to confirm that the entire DNS policy is correct.

A useful test should answer a specific question: what did DNS return, where did the connection go, and which rule matched? Running ping alone is not a reliable way to test web proxy access: a virtual IP does not have to respond to ICMP, and websites use a different connection path. Also, don’t treat the time it takes to get a virtual IP as website latency; they measure different things.

Common issues: stale virtual IPs, broken intranet access, and routing misses

If the problem appears only after the core restarts, the mapping state may be out of sync with the app’s cache: the app retained an old virtual IP, but the new process has no matching entry. In that case, restart the app and resolve the domain again rather than repeatedly switching nodes. If it keeps happening after increasing pool capacity, check whether multiple DNS components are handling requests; capacity is not a substitute for troubleshooting.

Rollback steps: restore DNS, clear caches, then test the standard proxy

If FakeDNS isn’t a good fit for your current network, restore the original config. The important part is to disable both virtual IP assignment and any interception that depends on it, rather than leaving half the chain in place. Client updates may change how configs are generated, so use the saved config as your reference instead of guessing which switches were enabled.

• Restore the original DNS servers, domain exceptions, and client interception settings.
• Check that no virtual-pool interception rules remain on the physical network interface or in system routes.
• Quit the app, clear the DNS cache, then test the same target with the standard system proxy.
• Note whether the failure occurred during the DNS query, mapping recovery, or outbound connection. Change only that part next time.

The key takeaway: FakeDNS adds domain information to routing paths that need it. If a setup already passes domains reliably, there’s no need to add complexity just for another toggle. When transparent interception really does lose domain information, complete the chain by checking the address pool, DNS entry point, inbound recovery, and outbound resolution. For more field details, see DNS settings in the configuration reference. For basic connection issues, see the connection troubleshooting guide.