FakeDNS Explained: How It Works with TUN and When to Use It

How FakeDNS Works: Preserving Domains with Temporary IPs

FakeDNS returns a locally mapped address, not the website server’s real IP. A regular DNS query resolves a domain to its real IP; FakeDNS instead assigns an address from a predefined pool and records the domain-to-address mapping. The app connects to that address as usual. Once the proxy intercepts the connection, it uses the mapping to recover the domain and pass it to routing and outbound handling.

A common IPv4 address pool example for Xray is 198.18.0.0/15, ranging from 198.18.0.0 to 198.19.255.255. This is a reserved range used for benchmarking—not public server addresses or typical private LAN addresses. Seeing an app receive an address from this range is expected when FakeDNS is configured correctly.

The key to this setup is that an address can be mapped back to its domain. If an app bypasses the proxy when connecting to a fake IP, or the core handling the connection lacks the mapping, the fake IP cannot be used to reach the site. Adding an address pool to DNS without configuring connection interception and domain restoration will usually turn accessible sites into connection timeouts.

FakeDNS and TUN: Intercepting Traffic Isn’t the Same as Intercepting DNS

TUN sends network packets to the proxy for processing; FakeDNS keeps domain information available for recovery along the way. They’re often used together, but they do different things. Even with TUN enabled, an app’s connections may be intercepted while its DNS queries still go to a router, corporate DNS server, or the browser’s own encrypted DNS service. In that case, the app gets a real IP and no FakeDNS mapping is created.

Domain restoration and traffic sniffing are also different. Information such as the HTTP Host header or the server name in TLS can help identify some connections, but not every connection exposes a readable domain. FakeDNS restores domains using the mapping from an earlier DNS query, so it doesn’t have to rely entirely on application-layer content. But if an app connects directly to an IP without using that DNS entry point, FakeDNS can’t recover the original domain out of thin air.

Xray Configuration: Check the Address Pool and Inbound Restoration Separately

Xray FakeDNS requires an address-pool configuration that works with the DNS setup actually in use. The top-level snippet below is for illustration, not a complete, ready-to-run client configuration. It shows only an IPv4 fake-IP pool and server selection for built-in DNS. A complete setup also needs inbounds, routing, and outbounds—and app queries must actually reach this DNS module.

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

poolSize specifies the mapping pool capacity; it isn’t a DNS listening port or a network speed setting. The example value 65535 doesn’t mean a site can handle 65,535 concurrent connections. FakeDNS alone also can’t handle every real DNS lookup. Direct connections that need real IPs, proxy server domains, and special internal domains all need a defined path for real resolution, so they don’t receive fake IPs that can’t be used during connection setup.

For Xray inbounds that support this mechanism, fakedns in sniffing.destOverride looks up the mapping and restores the target. Don’t paste these fields directly into another core’s configuration, and don’t change an inbound that doesn’t receive TUN traffic. If the client generates its configuration automatically, edits to a temporary file may be overwritten on the next launch. Use the client’s supported configuration options instead.

When to Use FakeDNS: Domain-Based Routing with Exceptions for Local DNS

FakeDNS is most useful when traffic is transparently intercepted but outbounds need to be selected by domain. For example, some apps don’t use the system HTTP proxy. With TUN enabled, the proxy may see only the connection’s target IP; FakeDNS preserves the mapping so routing can use the domain again. It improves domain identification—it doesn’t improve subscription node quality or automatically convert VMess to VLESS.

Don’t route every LAN printer, corporate service, or app that relies on local discovery through FakeDNS. Multicast discovery and regular unicast DNS are separate mechanisms. Preserve the existing resolution paths for these services first, then expand interception gradually. If internal domains are sent to a public DNS resolver, they may remain inaccessible even with FakeDNS disabled.

Verify and Troubleshoot: Check DNS, Then the Target and Outbound

Don’t verify FakeDNS only by checking whether a webpage loads. The page might work through an existing connection, cached data, or the browser’s own DNS service—none of which proves the new setup is working. Change one setting at a time and record DNS results, connection targets, and outbound tags before and after. The steps below don’t depend on a specific client version or assume that one menu name applies to every release.

1. Confirm which core is running. Check the selected core or runtime logs in v2rayN, and note the client and core versions. If the configuration reports an “unknown field,” check which core supports that field instead of repeatedly switching subscription nodes.
2. Check the DNS entry point. Regular DNS typically uses UDP or TCP port 53, but a built-in DNS module doesn’t necessarily listen on that port on your system. Check the client’s DNS interception settings and the system DNS address. Don’t assume 127.0.0.1:53 is available.
3. Clear old caches. Close the app under test and clear the system cache, then relaunch it. Browsers may also have their own DNS cache and secure DNS settings, so check those separately.
4. Verify the address and restoration. The query result should match the configured address pool, and the connection logs should show the restored domain or a corresponding processing record. Seeing 198.18.x.x alone doesn’t prove the outbound connection succeeded.
5. Check real DNS resolution and routing. Confirm that direct-connection targets and proxy server domains resolve to real addresses, then check which outbound the domain rule selects. Once troubleshooting is complete, restore the usual log level to avoid retaining large amounts of connection data.

On Windows, use the following commands to clear the system DNS cache and view the DNS servers configured for each network interface. Run the second command in PowerShell. These commands help identify the DNS entry point; they don’t change client rules or clear every app’s internal cache.

ipconfig /flushdns

Get-DnsClientServerAddress -AddressFamily IPv4

If a test tool returns a real IP, first check which DNS server it queried before concluding that FakeDNS failed. If it returns a fake IP but the connection times out, check whether address-pool traffic reaches the correct inbound and whether the mapping is still valid. After restarting the core, an app may still use an old fake IP that the new core can’t map. Restarting the app and clearing its cache is more targeted than repeatedly switching nodes.

• AAAA records appear, but IPv4 mapping works: Check IPv6 interception and DNS policy. An IPv4 success alone doesn’t prove that all connections are routed through the proxy.
• Problems on a corporate network: Check whether any network equipment already uses 198.18.0.0/15 to avoid conflicting with existing routes.
• Suspected DNS leak: Check traditional DNS, encrypted DNS, and IPv6 paths separately. A fake IP alone doesn’t prove that no queries are leaving your network.

FAQ: Toggles, Latency, and Recovery After Disabling FakeDNS

Check the full connection path to diagnose the issue: which address the app received, which inbound intercepted the connection, whether the domain could be restored, and which outbound the rule selected. For more on routing and proxy modes, see the complete guide. If you’re setting up a client for the first time, follow the setup guide to establish a working baseline before adding FakeDNS.