V2Ray DNS Leak Test: How to Prevent DNS Leaks in v2rayN

1. How to Identify a DNS Leak: Separate DNS Queries from Connections

DNS translates domain names into IP addresses. Routing web connections through a proxy does not mean the preceding DNS queries also use the proxy. For example, an app might query the router at 192.168.1.1:53, then send the returned IP address to a local proxy. The page loads, but the DNS query has already gone through the local network. This split path is what you need to investigate.

Online DNS leak tests typically have your browser visit a set of randomly generated subdomains, then ask the test provider's authoritative DNS server to observe which resolver makes the recursive query. The results usually show the recursive resolver or its exit point, not every packet sent by your computer's network adapter. A resolver appearing in a different country from your proxy exit does not, by itself, prove a leak.

• Worth investigating: A domain that should use the proxy is consistently resolved by your local ISP, or a packet capture shows related unencrypted queries leaving directly through the physical network adapter.
• Not necessarily a problem: Public DNS services use anycast, so a test may place a resolver in another region; one service may also show multiple resolver exit points.
• Routing exceptions: Local network names and domains explicitly set to bypass the proxy may be resolved locally by design. First define which domains must use remote DNS.

2. Online DNS Leak Tests: Run Three Reproducible Comparisons

Open dnsleaktest.com in your browser. Run the Standard test first, then check again with the Extended test. The test page receives network information related to the test, so don't enter subscription links, node credentials, or internal work domains. The steps below are a logging template, not results from tests conducted for this guide.

1. Record a baseline

   On a trusted network, first turn off “Enable TUN” in the main window, then select “System Proxy” → “Clear System Proxy.” Record the test results; note that this test sends traffic directly over your current network.

2. Keep variables constant

   Use the same working node and browser profile throughout. Note whether the browser's Secure DNS is enabled. Don't change the node, resolver, and routing rules at the same time during comparisons.

3. Clear the cache

   Run Clear-DnsClientCache in PowerShell as an administrator. Fully quit and reopen the browser to reduce interference from cached DNS records and reused connections.

4. Test in separate rounds

   Test the system proxy first, then TUN. Run two tests for each configuration and record the time and resolver IPs. Don't rely only on country labels or treat results from an old tab as a fresh test.

3. System Proxy vs. TUN: Different Capture Scopes

In v2rayN, “System Proxy” → “Auto Configure System Proxy” mainly affects apps that follow Windows proxy settings. It does not capture DNS system-wide. An app may ignore the system proxy or resolve a domain through Windows before connecting to a proxy port. Apps using SOCKS also need to be set to resolve domain names through the proxy; entering the correct proxy address alone isn't enough.

The paths in this guide refer to the common v2rayN 7.x desktop interface; labels may change in later versions. “Enable TUN” in the main window turns on virtual network adapter capture. The TUN implementation, DNS hijacking rules, and routing behavior depend on the core actually running. Using Xray for a node does not mean Xray also provides the TUN layer; check the startup logs to confirm.

• Before starting: Exit other networking tools that capture routes or DNS. Grant administrator permission if prompted by the client to avoid failures creating the virtual adapter or routes.
• After starting: Check the logs for permission errors, virtual adapter creation failures, or route conflicts. An enabled toggle confirms only the interface state, not that traffic is actually being captured.
• DNS capture: Check whether the current TUN configuration sends regular UDP/TCP port 53 queries to the core. Browser-initiated DoH uses HTTPS and cannot be identified automatically by capturing port 53.
• IPv6: If the physical network provides IPv6, confirm that IPv6 routes are captured too. Passing an IPv4-only test does not prove that dual-stack apps use the intended exit for all traffic.

4. Remote DNS: Configure Both the Resolver and Its Route

In v2rayN, open “Settings” → “DNS Settings” and first confirm that you're editing the configuration for the core in use. Xray and sing-box use different DNS configuration formats; don't paste an entire JSON block from one core into the other's settings. Custom configuration sections may also bypass some GUI options, so check the configuration actually generated and loaded.

For remote resolution, you can use a DoH address provided by the service, such as https://1.1.1.1/dns-query. DoH encrypts queries between the client and resolver, but does not ensure that the connection goes through a proxy. If your goal is for the DNS service to see the proxy exit IP, verify the route used by that HTTPS connection—not just that its URL starts with HTTPS.

If you're using Xray's built-in DNS in regular https:// mode, check the routing rules to see which exit the resolver connection uses. https+local:// is a local mode, not an alternative way to force traffic through a proxy. If you use a DoH endpoint specified as an IP address, make sure the service certificate covers that address. Don't fix connection errors by disabling certificate validation.

• Put an exact match for the remote DNS destination before any broad direct-connection rule that might override it. For the endpoint above, for example, check which outbound rule ultimately matches 1.1.1.1/32.
• Local domains can have their own resolution rules, but don't use local DNS as the default fallback for every unknown domain.
• If the node server is specified by domain name, keep the required bootstrap resolution and distinguish between the lookup used to connect to the node and queries for destination domains. A local lookup for the node does not mean all destination queries are leaking.

5. Traffic Sniffing: Recover Domain Names, Not a Substitute for DNS Capture

Look for traffic sniffing options under “Settings” → “Parameter Settings.” Labels may vary by version, such as “Enable Traffic Sniffing.” Sniffing can recover destination domains from visible information such as HTTP Host headers and TLS handshakes to help match routing rules. It cannot undo a query an app has already sent to a local resolver.

The following shows only sniffing fields in an Xray inbound, to explain what the settings mean. It is not a complete configuration file and cannot be pasted into sing-box DNS settings.

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["http", "tls"],
    "routeOnly": true
  }
}

• enabled: Turns on traffic sniffing for this inbound. App traffic must actually pass through it.
• destOverride: Specifies which protocols to sniff. A domain cannot be recovered from a connection if no domain information is visible.
• routeOnly: Uses the sniffed result for routing without replacing the original destination address with the sniffed domain. This is not a DNS encryption option.

Check the browser's Secure DNS setting separately. In Chrome, go to “Settings” → “Privacy and security” → “Security” and look for “Use secure DNS.” In Edge, search settings for “Secure DNS.” For troubleshooting, turn it off for one comparison test, then decide whether to enable it based on your final policy. Run the final checks with the settings you plan to keep; if you turn it back on after testing, test again.

6. Troubleshooting Logs and Command-Line Checks

An error in the core logs means a step failed; it doesn't necessarily mean a leak occurred. Check the destination, timestamp, and outbound tag to identify the problem. The examples below show common error snippets. Prefixes and suffixes may vary between core versions, so don't expect an exact match with the full log line.

To see which DNS addresses Windows is currently using, run the following commands in PowerShell. They show network adapter settings and test system resolution; they are not equivalent to testing a proxied browser. In particular, a query sent to a manually specified resolver may go directly to that address if TUN isn't capturing it.

Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClientServerAddress -AddressFamily IPv6
Clear-DnsClientCache
Resolve-DnsName example.com -Type A
Resolve-DnsName example.com -Type AAAA

Seeing the router's DNS address in the network adapter list doesn't by itself prove a leak, because TUN may intercept requests sent to it. Conversely, seeing a public DNS address doesn't prove that queries go through the proxy. For a packet capture, check the physical adapter for direct UDP/TCP port 53 and TCP port 853 traffic. You can't distinguish DoH over HTTPS from regular web traffic by port 443 alone; also check the destination address and core logs.

7. Final Checklist: Test Your Everyday Setup

After making changes, save the settings and restart the core if prompted by the client. If you changed TUN routes or the virtual adapter, toggle TUN off and on again. Final checks should cover more than one website: test after a restart, when switching networks, and over IPv6. A single test page shows only how that browser request behaved; it cannot guarantee the behavior of every background app.

• Browser: With your everyday Secure DNS settings, run the Extended test twice. Confirm that the public IP and resolvers match expectations, and that local ISP resolvers don't appear on test paths that should use remote DNS.
• System apps: Test the actual apps that need a proxy and confirm they follow the system proxy or are captured by TUN. A browser test passing doesn't mean every app is covered.
• Dual-stack network: Check A and AAAA resolution, and test IPv4 and IPv6 connections separately to make sure both are captured.
• Failure scenario: Temporarily disable the node and check whether a failed remote lookup falls back to a local query that violates your policy. Restore the node as soon as the test is complete.
• Restart recovery: Run the test again after restarting the client. After switching between Wi-Fi and wired networks, check that TUN routes and DNS capture are still working.

A reliable setup has three parts: app traffic enters through the intended interface, domain queries use the intended resolver, and resolver connections use the intended outbound route. TUN, DoH, and traffic sniffing each handle a different part of the process. Checking each one is more effective than repeatedly switching public DNS addresses, and makes it easier to verify the setup after client upgrades.