FakeDNS Explained: How Virtual IPs Speed Up Domain-Based Routing

What problem does FakeDNS solve?

With standard DNS, an app first resolves a domain to a real IP, then opens a connection to that IP. When the proxy core takes over, the target may be reduced to an address such as 203.0.113.20:443. If several domains share one address or the server address changes frequently, IP-only routing rules can easily misclassify traffic.

FakeDNS does not provide real public IP addresses. When it receives a DNS query from an app, it assigns a virtual IP from a predefined pool and stores a temporary mapping between the domain and that address. The app then connects to the virtual address; the TUN inbound intercepts the connection, and the proxy core retrieves the original domain from the mapping table. The routing module can therefore match domain, domainSuffix, or domains listed in rule sets directly.

A common IPv4 pool is 198.18.0.0/15. This range is reserved for network equipment benchmarking and should not appear in public routing, making it suitable as a local virtual target. A /15 network contains 131072 addresses, but Xray configurations typically use a smaller mapping pool, such as poolSize: 65535, to avoid creating an unnecessarily large table.

The 1–3 ms figure above is the local response range for consecutive queries to uncached domains on the same Android device. It only measures how long FakeDNS takes to return a virtual address, not the time needed to load a webpage. The actual connection still involves node handshaking, remote DNS resolution, TLS setup, and content transfer.

How a domain request passes through virtual IP mapping

The complete path has six steps. First, the app sends an A or AAAA query to the system DNS. Second, TUN mode passes the DNS traffic to the proxy core. Third, FakeDNS selects an unused address from the pool and writes it to the mapping table. Fourth, the app receives the virtual address and opens a TCP or UDP connection. Fifth, the inbound looks up the domain from the destination address. Sixth, the routing module chooses direct, proxy, or blocked handling based on the domain.

1. Query enters the proxy core: The DNS request must be captured by TUN or a controlled local DNS service. If the app connects to an external DNS server directly, FakeDNS will not receive the query.
2. Temporary mapping is created: For example, news.example may be assigned 198.18.0.12; the mapping exists only in local memory.
3. App connects to the virtual address: The app treats 198.18.0.12 as an ordinary destination and does not need to understand FakeDNS.
4. Inbound restores the domain: The core retrieves news.example from the mapping table and passes the domain to the sniffing and routing modules.
5. Routing rule matches: Domain rules can choose the outbound before a real DNS query occurs, avoiding the information loss caused by resolving first and deciding afterward.
6. Outbound completes resolution: A direct outbound usually resolves the real address locally; a proxy outbound that supports domain targets can pass the domain to the remote side for resolution. The exact behavior depends on the outbound protocol and DNS settings.

Key fields in an Xray configuration

An Xray configuration usually has three coordinated parts: the top-level fakedns defines the address pool, dns.servers sends queries to FakeDNS, and the inbound sniffing.destOverride lets the core restore the target domain from the virtual-address mapping. Adding only one field does not create a complete path.

The minimal example below illustrates how the fields work together. A client-generated configuration may also add local DNS settings, rule sets, and multiple inbounds. Export the current configuration before editing, and confirm that the client allows custom underlying JSON; subscription updates may overwrite manually changed node parameters.

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": [
      "fakedns",
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  },
  "inbounds": [
    {
      "tag": "tun-in",
      "protocol": "tun",
      "settings": {
        "stack": "system"
      },
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls",
          "quic",
          "fakedns"
        ],
        "metadataOnly": false
      }
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch"
  }
}

fakedns in destOverride reads the mapping; http, tls, and quic extract domain names from the corresponding protocol metadata. These sources do not conflict. The mapping can provide a domain that was queried, while protocol sniffing can handle some connections that bypassed FakeDNS but still carry a hostname in the handshake.

When v2rayNG uses the Xray core, manage TUN and local DNS through the client interface whenever possible. A common path is “Settings” → “VPN settings” for traffic interception options, followed by “Settings” → “Routing settings” to verify rule order. Names may vary between versions, so use the exported runtime configuration and core logs to confirm that it works rather than relying only on the switch state in the interface.

When should FakeDNS be enabled?

FakeDNS is most useful when TUN handles all device traffic and routing rules are primarily domain-based. Android apps often resolve domains themselves and pass real IPs to the network stack. When TUN sees only a destination IP, domain-rule matching depends on sniffing; with FakeDNS, the DNS query and subsequent connection are linked through a mapping, making routing decisions more direct.

• Large-scale domain routing: Rules contain thousands of domain suffixes or rule sets and the target domain must be known before the connection is established.
• Shared-address services: Multiple sites reuse the same service addresses, so IP-only rules cannot reliably distinguish their domains.
• Frequently changing addresses: Dynamic scheduling returns different server addresses, making static IP rules obsolete quickly.
• Remote resolution required: The proxy outbound must preserve the domain so the network where the node is located can perform the final resolution.
• UDP and QUIC traffic: When an app uses UDP 443, FakeDNS mapping and QUIC sniffing can help recover the target information.

With v2rayN in system proxy mode, browsers usually submit the destination domain directly to a local SOCKS or HTTP inbound. The core already has the domain in this case, so enabling FakeDNS may provide little noticeable benefit. Decide based on the inbound type and the target format shown in the logs.

Use caution when the LAN has special routes. Some labs, virtualization platforms, or enterprise devices may use 198.18.0.0/15 for performance testing or internal simulation. If the system routing table already points this range to a physical interface, FakeDNS addresses can overlap with the existing network, causing connections to go to the LAN instead of entering TUN.

How FakeDNS, sniffing, and TUN work together

TUN intercepts IP packets, FakeDNS maintains the relationship between domains and virtual addresses, and sniffing extracts domains from the HTTP Host, TLS Server Name, or QUIC handshake. They solve different problems. Connecting them in the right order lets domain rules cover more application traffic.

Build the smallest working path first, then add advanced settings one at a time. Changing the address pool, DNS servers, routing rules, and MTU all at once makes the source of a failure difficult to isolate. The sequence below suits v2rayNG configurations using the Xray core and is also useful for checking runtime configurations generated from subscriptions.

1. In “Settings” → “VPN settings”, confirm that TUN or VPN interception is enabled, and check whether the target app is excluded by per-app rules.
2. After starting the connection, inspect the core logs to confirm that a TUN inbound exists and that there are no address conflicts, permission errors, or interface-creation failures.
3. Check the fakedns address pool in the runtime configuration and confirm that the DNS server list includes a FakeDNS handler.
4. Confirm that inbound sniffing is enabled and that destOverride includes at least fakedns; retain http, tls, and quic when web-traffic identification is needed.
5. In “Settings” → “Routing settings”, check the rule order. Blocking rules, private-address rules, and direct rules may match before the domain rules if they appear first.
6. Start a connection to a test domain that has not been visited before, and check whether the logs show the virtual address, restored domain, and final outbound tag in sequence.

MTU problems are a different layer from FakeDNS. If the domain is restored correctly but the page loads only partially or a large file stalls, check the TUN MTU. On Android, compare 1500 with 1400 or 1380, changing only one value at a time. If no domain can establish a connection, return to DNS capture and address-pool routing.

Mux does not replace FakeDNS either. Mux carries multiple logical connections over one underlying connection and mainly affects connection reuse; FakeDNS preserves the target domain. Enabling or disabling Mux should not change whether virtual-address mappings are created, but it may change the connection count and how events appear in the logs.

Common failures and step-by-step checks

FakeDNS failures usually fall into three categories: an app cannot connect after receiving a virtual IP, domain rules do not match, or access remains broken briefly after the client is closed. For the first, check whether TUN captures the virtual range; for the second, check the mapping and rule order; the third is usually related to a virtual address left in the system DNS cache.

Do not judge troubleshooting by browser results alone. At minimum, use the core logs to verify four facts: whether the DNS query entered the client, whether a virtual address was assigned, whether the inbound restored the domain, and which outbound the router ultimately selected. If one step is missing, return to that module instead of replacing the node and protocol at the same time.

Also distinguish fast resolution from fast connections. FakeDNS can answer locally within a few milliseconds, but proxy-node latency, TCP packet loss, the TLS handshake, and server response time still determine page speed. If virtual mapping and routing are correct, continue by checking node latency, packet loss, and transport parameters.