What Is FakeDNS? How V2Ray Virtual DNS Works and When to Use It

What Is FakeDNS? Linking Domains to Virtual IPs

A standard DNS lookup converts a domain name into a real, reachable IP address. FakeDNS instead assigns the application a virtual IP from a designated pool and records the domain-to-IP mapping. The application connects as usual, but the address does not belong to the actual web server, so the local proxy must intercept the connection and handle it.

For example, when an app looks up example.com, local FakeDNS might assign 198.18.0.1. When the app connects to port 443 at that address, the proxy looks up the mapping and restores the destination as example.com:443, then applies domain-based routing rules and selects an outbound. This is an example only; a lookup is not guaranteed to return the same address.

FakeDNS addresses a specific problem: by the time a connection reaches the proxy, only the IP may remain and the domain name may be lost. It does not provide proxy servers, replace VMess, VLESS, or Trojan, or change REALITY handshake settings. A subscription supplies connection settings; FakeDNS preserves the link between local connections and domains. They operate at different layers.

How Domain Restoration Differs from Regular Sniffing

Protocol sniffing inspects application-layer data in a connection, such as the HTTP Host header or the server name visible in a TLS ClientHello. FakeDNS restoration instead relies on a mapping saved earlier, so it does not have to wait for the application to expose a domain in its payload. The two methods can work together, but enabling HTTP/TLS sniffing does not by itself configure FakeDNS.

• Mapping-based restoration: Look up the domain using the destination virtual IP. The address assignment and connection handler must share a valid mapping.
• Protocol sniffing: Extract a domain from connection data. This cannot be guaranteed when the traffic contains no recognizable domain information.
• Domain-based routing: Apply rules once the domain is available. Restoring a domain does not guarantee a rule will match; check rule order and the selected outbound too.
• Connecting to the destination: A proxy outbound may pass the domain to the remote end for resolution. A direct outbound usually still needs a real IP address; the details depend on the core and outbound settings.

This is why enabling FakeDNS does not eliminate real DNS entirely. The application may avoid waiting for a real DNS lookup, but direct connections and resolving proxy server hostnames may still require real DNS. With a remote proxy, the destination domain may also be resolved remotely.

FakeDNS and TUN: Two Paths That Must Connect

TUN provides a virtual network interface that receives IP traffic matching the routing rules. FakeDNS provides virtual DNS responses and mappings. They are often used together because TUN can send connections to virtual IPs back to the proxy, but TUN alone does not guarantee that all DNS queries are intercepted or that a particular FakeDNS implementation is in use.

In v2rayN, the TUN path and the regular proxy path may use different configuration generators or processing modules. Do not paste one core's fakedns JSON into another TUN configuration format. First check the selected core, the active configuration, and the logs; then determine which layer handles DNS.

1. Turn off TUN and test the node through the existing system proxy to rule out subscription and server issues.
2. In v2rayN, open “Settings” → “Parameter Settings” and check the available cores and related options for your version. Page names may vary between versions, so use the labels shown in your app.
3. With TUN enabled, check the system routes to confirm that traffic for the virtual IP range enters the interception path instead of going to the physical gateway.
4. Also check DNS interception and each app's encrypted DNS settings. Otherwise, connections may be intercepted without creating the domain mappings they need.

V2Ray / Xray Configuration: Assignment and Restoration Must Work Together

The following configuration snippets are for V2Ray / Xray cores that support the relevant fields. They illustrate how the fields relate; they are not a complete v2rayN import configuration. They do not include inbound listeners, node outbounds, or complete routing rules. GUI clients usually generate these settings, and manual edits to generated files may be overwritten the next time they are saved.

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

In dns.servers, fakedns enables virtual DNS responses. The top-level fakedns setting defines the address pool and its capacity. The 4096 value here is an example capacity, not a default for every core or a performance metric. DNS queries must also be routed to this DNS module; adding these fields alone will not intercept system queries.

The inbound receiving connections to virtual IPs also needs its corresponding restoration mechanism enabled. Merge the sniffing object below into the relevant inbound object; it is not a separate top-level setting. Check the documentation for your core to confirm which fields it supports.

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

• enabled turns on sniffing for this inbound. fakedns in destOverride tells it to restore the destination using the virtual IP mapping.
• This example uses routeOnly: false so the restored destination can replace the original, rather than being used only for routing decisions. Do not switch to route-only mode unless you understand how your outbounds behave.
• For a proxy outbound, confirm that the restored domain is passed into the proxy chain. For a direct outbound, provide a resolution path that returns a real IP to avoid a loop in which the virtual IP is returned again.
• geosite: rules match domain categories; geoip: rules match IP address categories. A virtual IP does not indicate the destination server's geographic location, so it cannot be used to route by the real destination's IP geolocation.

When to Enable FakeDNS: Choose Based on How Connections Are Made

If an app already connects through an HTTP proxy or sends domain names in SOCKS requests, the proxy may already know the domain, so FakeDNS often adds little. It is more useful for transparent proxying where only the destination IP is visible and domain-based rules are needed.

198.18.0.0/15 is a special-purpose address range reserved for network benchmarking. It is not a public website address or a typical private network range. If your lab network or corporate environment already uses it, check for routing conflicts first. Any alternative address pool also needs to be supported by the core and accounted for in your routing plan; do not substitute an arbitrary public address range.

How to Verify FakeDNS: Don't Check DNS Results Alone

Verification needs to cover the entire path. Seeing an address starting with 198.18 or 198.19 shows only that a query returned a virtual response; it does not prove the connection restored the domain or followed the right route. Conversely, a tool may return a real address because it bypassed the expected DNS path.

1. Record a baseline. Save the current configuration, choose a domain that already works, and note the active node and routing mode. Do not change protocols while testing.
2. Trigger a fresh lookup. After enabling the configuration, restart the test app. On Windows, run ipconfig /flushdns to clear the system DNS cache. The browser's own DNS and connection caches may need to be cleared separately.
3. Check the DNS path. Use nslookup example.com to help inspect system name resolution, but it may not reproduce a browser's encrypted DNS behavior and is not sufficient on its own to confirm the setup.
4. Check connection logs. Confirm that the virtual destination is restored to the original domain and check which outbound is ultimately selected. If you temporarily increase log verbosity, revert it after testing to avoid keeping a long-term record of visited domains.
5. Test different cases. Check a proxied site, a direct site, an internal domain, and an IPv6 scenario. Testing just one page can miss a direct-resolution loop or an AAAA query that bypasses the intended path.

Common Issues and Rollback Steps

To roll back, restore DNS settings, restore the original routes, restart the interception service, and clear app caches—in that order. Keeping a known-good baseline configuration makes troubleshooting easier than changing FakeDNS, IPv6, sniffing, and routing policies all at once. When trying again, change one part at a time to identify whether the issue is query bypass, a missing mapping, or an outbound rule.