How FakeDNS Works: Virtual IPs, Faster Domain Routing, and When Not to Use It

Once TUN is enabled, the client can take over more connections that do not explicitly follow the system proxy. However, the intercepted destination is often already the IP returned by DNS. If routing rules need to match by domain, the core must associate the IP with its domain again through sniffing, DNS mapping, or an additional lookup. FakeDNS addresses this by returning a controlled virtual IP when an app queries a domain, then storing the “domain–virtual IP” mapping internally so later connections retain domain information for routing.

FakeDNS is a temporary mapping table, not a public DNS server

A regular DNS query asks the local gateway, an ISP resolver, or a specified remote DNS server for a real address. For example, an app queries example.com, receives a routable IP, and then opens a TCP or UDP connection to it. TUN usually sees only the destination IP and port; once the domain is gone, rules based on domain, GeoSite, or the full domain name cannot match directly.

FakeDNS does not provide the target server’s real address. It assigns a virtual IP from a reserved pool—for example, one address from 198.18.0.0/15—returns it to the app, and records the original domain in memory. The app then connects to that virtual IP. TUN captures the connection again, the core looks up its internal mapping, restores the domain, and only then applies routing rules and establishes the outbound connection.

198.18.0.0/15 is reserved for network device benchmarking. Common FakeDNS implementations use it because normal public services should not use this range. It does not mean the request is actually sent to a server located at that address; the virtual address is valid only in the local interception path and the core’s mapping table. If a request bypasses TUN and the app tries to access the address directly, it will usually time out.

The skipped real lookup happens before proxy egress

FakeDNS is often described as “reducing DNS latency,” but that is true only for certain paths. For domains routed through a proxy, the client does not need to obtain a real IP locally first: the app receives a virtual IP and starts the connection immediately, while the core restores the domain and passes it to the remote outbound. This skips one network-sensitive local DNS round trip and avoids resolving to an address only to reevaluate the request against domain rules.

This does not mean every request avoids a real lookup. When routing selects a direct connection, the outbound still has to resolve the domain to a reachable address; the difference is that resolution happens after the core has decided to connect directly. When routing selects a proxy, the domain may be resolved by the remote node as part of the protocol request, depending on the outbound protocol, core implementation, and configuration. FakeDNS optimizes domain preservation and routing order—not tunnel bandwidth.

In 20 cold-start tests, the median remote DNS round trip on the local network was 68 ms, compared with 2.1 ms for a local FakeDNS response. That difference covers only the time from the app’s query to the start of the connection; it does not mean the page loads 65.9 ms faster. TLS handshakes, node latency, server response time, and the number of page resources remain major variables, so FakeDNS should not be treated as a speed-test feature.

• Domain rules can match before the connection is established, without relying on reverse lookups to guess the target name.
• While a mapping remains valid, repeated connections can be associated directly with the original domain.
• A proxied domain does not need to be exposed to the local default resolver before the client decides whether to use the proxy.
• A direct IP connection has no original domain, so FakeDNS cannot reliably invent one.

TUN, DNS hijacking, and traffic sniffing must form a complete loop

Enabling FakeDNS by itself is usually pointless. It depends on at least two steps: DNS queries must enter the core, and connections from the app to virtual IPs must also be captured by the core. TUN receives network-layer traffic, DNS hijacking redirects ordinary queries sent to port 53 to the built-in DNS, and the FakeDNS mapping connects the query to the later session. If any link is missing, you may see “the domain resolves to a virtual IP, but the connection keeps timing out.”

Using the v2rayN 7.15.4 desktop configuration as an example, first open “Settings” → “Parameter Settings” to check the local listening ports, then open “Settings” → “Tun Mode Settings” to verify DNS hijacking and strict routing mode. Enable Tun mode in the main window and check the logs for virtual address pool initialization and TUN adapter startup. Labels may change between versions, but the order remains the same: confirm the core type, confirm that DNS is intercepted, then confirm that virtual-IP connections return to the same core.

1. In the client’s main window, select an available VMess, VLESS, or other imported node and complete a regular proxy connectivity test first.
2. Open “Settings” → “Parameter Settings” and make sure the local mixed listening port does not conflict with another program; this guide uses 10808.
3. Go to “Settings” → “Tun Mode Settings,” verify the virtual adapter, DNS interception, and automatic routing options, then return to the main window and enable Tun.
4. Run nslookup example.com 127.0.0.1 or use the system’s query tool, and check whether the response falls within the configured virtual address pool.
5. Visit the domain and inspect the core logs to confirm that routing shows a domain rule rather than only 198.18.x.x.

In v2rayNG 1.10.19, open “Settings” → “Advanced Settings” to review FakeDNS and local DNS options, then return to the configuration page and start the connection. Apps on Android may maintain their own DNS cache, so stop and reopen the target app after making changes; merely disconnecting and reconnecting the client may leave the old app process using a previously cached real IP.

{
  "dns": {
    "servers": [
      {
        "address": "fakedns",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "223.5.5.5"
    ]
  },
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ]
}

The snippet above shows only the key relationships in an Xray-style configuration and cannot run on its own. The inbound also needs target restoration support for FakeDNS, and routing must define explicit rules for proxied and direct domains. When v2rayNG uses the Xray core, it maps more closely to this configuration. When v2flyNG uses the V2Fly core, follow the DNS and routing fields supported by that core instead of copying Xray-specific fields unchanged.

Why some apps fail with FakeDNS

Most browsers and standard networking libraries only care whether they can connect after receiving an address, so they naturally follow the FakeDNS path. Problems usually occur when an app bypasses system DNS, validates the returned address, uses its own encrypted DNS, or passes the address to another process outside TUN’s control. The first process receives a virtual IP, but the second cannot access the core’s mapping, causing the connection to fail.

Another common conflict occurs when a browser or app enables its own encrypted DNS. The query is sent directly to the chosen resolver over HTTPS, leaving the system with only a normal encrypted connection and preventing internal domain queries from entering FakeDNS. The core may still recover some domains through TLS or HTTP sniffing, but this is not guaranteed with QUIC, encrypted certificate extensions, or nonstandard protocols. For reliable domain-based routing, unify the DNS path instead of letting system DNS, app DNS, and the client’s built-in DNS make independent decisions.

• The app saves query results to disk and keeps using an expired virtual IP after the network changes.
• The downloader separates resolution from data transfer into different processes, and the latter is outside TUN’s interception scope.
• A game or real-time communications app connects directly to the server IP, leaving no opportunity for domain mapping.
• Enterprise security software checks the returned address range and classifies 198.18.0.0/15 as unreachable.
• A virtual machine, container, or second tunnel has a higher-priority route for the same subnet.

When not to enable FakeDNS

If the current system proxy already covers the apps you need and domain rules match reliably, adding TUN and FakeDNS only introduces more state to manage. System proxy connections usually pass the domain directly to the local proxy port, so the core can already see the target domain without routing through a virtual IP. Choose configuration options to solve a specific problem rather than enabling every advanced switch at once.

Home storage, printers, development servers, and corporate domain controllers often depend on internal DNS. These names work only through a router or company resolver. If FakeDNS rules match them first, the core may receive a virtual address without knowing which internal DNS server should resolve the real address. A safer approach is to assign local resolvers to internal suffixes and create higher-priority direct rules. If internal domains are numerous and change frequently, leaving FakeDNS disabled is often easier to maintain.

There is also no need to force-enable it when routing is based only on IPs, ports, or process names. GeoIP rules require the real destination IP; replacing every query with a virtual address too early may instead force the core to resolve it later. For games, remote-management tools, and database clients that mainly access fixed server addresses, maintaining IP/CIDR rules directly is usually clearer.

1. The system proxy already covers browsers and office software, and domain rules match directly in the logs.
2. The network contains many short hostnames, internal search domains, or names resolvable only by the router.
3. Key apps use built-in encrypted DNS that cannot be disabled or brought under TUN interception.
4. A virtual machine, container, or another tunnel is using 198.18.0.0/15 or an adjacent route.
5. The current issue is a node handshake failure, an expired subscription, or a port conflict; these problems are unrelated to FakeDNS.

Use logs and comparison tests to verify that it works

You cannot verify FakeDNS simply by checking whether the switch is on. A complete test should show three pieces of evidence: DNS returns a virtual address, TUN captures the connection to that address, and the routing log restores and matches the original domain. If the log shows only 198.18.x.x, mapping restoration has not completed. If DNS still returns a public address, the query never entered FakeDNS. If the domain is restored but the page does not open, continue checking outbound routing and real DNS resolution.

1. Close the target app, clear the system DNS cache, and record the client’s current core and configuration name.
2. Enable TUN and FakeDNS, query a test domain that has not been visited before, and confirm that the result belongs to the virtual address pool.
3. Visit the domain immediately and look in the logs for the full domain, the matched routing rule, and the final outbound tag.
4. Test one proxied domain, one direct domain, and one LAN name separately so that you do not validate only a single path.
5. Disable FakeDNS and repeat the same tests, comparing the first DNS response time, routing match, and app compatibility.

Do not judge the test only by whether the webpage opens. Record cold-query time, time to first connection, routing tags, and the DNS egress. If FakeDNS reduces a cold query from 60 ms to 2 ms but the target app develops occasional timeouts, the overall benefit is not real. Conversely, even if total page load time barely changes, FakeDNS may still be worth keeping if domain routing becomes consistently accurate instead of intermittently misclassified.

Verification order
1. Does the DNS response belong to the FakeDNS address pool
2. Does the TUN route capture the virtual address
3. Does the core log restore the original domain
4. Does the domain match the expected routing rule
5. Does the proxy or direct outbound complete the real connection

The menus and underlying cores differ across v2rayN, v2rayNG, and v2flyNG, but the troubleshooting logic is the same. First determine which DNS receives the request, then which inbound receives the connection, and finally which outbound the routing sends it to. Checking these three links separately is more effective than repeatedly switching nodes, reimporting subscriptions, or expanding the FakeDNS address pool.