V2Ray FakeDNS Explained: Virtual IP Mapping and Use Cases

FakeDNS vs. regular DNS

Regular DNS uses A and AAAA queries to look up IPv4 and IPv6 addresses. After receiving an answer, an application typically connects directly to that address. At a transparent proxy entry point, the original connection may contain only the destination IP and port, while domain-based rules need the name the application originally queried. FakeDNS changes the first step: instead of immediately returning the real server address, it assigns a virtual IP that is meaningful only within the controlled connection path.

For example, an application queries www.example.com. FakeDNS assigns 198.18.0.2 and stores the mapping between the two. The application then connects to 198.18.0.2:443. The core intercepts the connection, looks up the mapping, and can restore the destination as www.example.com:443. This address is an example of how the mechanism works—not a reachable test endpoint or a fixed first address assigned by any particular client.

How virtual IP mapping works end to end

The key isn’t simply what DNS returns; it’s whether the response and the subsequent connection can be brought back together. The mapping table used to answer DNS queries and the core handling the destination connection must share state, or be connected through an integration that supports this mechanism. If one instance assigns the virtual address but another instance without the mapping handles the connection, all it sees is a special-purpose address it can’t access directly.

1. Send queries through controlled DNS: The application’s A or AAAA queries must use the configured DNS path. Intercepting traditional DNS on UDP port 53 alone does not cover encrypted DNS built into an application.
2. Store the mapping: FakeDNS assigns a virtual address to the domain. The address pool has limited capacity, and an implementation may reclaim old mappings under pressure. The order in which addresses are assigned should not be treated as a stable interface.
3. Intercept connections to virtual addresses: TUN or transparent proxy rules must send connections to an entry point that supports restoration. FakeDNS itself does not create a TUN interface or automatically install complete system routes.
4. Look up and restore the destination: The core uses the virtual IP to recover the domain for domain-based rules and subsequent outbound handling. Whether it also rewrites the connection destination depends on settings such as inbound sniffing.
5. Complete the connection: With a proxy outbound, protocols that support domain destinations can pass the domain to the remote end for resolution. With a direct outbound, a real DNS lookup is usually still needed to obtain a reachable address.

FakeDNS doesn’t eliminate DNS; it defers real resolution while preserving the domain mapping. It also doesn’t replace proxy protocols such as VMess or VLESS, change node credentials, or fix an unreachable server, an incorrect transport path, or mismatched TLS settings.

Configuration fields: address pool, DNS, and inbound restoration

“V2Ray FakeDNS” is often used as a catch-all term for this type of mechanism, but V2Ray and Xray differ in their configuration options, fields, and client integration. The example below uses explicitly specified values in an Xray-core JSON configuration that supports these fields; it does not claim they are defaults across all versions. v2rayN, v2rayNG, and v2flyNG have different interfaces and configuration-generation methods, so don’t copy settings between cores without checking compatibility.

The following DNS and address-pool excerpt belongs inside the root object; it is not a complete, runnable configuration. It doesn’t define an inbound listener, outbounds, or system routes, and it shows an IPv4 pool only. This does not mean AAAA queries will be handled the same way. For a real deployment, consult the documentation for your current core and configure IPv6 behavior and the real-DNS fallback path as needed.

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

The inbound that receives connections to virtual addresses also needs a restoration mechanism. Below is only the sniffing field inside that inbound; it doesn’t fill in the other inbound parameters. routeOnly generally means using sniffed results for routing without rewriting the destination. This example explicitly sets it to false so an unrestored virtual destination isn’t passed on to the outbound.

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

When to use FakeDNS—and when not to

FakeDNS is most useful in environments that already use TUN or a transparent proxy and need domain-based routing. A transparent entry point receives connections at the network layer, so the domain may not be available from the connection itself. The mapping table lets domain rules work without relying entirely on HTTP Host headers or TLS handshake information. FakeDNS can also help defer real resolution until traffic reaches the proxy’s outbound, but whether that works depends on the combination of outbound, routing, and real-DNS settings.

Evaluate explicit and transparent proxies separately. SOCKS requests and HTTP CONNECT requests that support domain destinations can carry the domain directly, so they may not need FakeDNS. But if an application resolves the name locally and submits an IP to the proxy, the domain may still be lost. Base the decision on the actual request format, not merely on the presence of a “system proxy” setting.

Common side effects: caching, internal networks, and DNS bypass

FakeDNS adds a local mapping table with its own lifecycle, while applications and the operating system may keep caching old DNS answers. If the core restarts and a mapping disappears, an application may still try to connect using the old virtual IP. This can look like “it worked at first, then stopped after switching modes.” Switching nodes repeatedly usually won’t help because the failure occurs before outbound selection.

• Connections fail after switching modes: Even after FakeDNS is disabled or TUN is turned off, an application may still use a cached virtual address. Restore a consistent interception mode first, then clear the cache and restart the affected applications.
• Local network services stop working: Internal domains may need the office DNS server to return internal addresses. Route those domains through explicit real DNS and direct connections instead of sending every query to the virtual pool.
• The application resolves names itself: If an application has built-in DoH, DoT, or its own resolution results, traditional DNS interception may never see the query. In that case, no virtual mapping is expected; it doesn’t mean the address pool has failed.
• IPv4 and IPv6 behave differently: If A queries use the virtual pool while AAAA queries take another path, the same application may behave inconsistently. Check both record types, IPv6 routing, and the corresponding pool settings.
• Diagnostic tools show different results: A result in the 198.18 range doesn’t mean the domain really points there. Testing connectivity to a virtual IP also doesn’t directly tell you whether the remote website is online.

FakeDNS doesn’t automatically mean “no DNS leaks.” A direct outbound may still trigger real DNS resolution, and applications may bypass controlled DNS. To verify the resolution path, check where queries go and which outbound handles the connection separately. Don’t draw conclusions just because one lookup returned a virtual address.

Troubleshoot virtual IP connection failures step by step

Start with one domain, one application, and one node, and record what changes when you switch modes. The example below uses www.example.com. The commands show the current resolution path on your device, but they don’t guarantee that the query goes through FakeDNS. Windows, macOS, and Linux DNS tools may also use a different resolution path from your browser.

nslookup -type=A www.example.com
nslookup -type=AAAA www.example.com

1. First, check whether the lookup uses the virtual pool: If the A record returns an address from the configured pool, that query received a virtual answer. If it still returns a real IP, check whether the query bypassed controlled DNS or the domain matched a real-DNS exception.
2. Next, check whether the connection reaches the core: Look at the access logs when the application connects. If DNS returned a virtual address but the core has no corresponding connection entry, check TUN routing and inbound interception first. Don’t start by changing the node’s VMess or VLESS settings.
3. Check whether the mapping restores the domain: If the logs show only the virtual IP, check whether the inbound handling the connection has the matching restoration settings enabled. Also check for a core restart, an address-pool change, or a switch between instances. Log formats vary by version, so a single line isn’t enough to prove a failure.
4. Finally, check routing and the outbound: If the domain is restored but the connection still fails, check which outbound the domain rule selects. Direct connections need a working real-DNS path. For proxy outbounds, check node connectivity, server-side resolution, and transport settings.

On Windows, you can use the command below to clear the system DNS cache, but it won’t clear every application’s cache. Before clearing it, make sure interception is configured correctly; otherwise, applications will simply receive another unusable result. If a browser or background process still has issues, close the relevant process and try again.

ipconfig /flushdns