How FakeDNS Works: How Fake Address Mapping Reduces DNS Latency

The FakeDNS flow: return a fake IP, then restore the original domain

A standard DNS flow sends the domain to a resolver first. Once the real A or AAAA record arrives, the application connects to the returned address. That means at least one DNS round trip; a slow system resolver, the wrong DNS route, or a cache miss can block connection setup at the resolution stage.

FakeDNS changes the local resolution path. When an application queries a domain, the core does not need to request the real address from a public DNS server immediately. Instead, it assigns a fake IP from a predefined pool and records the domain-to-address mapping. The application then connects to the fake IP; the TUN inbound captures that connection, the core retrieves the original domain from the mapping, and routing rules select proxy, direct, or blocked egress.

A commonly used IPv4 pool is 198.18.0.0/15. This range is intended for network-device benchmarking and is not publicly routable, making it suitable as a local mapping marker. A fake IP is not the destination server’s address and is not sent directly to a proxy node as the final target. It works like a local index; the actual proxy request still targets the restored domain.

The latency figures above come from a sample of 100 consecutive cold queries on the same device: local FakeDNS returned a median of about 1.2 ms, while the remote DNS round trip had a median of about 43 ms. This only shows that the first resolution response can arrive sooner; it does not mean total page-load time will necessarily drop by 41.8 ms. TLS handshakes, node round-trip time, packet loss, and server response time still determine what happens next.

How the mapping table, sniffing, and egress work together

FakeDNS works only when three conditions are met: the core receives the DNS query, the connection to the fake address is captured by the appropriate inbound, and the mapping is used to restore the domain before egress. If you enable the address pool without sending TUN traffic into the core, the application may receive 198.18.x.x but fail to connect.

When the core receives a connection aimed at a fake IP, it checks whether the destination belongs to the FakeDNS pool. If a matching record exists—for example, 198.18.0.27 maps to example.net—the destination can be restored to a domain. The router then checks domain, IP, port, and inbound-tag rules in configuration order before selecting proxy or direct egress.

It is easy to confuse protocol sniffing with FakeDNS restoration. HTTP, TLS, and QUIC sniffing try to identify a domain from traffic contents; FakeDNS restoration reads the mapping created earlier. They can work together, but restoration does not depend on every connection exposing a recognizable hostname, so it is more reliable for connections whose domain cannot be extracted from the payload.

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

This configuration illustrates only the conceptual relationship between the address pool and DNS servers. It cannot be used on its own without inbound, routing, and egress settings. When a client generates the actual configuration, also verify that the TUN inbound has destination restoration enabled and that the local network is not using the same range for lab devices or enterprise test environments.

FakeDNS: practical effects on latency and routing

FakeDNS’s most direct benefit is changing “the application waits for a real DNS response” to “the application immediately receives a local fake address.” The difference is most noticeable when remote DNS round trips are long, first packets often time out, or several applications issue cold queries at once. For domains already in the system cache, the full resolution delay is not paid again, so the benefit is smaller.

A second benefit is preserving domain information. After ordinary resolution, an application may connect only to the real IP, leaving the TUN layer with just an address. When multiple domains share one IP, IP-only rules cannot distinguish them reliably. By restoring the original domain during connection handling, rules such as domain, domainSuffix, and geosite can participate before egress is selected.

What to observe	Regular remote DNS	FakeDNS	How to check
First returned address	Real A/AAAA record	Reserved-range fake IP	Check the result seen by the application
Domain information	May be reduced to an IP after resolution	Restored from the mapping table	Check routing-hit logs
Cold-query latency	Affected by the DNS round trip	Usually a local response	Run repeated tests and compare medians
Final connection target	Real IP or remote-resolution result	Restored domain	Check proxy-egress logs

A third effect is a more consistent resolution path. If a domain should use a proxy but the system first resolves it through the local network, the DNS path and traffic path may diverge. FakeDNS lets the local machine assign a fake address first and defer real resolution to the proxy egress, reducing the influence of local DNS on proxy-domain results.

FakeDNS also changes troubleshooting. Seeing 198.18.x.x is not, by itself, evidence of a DNS error. First check whether the address belongs to the configured pool, whether a mapping exists, and whether the connection entered TUN. Only when the application receives a fake address but the core cannot restore the domain does it indicate a broken link in the chain.

Pairing FakeDNS with TUN mode and routing rules

TUN mode uses a virtual network interface to capture traffic from processes that do not actively use the system proxy, making it the most common entry point for FakeDNS. In v2rayN, open Settings → Parameter Settings to verify the local listening ports before enabling TUN mode. The location of TUN options may vary by version; rely on the status bar and core startup logs for the final confirmation.

On Android, v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. After enabling device-wide traffic interception, check that the client’s local DNS, domain strategy, and routing mode all come from the same configuration plan. Do not let another local networking tool occupy the VPN interface at the same time, or DNS queries may bypass the current core.

1. Verify TUN interception first. Disable the application’s own HTTP or SOCKS proxy settings, start the client, and visit a test domain to confirm that the connection still appears in the core logs.
2. Then inspect the fake address. Query a domain that is not cached and check whether the response is a 198.18.x.x address from the configured pool.
3. Confirm domain restoration. Look for the original domain in the routing logs rather than only a fake IP. If the logs show only a fake IP, check the destination-restoration settings.
4. Verify rule matching. Test one domain that should use a proxy and one that should connect directly, confirming that each reaches the expected egress tag.
5. Test the fallback last. Disable FakeDNS and restore ordinary DNS to ensure that a clear, usable fallback remains when the configuration fails.

Rule order is especially important. A fake address is only a temporary target. If a broad IP rule matches 198.18.0.0/15 first and allows it directly, the connection may be sent to the wrong egress before the domain is restored. A safer approach is to let the TUN inbound restore the domain, then route by domain rules while explicitly excluding LAN and internal services.

When to enable FakeDNS—and when not to

FakeDNS is a good fit when TUN is reliably capturing traffic, remote DNS round trips are long, domain-based routing is extensive, and applications often reach the core with only an IP address. In that situation, FakeDNS both shortens cold-query waits and restores the original domain for routing, offering more than a simple reduction of a few dozen milliseconds.

If you use a browser that explicitly connects to a local HTTP or SOCKS port, it will usually pass the domain directly to the proxy. Since the core already has the domain, FakeDNS adds little routing accuracy. Prioritize keeping listening ports such as 10808 and 10809 conflict-free, and verify that the system proxy points to the correct port.

• Recommended: TUN captures all traffic, and the core logs frequently show only destination IPs.
• Recommended: Remote DNS cold queries consistently exceed 50 ms, causing noticeable waits when applications open.
• Use caution: Internal company domains must be resolved by LAN DNS, with different results by network segment.
• Use caution: The real network already uses 198.18.0.0/15 or a custom fake-address pool.
• Limited benefit: The application submits domains through an explicit proxy, and local DNS is not the current bottleneck.

Verify and troubleshoot from the logs

Do not validate FakeDNS only by checking whether a website opens. A complete check covers five stages: DNS response, TUN capture, domain restoration, rule matching, and proxy egress. Missing any one of them can produce a setup that works only intermittently or fails in certain applications.

Choose two domains you have not visited before: one that should use a proxy and one that should connect directly. Clear the client’s internal DNS cache, query each one, and record the returned address and time. Then connect immediately and confirm the original domain, inbound tag, and egress tag in the logs. Do not switch nodes repeatedly during testing, or node differences may be mistaken for DNS differences.

1. Record the client’s current settings. Confirm that the local SOCKS port is 10808 and the HTTP port is 10809, or record the actual custom values.
2. After starting TUN, inspect the core logs to confirm that the virtual interface was created successfully, with no route-add failure or interface-in-use warning.
3. Query a test domain and confirm that the response address falls within the configured FakeDNS pool. The response time should normally be lower than a remote DNS round trip.
4. Start a connection and search the logs for the original domain. Confirm that 198.18.x.x is not being used as the final destination throughout.
5. Confirm that the proxy domain matches proxy and the direct domain matches direct, without being overridden by a broader rule earlier in the list.
6. Run 20 consecutive tests and record the median and failure count for each. Do not base the conclusion on the single fastest result.

If testing fails, roll back in reverse order: temporarily disable domain-routing rules and confirm that basic proxy egress is reachable; then disable FakeDNS and use ordinary DNS to check resolution; finally disable TUN and use an explicit system proxy to verify the local listening ports. Change only one variable at a time so you can identify whether the fault lies in the address pool, DNS, TUN, routing, or node path.

FakeDNS’s core value is not producing a seemingly unusual DNS result. It preserves the domain dimension reliably while global traffic is being intercepted. When configured correctly, the fake address exists only briefly on the local machine, routing uses the restored domain, and proxy egress continues to establish connections according to the actual VMess, VLESS, and subscription-node settings. Whether to enable it depends on DNS latency, the TUN interception method, internal network structure, and routing needs.