FakeDNS Explained: Virtual IPs, How It Works, and When to Use It

How FakeDNS Works: Virtual IPs as Mapping Keys

A standard DNS lookup resolves a domain to the real address of its destination. FakeDNS instead picks an address from a local pool, maps it to the domain, and returns the virtual address. For example, a query for the A record of example.org might return 198.18.0.1. This is only an example; the actual allocation order depends on the implementation and runtime state.

The application then connects to that virtual IP. A component intercepting the traffic reads the destination address, looks up the associated domain, and passes it to the routing and outbound logic. The key is not simply returning a “special IP”: the DNS query and the subsequent connection must pass through a processing chain that can access the same mapping.

198.18.0.0/15 is a reserved range for benchmarking, spanning 198.18.0.0 to 198.19.255.255. It is not a range of regular public service addresses. FakeDNS often uses it, though implementations may use different pools. If a virtual address bypasses interception and is sent directly to the physical network, it generally cannot reach the original website.

TUN and Domain-Based Routing: Interception, Recovery, and Matching

TUN receives IP packets at the network layer. When it first intercepts a connection, the available information is often limited to the destination IP, port, and transport protocol. If the application has already resolved the domain, the domain may no longer appear in the packet. FakeDNS stores the domain-to-address mapping in advance, giving domain rules a way to identify the destination.

1. Intercept DNS: The application's queries must enter the intended DNS processing chain. Traditional DNS commonly uses UDP port 53, but may also use TCP port 53. Handling only one does not mean all queries are intercepted.
2. Intercept connections: TCP or UDP traffic to the virtual address pool must enter the appropriate TUN, routing, and core processing chain. Exclusion rules must not bypass it.
3. Recover the domain: The component handling the connection must be able to access the mapping. In Xray, the relevant settings involve FakeDNS and inbound sniffing; adding a name to the DNS list alone is not enough to complete the flow.
4. Apply routing rules: Once the domain is recovered, domain rules, IP rules, and fallback rules determine the outbound route. Protocols such as VMess and VLESS handle proxy transport afterward; they do not create the mapping.

When a browser accesses an HTTPS site through the system HTTP proxy, its CONNECT request can include the target hostname. SOCKS5 can also use a domain-name address type. These routes may already pass the domain to the proxy, so FakeDNS may not be necessary. If an application resolves the domain locally and submits only an IP, check how the domain information can be recovered.

Configuration Check: The Address Pool and Recovery Path Must Work Together

v2rayN is a desktop client, v2rayNG uses the Xray core, and v2flyNG uses the V2Fly core. The client interface, selected core, and TUN integration component are separate layers. The client name alone does not tell you whether a configuration field is supported. The keys below illustrate how Xray settings relate to each other; they do not imply that all three clients have identically named options, and they are not a complete configuration to import.

This Xray-native JSON snippet shows only the link between the address pool and built-in DNS. It omits inbound, outbound, routing, and interception settings, so it cannot replace the complete file generated by your client. If another component handles TUN and DNS, follow that component's configuration structure instead of mixing fields.

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

• Back up your current settings first, then inspect the runtime configuration actually generated. Enabling TUN in the interface does not mean FakeDNS is enabled.
• Make sure the client starts without unknown fields, configuration parse errors, or address-pool conflicts. Revert any configuration that fails validation, and don't change node protocol settings at the same time.
• Check how A and AAAA queries are handled separately. The IPv4 address-pool example above does not mean IPv6 queries receive a corresponding virtual mapping.
• Check how direct and proxy outbounds handle the recovered domain. If the final connection needs a real address, a working resolution path is still required; don't let queries loop back to the virtual IP allocator.

Use Cases and Side Effects: Virtual IPs Don't Suit Every Application

FakeDNS can reduce the need for some connections to obtain real addresses locally and help domain rules identify requests that have become IP connections. It does not automatically speed up remote resolution or fix unavailable nodes, incorrect TLS settings, or misordered routing rules. Judge whether it helps by domain recognition and application compatibility—not by whether DNS replies appear faster.

An app that connects directly to an IP literal never looked up a domain, so FakeDNS cannot supply one. Multicast name discovery on a LAN is also different from ordinary unicast DNS. Changing port 53 rules alone may not fix printer access, file sharing, or internal service discovery.

Testing: Check DNS, Mapping, and Outbound Routing Separately

Use the same test domain, keep the node and routing rules fixed, and change one setting at a time. Seeing a virtual IP only confirms that one query received a virtual response; a website loading does not prove every app used the same route. Check the DNS result, interception logs, and matched routing rule together.

1. Establish a baseline: Turn off FakeDNS and record whether the test domain is reachable, its current DNS result, and the outbound rule used. Keep a recoverable copy of your settings and don't change server addresses in your subscription.
2. Check the DNS response: Turn it on and query the same domain. Confirm that the A record falls within the configured virtual address pool. If you still get a real IP, check caches, app-specific DNS, and DNS routing before changing the pool.
3. Check domain recovery: Start a new connection and check whether the logs associate it with the original domain and expected outbound route. If you see only a direct connection to the virtual IP, check the recovery handler and subnet routing first.
4. Check compatibility: Test a website, an internal service, and a non-browser app separately. Test UDP apps independently too; a successful TCP connection in a browser does not verify UDP.

On Windows, first check the DNS result currently in use, then clear the system DNS cache after switching setups. The commands below query and clear the cache, respectively; they are not performance tests and don't guarantee a specific address.

nslookup example.org
ipconfig /flushdns

Clearing the system cache does not clear browser or app caches. After FakeDNS is disabled or the mapping component restarts, an app may still hold an old virtual IP. If its mapping has disappeared, connections using that address will fail. To roll back, stop the affected apps, clear the system cache, then reopen the apps and test again.

FAQ: Troubleshooting Problems After Enabling FakeDNS

The key test is whether you can explain the connection path, domain rules match as expected, and everyday apps work reliably. FakeDNS is just one way to coordinate DNS with traffic interception; subscription import, node selection, system proxy, and TUN settings still need to be checked separately.