How to Detect DNS Leaks in V2Ray: Configure Remote DNS, FakeDNS, and TUN

1. What Is a DNS Leak? When DNS and Web Traffic Take Different Routes

DNS translates domain names into IP addresses. An established proxy connection does not mean the DNS lookup that came before it also used the proxy. For example, an app might ask your home router for a destination IP, then send the connection through a local proxy port. The webpage appears to use the proxy, but your local resolver may still see the domain you visited. A leak is a lookup that violates your intended routing policy—not simply any lookup handled by a local resolver.

Using direct DNS for websites in mainland China that are meant to connect directly is usually reasonable. The issue this guide addresses is a domain that should use the proxy but whose DNS query goes to a resolver on the local network. VMess and VLESS handle proxy traffic; they do not automatically capture every DNS request made by the system. A subscription provides node settings, not necessarily a complete DNS policy for your device.

2. How to Test for DNS Leaks: Establish a Baseline, Then Check the Physical Adapter

A browser-based test shows the recursive resolver's egress as seen by the test site; it may not be the server your client connects to directly. Public DNS services may use exits in different regions, and the city shown may come from an outdated geolocation database. So don't treat a mismatch between the resolver's city and your proxy node's city as conclusive evidence. Check which network adapter carries the query and whether that matches your rules.

1. Record a baseline. Turn off TUN and the system proxy. Note your system DNS addresses, the browser's Secure DNS setting, and the resolvers listed by the test site. Don't visit sensitive sites during testing.
2. Keep variables constant. Use the same node and routing rules for each test, and test the same page. Don't switch nodes or change browser DNS settings mid-test, or you won't know which change affected the result.
3. Clear the cache. On Windows, run ipconfig /flushdns in a terminal, then close and reopen the browser. The core's DNS cache usually requires a core restart to clear.
4. Check system lookups. Run the command below and note the default resolver and query result. This shows the system's DNS path; the browser may use a different one.
5. Check the physical adapter. In your packet capture tool, select the Ethernet or Wi-Fi adapter that is connected to the internet. Check whether the query goes directly to a local resolver. Seeing DNS packets on a virtual adapter alone does not mean they have left your device.

ipconfig /all
ipconfig /flushdns
nslookup example.com

# Packet capture display filter: check traditional DNS and common DoT connections
udp.port == 53 || tcp.port == 53 || tcp.port == 853

example.com is a sample domain for demonstrating a query, not a DNS leak test service. For a real test, choose a domain your rules explicitly route through the proxy. Browser-based DoH uses HTTPS, so a port 53 filter won't identify it on its own. Check the browser's Secure DNS settings, connection destination, and client routing logs together.

3. Remote and Direct DNS in v2rayN: Configure Both the Resolver and Its Route

In v2rayN, open Settings → Parameters and check the active core and listener settings. Then go to Settings → DNS Settings and review the DNS configuration for that core. Menu locations and field names vary by version, so use the current interface and generated configuration as your reference. Pay particular attention to the difference between the core used for regular proxy connections and the one used by TUN. Don't paste a DNS JSON block into the configuration area for a different core.

Use remote DNS for domains that should connect through the proxy, and direct DNS for domains explicitly routed directly. Configuring a remote resolver is only the first step: if the connection to that resolver still goes direct, encrypted queries or not, DNS is not following the proxy route. DoH encrypts the connection to the resolver; it does not choose a proxy outbound for you.

• Handle bootstrap lookups first. If the node server is specified by domain name, it needs a usable IP before the proxy connection can be established. Give node domains a reachable bootstrap DNS path of their own to avoid the loop where you need the proxy to resolve the node and the node to connect to the proxy.
• Limit direct DNS to the domains that need it. Send only explicitly direct domains to the direct resolver. Don't use it as an unrestricted fallback for every failed query.
• Check rule order. Put resolver outbound rules ahead of broad direct rules that might match first. Routing rules are generally evaluated in order, and the first match determines the route.

Xray DNS snippet: match direct domains separately and use remote DNS for the rest

This example uses Xray configuration syntax. It requires geosite.dat to support the geosite:cn category. If the rule data is missing, fix the data file first or use an explicit list of domains instead. The example addresses illustrate the intended roles; verify that they are reachable on your network. disableFallbackIfMatch prevents a matched domain group from falling through to another resolver on failure, but it cannot control queries made independently by browsers or apps.

{
  "dns": {
    "queryStrategy": "UseIP",
    "disableFallbackIfMatch": true,
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"],
        "skipFallback": true
      },
      {
        "address": "https://1.1.1.1/dns-query"
      }
    ]
  }
}

Merge the following rules into your existing routing.rules; don't replace the entire routing configuration. This example assumes your configuration has outbounds named proxy and direct. If the client generates different tags, use the actual tags. The example selects an outbound by resolver IP, which can also affect other connections to those IPs. Review the impact against your existing rules before using it.

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": ["1.1.1.1/32"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": ["223.5.5.5/32"],
        "outboundTag": "direct"
      }
    ]
  }
}

4. Prevent DNS Leaks in TUN Mode: Handle DNS and IPv6 After Capturing Traffic

TUN routes system traffic through a virtual network adapter, making it useful for apps that ignore the system proxy. But it is not a switch that forces every request through the proxy: routing rules still decide whether traffic goes direct or through the proxy. Whether DNS is intercepted and sent through a controlled resolution path also depends on the TUN configuration. Save your current settings, enable “Enable TUN” on the v2rayN main screen, grant the required system permissions, and check the startup log.

1. Confirm the virtual adapter is up. If the core fails to start, fix the permission, driver, or configuration issue first. Don't try to hide a startup failure by changing DNS settings.
2. Confirm DNS is being captured. Check that the TUN configuration includes applicable DNS hijacking or redirection rules, then verify with system lookups and a packet capture. Changing the adapter's DNS address alone won't control apps with hard-coded resolvers.
3. Review routing exclusions. You can route local network traffic directly if needed, but make sure exclusions aren't also letting DNS requests that should use the proxy escape. Broad direct rules must not match the remote resolver's address first.
4. Check IPv6 too. Capturing IPv4 traffic in TUN does not mean IPv6 is covered. Check the IPv6 default route and DNS servers. If you don't need IPv6, you can temporarily disable it to compare results after considering the impact—but disabling IPv6 is not a universal fix.
5. Test reconnection and resume from sleep. Run another lookup after switching Wi-Fi networks or waking the device from sleep. The adapter's DNS, system routes, and virtual adapter state may have changed.

v2rayN's TUN implementation may use the sing-box core, whose DNS and FakeIP configuration differs from Xray FakeDNS. Configure it through the appropriate settings or in the format for that core. v2rayNG uses Xray, while v2flyNG uses V2Fly, but Android VPN capture, app exclusions, and DNS behavior still depend on the client configuration. Don't copy desktop JSON directly into Android client settings.

5. How to Configure FakeDNS: Restore the Domain on the Same Traffic Path

FakeDNS returns a mapped address from an address pool, not the website's real IP. When the app connects to that address, the core restores the original domain from the mapping, then applies domain-based routing and connects through the proxy. This can avoid looking up the real IP in advance, but FakeDNS is not encrypted DNS and does not, by itself, prevent leaks. Node bootstrap lookups, direct destinations, and DNS requests from uncontrolled apps still need separate handling.

The following is an example snippet for an Xray core that supports this feature. 198.18.0.0/15 is a benchmarking address range commonly used for this type of mapping, not a real website address. Check for conflicts with your local network, other VPNs, or existing routes before using it. poolSize sets the mapping pool capacity; it does not indicate speed or concurrent connection capacity.

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

The inbound that handles subsequent connections must also be able to restore FakeDNS domains. For example, configure the sniffing fields below on that inbound. Merge them into an existing inbound object; don't use them as a standalone inbound. This demonstrates mapping and restoration only—it does not include DNS traffic capture, node bootstrap lookups, or exceptions for direct domains.

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["fakedns"],
    "metadataOnly": true
  }
}

• The address pool must be captured. After an app receives a mapped address, its connection must not leave directly through the physical adapter; otherwise, it will try to reach a nonexistent public destination.
• Keep mapping and connection on the same path. Don't have one independent instance create a mapping and then send the connection to another instance that has no record of it.
• Direct traffic still needs real DNS resolution. After the domain is restored, a direct outbound may still need to look up the real IP. That lookup must follow your direct DNS policy too.
• Clear caches after restarting. A core restart may discard old mappings while the app still has the old address cached. Clear the system and app caches, then run a fresh lookup to avoid mistaking an expired mapping for a node failure.

6. Common DNS Errors: Identify Which Layer Failed First

The following are error snippets you may see in logs. Exact wording and prefixes vary by core version, and a single error only points you in a direction. For each test, change one setting at a time and note whether the error came from connecting to the node, the remote resolver, or the destination website.

7. Retesting FAQs: A Working Browser Doesn't Prove the Whole Device Is Covered

A complete validation should confirm the whole chain: proxy-routed domains use a controlled DNS path, connections to the remote resolver use the expected outbound, direct domains resolve according to policy, node addresses can be bootstrapped independently, and TUN and IPv6 coverage are understood. To review the basic setup, see the subscription import guide, DNS configuration guide, and TUN mode guide.