What Is FakeDNS? How It Works, How to Enable It, and When to Use It

How FakeDNS Works: Virtual IPs Preserve Domain Names

A standard DNS lookup translates a domain name into the real address of a server. FakeDNS instead assigns the queried domain a virtual IP and keeps a local domain-to-IP mapping. For example, when an app queries example.com, it may receive an address from a virtual IP pool. When the app connects to that address, the proxy core uses the mapping to recover the original domain. This is not the website's real server address and cannot be used for a direct connection over the public internet.

This flow depends on two conditions: the DNS query must be handled by the component that maintains the mapping, and the subsequent connection must pass through a handler that can look it up. If only the first condition is met, the app gets a virtual IP but cannot connect. If only the second is met, the query returns a real IP, so there is no FakeDNS mapping to use.

Once the domain is restored, the proxy can use domain rules to choose a direct or proxied connection. A direct connection usually still needs the real destination address. Whether a proxy outbound can pass the domain to a remote resolver depends on the outbound protocol and configuration. FakeDNS changes local resolution and target identification; it does not replace the final destination lookup or change VMess or VLESS protocol parameters.

What FakeDNS, TUN, and Traffic Sniffing Each Do

TUN provides the traffic entry point, FakeDNS handles address mapping, and sniffing identifies targets. They are separate mechanisms, not one switch. TUN typically receives IP packets; if an app has already resolved a domain elsewhere, the packet may not retain the domain name, so another way to identify it is needed.

FakeDNS restores domains using its own mapping; it does not require apps to send a readable HTTP host header or TLS hostname. However, an app's built-in encrypted DNS, fixed-IP connections, or local DNS cache may bypass this mapping. Enabling sniffing does not mean every connection will match a domain rule.

Before You Enable It: Check Your Core and DNS Interception

v2rayN is a desktop client; its configuration options depend on the core and operating mode in use. v2rayNG is for Android and uses the Xray core, while v2flyNG is for Android and uses the V2Fly core. Don't assume configuration fields are interchangeable just because the clients have similar names. In particular, TUN traffic handling and the proxy core for a node may be provided by different components. Xray's FakeDNS fields cannot simply be copied into another component's configuration.

Check IPv4 and IPv6 separately. If you configure an IPv4 virtual pool but an app can still obtain a real IPv6 address, it may connect through a different path. This is not necessarily a fault, but routing may behave differently than expected. Don't disable IPv6 blindly just to make test results look consistent; first confirm that your client supports the corresponding IPv6 interception.

Xray Configuration Example: Address Pool, DNS, and Entry-Point Restoration

The Xray JSON snippet below illustrates how the fields relate; it is not a complete TUN configuration. It shows the top-level fakedns address pool, a DNS fakedns server, and domain restoration on a SOCKS inbound. Before merging it, confirm that your Xray version supports these fields and integrate them with the existing dns and inbounds settings. Do not overwrite existing inbounds or outbounds.

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": [
      "fakedns"
    ]
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "fakedns"
        ]
      }
    }
  ]
}

• poolSize: 65535 sets the mapping pool capacity. It is not the number of nodes and says nothing about speed. For long-running use, coordinating mapping lifetimes with app caches matters more.
• 127.0.0.1:10808 is the SOCKS inbound used in this example, not a DNS listening address. Setting it as the system DNS server will not create a DNS service.
• Here, dns.servers shows only FakeDNS. A real deployment also needs real DNS resolution rules supported by the core; queries that require real IPs must not all be sent to the virtual pool.
• fakedns in destOverride restores the destination domain from the mapping. It does not create a TUN interface or route system DNS into the core.

When a client generates its configuration automatically, editing a temporary generated file may stop working after a restart or node change. Use the custom configuration option provided by your version, or adjust DNS and inbound settings where supported. To understand the routing fields, start with the configuration guide. Don't combine examples for different cores in one configuration.

Verification: Trace a DNS Response Through to the Routing Result

Change one type of setting at a time, keep a recoverable configuration, and test in the order below. The goal is to verify the entire flow, not just see a virtual IP. A single latency test cannot confirm that domain-based routing works.

1. Record a baseline. Choose a test domain and note its current DNS response, whether the connection succeeds, and which outbound the routing rules select. Don't change nodes, subscriptions, and rule sets all at once.
2. Clear old caches. On Windows, run Clear-DnsClientCache in PowerShell, then restart the test app. This system command does not clear every browser's internal cache or the proxy core's own mappings.
3. Check the response address. If the query goes through the configured IPv4 virtual pool, the response should fall within 198.18.0.0/15. If it still returns a real address, check where DNS is going before changing your routing rules.
4. Make a real connection. Check the client logs to see whether the target is restored to the expected domain, then confirm which rule or outbound is selected. Log fields vary by core, and not every log level shows mapping details.
5. Test direct and proxied connections separately. Both types of target should connect successfully. If only direct connections fail, check real DNS resolution and the direct outbound. If all virtual IPs time out, check the connection handling path first.
6. Check what happens when you turn it off. Disable the mode, clear system and app caches again, and confirm that new queries no longer reuse old virtual IPs. Otherwise, a failure after disabling it may be mistaken for a network problem.

When to Use FakeDNS—and When to Hold Off

FakeDNS is a good fit for setups that need transparent interception, rely on domain rules, and can manage DNS centrally. It can reduce reliance on protocol sniffing, but it also requires mapping state and caches to stay in sync. Enable it to address a specific problem, not by default.

• Worth evaluating: After TUN interception, logs often show only IPs, domain rules fail to match, and you can control system and app DNS paths.
• Keep your current setup: The browser sends domain names through an explicitly configured proxy, domain-based routing is stable, and you don't need transparent interception.
• Troubleshoot first: Your corporate network uses split DNS, internal domains, or routes that conflict with the virtual pool. Separate internal and public DNS queries before proceeding.
• Test with care: An app stores DNS results on disk for long periods, passes IPs between processes, or keeps using old connections after the proxy exits.
• Don't expect it to help with: Unreachable nodes, incorrect server authentication parameters, or a congested transport path. Domain mapping does not solve these problems.

LAN printers, network storage, and internal service domains usually need DNS resolution that meets local network requirements. Replacing all responses with virtual IPs may disrupt discovery, access controls, or diagnostic workflows that depend on real addresses. Test a limited scope first, then expand; it's easier to troubleshoot than enabling every related option at once.

FakeDNS FAQ and Troubleshooting

A practical setup order is: get a standard proxy and real DNS working first, verify TUN interception next, then introduce FakeDNS. Keep logs and a way to revert each change so you can tell whether a problem is in resolution, routing, or the outbound connection.