FakeDNS Explained: How Xray Virtual IP Mapping Works, When to Use It, and What to Check

How FakeDNS works: it returns an address without looking up the real IP first

Standard DNS looks up a domain's A or AAAA record with an upstream server and gets the real address before a connection is made. FakeDNS instead keeps a local mapping between domains and virtual IPs. When an app looks up a domain, FakeDNS assigns and returns an address from a specified pool. That address is not the website's server and cannot be used on its own, without the mapping.

Suppose an app looks up example.com. FakeDNS returns an address from its local pool, such as 198.18.x.x. When the app connects to that address, the traffic must pass through a processing path that can access the same mapping table. Xray can then recover the original domain, match domain-based rules, and send the request through the appropriate outbound. If the connection bypasses that path, the system will simply try to connect to a virtual IP that does not host the website.

That is why FakeDNS is often used with TUN: a virtual network interface can capture IP traffic destined for these addresses. But TUN only provides the interception path. It does not automatically ensure DNS queries reach FakeDNS, or that different cores share the same mapping. DNS queries and subsequent connections must complete the same loop.

Address pool and mapping capacity: what three numbers mean

Xray's FakeDNS configuration lets you set ipPool and poolSize. The IPv4 example below illustrates what these settings mean; it does not imply that every client uses the same defaults. The address pool and mapping capacity are separate limits. A large subnet does not mean mappings can never be evicted.

198.18.0.0/15 is a reserved range for network benchmarking, not a public website address or a private subnet typically used on home networks. It can still conflict with routes if an enterprise test network or another tunnel uses the same range. Check your local routing table before enabling it; “reserved” does not mean “conflict-free.”

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

This is a partial Xray configuration, not a complete client configuration. It does not define inbounds, outbounds, DNS interception, or routing rules, nor does it provide real DNS resolution for destinations that should connect directly. Do not treat it as a ready-to-use configuration file. Mappings exist only at runtime, so do not assume an old virtual IP will still map to the same domain after the core restarts.

FakeDNS, regular DNS, and domain sniffing compared

FakeDNS is neither encrypted DNS nor HTTP or TLS sniffing. FakeDNS creates a mapping; sniffing extracts a possible domain from connection data. Xray uses its mapping table to recover domains, so it does not need to read a hostname from the application layer on every connection. Even so, if an app connects directly to a real IP without first making a corresponding domain lookup, FakeDNS cannot infer the domain.

For domains that need a proxy, FakeDNS can avoid making the client wait for the real IP first. If the proxy outbound sends the domain to a remote server, resolution can happen later in the chain. Direct connections still need a real address. Resolution work may simply move elsewhere; it does not disappear from the connection entirely. Page load times also depend on node latency, packet loss, server response times, and the number of resources, so FakeDNS cannot guarantee a fixed speed increase.

• Good fit: Apps mainly make IP connections, TUN is reliably intercepting traffic, and domain rules need more complete matching information.
• Not a priority: Your browser already passes domains through the proxy protocol, the system proxy works as expected, and you are not losing domain names.
• Use caution: Enterprise intranets, local network device discovery, software that relies on real DNS results, and setups running alongside other virtual network adapters.
• Does not replace: Correct subscription settings, working nodes, accurate system time, or server-side support.

Before enabling FakeDNS in v2rayN: check the core and DNS path

v2rayN is the client interface; Xray is a core it can run. Seeing a “TUN” option in the interface does not mean that mode will use Xray's fakedns field. Some modes use different configuration-generation paths, so the fields and traffic interception may differ. Check the core name and version in the startup log, along with the configuration load results, before using the Xray fields in this guide.

1. Keep a baseline: Back up your current configuration. Turn off TUN and use the existing system proxy to verify that the same node can reach the target website. Note your current DNS, routing mode, and local ports.
2. Review settings: In v2rayN, check the core and inbound settings under “Settings” → “Parameter Settings,” then review the existing entries under “Settings” → “DNS Settings.” Menu names may vary by version; use the labels shown in your client.
3. Check the generated configuration: Confirm that the active configuration includes the expected fakedns, DNS server list, and inbound sniffing fields. Do not assume a feature is active just because a single toggle is on.
4. Check what gets intercepted: DNS queries must enter the intended local processing path, and connections to the virtual subnet must also be intercepted. Check whether browser secure DNS, app-level DoH, or IPv6 queries bypass that path.
5. Test one change at a time: Save and restart the core as required by the client. First test one proxied destination and one direct destination, then test a local network service. Change only one category of settings at a time.

Pay particular attention to routeOnly: using the recovered domain for rule matching is different from using it as the connection destination. If the outbound still tries to connect to the virtual IP, the request may time out. Check the current core's configuration documentation and the complete outbound design; do not copy a single Boolean value in isolation.

How to verify: check resolution results and connection logs together

Seeing a 198.18.x.x address proves only that this particular lookup returned a virtual result; it does not prove that the proxy outbound succeeded. Conversely, a page may load because the browser bypassed system DNS. Verification needs to show both where the query went and where the connection was ultimately sent.

1. Close any existing test tabs in your browser. In a Windows terminal, run ipconfig /flushdns, then quit and reopen the browser so old cache entries do not affect the test.
2. Run the query below to check whether the system's current resolution path returns an address from the pool. Do not specify an external DNS server; that would test a different path from the one the system normally uses.
3. Visit the same domain and check the core log for the destination domain and outbound tag. If needed, temporarily increase the log level, then restore it after testing to avoid logging excessive browsing activity.
4. Now check a destination that should connect directly. Confirm that its virtual IP is not being used as the final server address, and verify that the local router and intranet services are still reachable.

ipconfig /flushdns
nslookup example.com
route print

nslookup is useful for checking regular DNS queries, but it does not show how browser built-in DoH behaves. Use route print to check which routes cover the virtual subnet. If the subnet is not listed separately, that alone does not prove interception failed—some TUN setups use a broader route. Check the interface, metric, and client logs together.

Common issues: cache, IPv6, and recovery after disabling FakeDNS

FakeDNS preserves domain information along specific traffic interception paths. It does not change VMess or VLESS authentication settings, repair a broken subscription, or make an unreachable node work. Consider enabling it only after your basic connection is stable, you have a clear need for domain-based routing, and you can verify and roll back the configuration. If your browser only stalls occasionally, first narrow down the cause by checking the system proxy, DNS, and routing steps in the troubleshooting guide.