This guide is for users who are connected to v2rayN but still see their local ISP's DNS in test results. Using v2rayN 7.13.3 and the Xray core as examples, it covers baseline testing, browser checks, nslookup comparisons, log verification, and TUN leak prevention, while explaining which results indicate a real leak and which may be caused by browser Secure DNS or caching.
Start by defining what counts as a DNS leak
DNS translates domain names into IP addresses. When an app accesses a domain that is not cached, it usually sends a DNS query first and then connects to the returned address. A working proxy does not mean DNS requests are going through it: system proxy settings mainly handle traffic from apps that support HTTP or SOCKS, while the Windows DNS Client may continue sending UDP 53 queries to the DNS server configured on the active network adapter.
You cannot determine a leak by simply counting the servers shown on a test page. First record the DNS providers, cities, and server count with the proxy disabled, then enable v2rayN and repeat the test. If the same ISP and region consistently appear after enabling the proxy, and the logs confirm that queries never entered Xray, there is sufficient evidence to treat the issue as a leak.
Browser Secure DNS can also change test results. A browser may send HTTPS queries directly to its chosen DoH service, so the DNS servers shown by the test page may come from neither the system DNS nor v2rayN. During troubleshooting, open the browser's “Settings” → “Privacy and security” → “Security” → “Use secure DNS” and record the current setting. For a consistent baseline, temporarily disable it, then restore the original setting after testing.
Conclusion: Establish a direct baseline before judging a leak
A single result with the proxy enabled is easy to misread. Run two tests with a direct connection and two with the proxy. If the same ISP resolver appears throughout all four rounds, continue checking the system DNS path.
Method 1: Run two comparison rounds with a browser DNS leak test
Exit all other proxy tools and keep only v2rayN running. Open the v2rayN main window, confirm that the current server is selected at the bottom, and set the system proxy to “Automatically configure system proxy.” Browser tests are useful for quickly spotting a clear mismatch between the apparent exit location and DNS location, but they cannot prove which process sent a particular query.
Clear old caches
Close all browser windows, run
ipconfig /flushdnsin an elevated terminal, and reopen the browser after seeing “Successfully flushed the DNS Resolver Cache.”Record the direct baseline
In v2rayN, set the system proxy to “Clear system proxy,” visit dnsleaktest.com, run the Standard test, and record the server names, countries or regions, and result count.
Enable the system proxy
Return to v2rayN, select “Automatically configure system proxy,” confirm that the latency test succeeds, then open a new private browser window to keep old connections and DNS cache from affecting the results.
Repeat the test twice
Run two consecutive Standard tests, about 30 seconds apart. If the proxy exit location has changed but DNS still shows an ISP name from the direct baseline, continue with command-line testing.
A test page may list several public resolver nodes. Public DNS commonly uses Anycast, so one service may be routed to different cities; a mismatch between the DNS city and proxy exit city does not by itself prove a leak. Focus on whether the provider belongs to a local broadband or mobile network, and whether the servers seen with the proxy disabled remain unchanged.
If the problem appears in only one browser while other browsers produce normal results, check that browser's Secure DNS, extensions, and background connections first. Do not immediately change v2rayN's global configuration, or you may mistake the browser's own DNS behavior for a core-level problem.
Conclusion: A different exit location is not conclusive evidence
A more reliable judgment combines three conditions: the provider matches the direct baseline, repeated tests reproduce the result, and the query never entered Xray. This is more dependable than comparing map locations alone.
Method 2: Use nslookup to distinguish system DNS from proxy DNS
nslookup normally calls the DNS server configured by the system. It does not automatically use a proxy just because a standard HTTP system proxy is enabled. Therefore, when only “Automatically configure system proxy” is enabled, seeing a router address or ISP DNS is expected; it shows that ordinary proxying has not taken over system-level UDP 53.
Open Windows Terminal and first run a query without specifying a server. The Server and Address values at the top identify the current system resolver. Common addresses include a home router such as 192.168.1.1, a LAN gateway, or DNS supplied by the network adapter. Then specify a resolver and run the query again to check whether the local network permits that path.
ipconfig /flushdns
nslookup example.com
nslookup example.com 1.1.1.1
nslookup -type=AAAA example.com- Default query shows the router address: The LAN gateway is still handling system DNS; the standard system proxy has not taken over the request.
- Query to a specified server times out: UDP 53 may be restricted by the network, or a firewall may be blocking terminal requests; this does not prove that the proxy node is faulty.
- A records work but AAAA times out: Check local IPv6 availability and v2rayN's query strategy instead of changing only the IPv4 DNS.
- Results do not change for a short time: Windows, the browser, or the Xray core may be using a cache. Flush the caches and retest with a domain you have not accessed before.
To verify whether TUN is taking over system queries, enable TUN first and run the default nslookup again. Do not rely only on the Server field, which may still show the original adapter address. Also open the v2rayN logs and confirm that the UDP 53 request entered the TUN inbound, matched a DNS rule, and was sent through the expected outbound.
A standard system proxy does not cover every UDP query. For system-wide interception, use TUN and confirm the actual path through the inbound tag, destination port, and outbound tag shown in the logs.
Method 3: Confirm the path in v2rayN and Xray logs
Logs answer two key questions: did the query enter the core, and which outbound handled it? Open v2rayN's “Settings” → “Parameter settings” → “Basic settings,” temporarily set the log level to info, save, restart the core, then open “Help” → “View logs.” Menu text may appear as “Logs” or “View runtime logs” in different minor versions, but the output should be the live log from the current Xray instance.
Restart the core
In the main window, select “Server” → “Restart service” so the updated DNS and log level are included in the current generated configuration.
Generate a new query
Run
ipconfig /flushdns, then visit a domain you have not opened before so caching does not prevent a query from appearing in the logs.Search for the port
Search the logs for
:53,udp,dns, and the target domain. Check whether the request came from the TUN inbound or an application proxy inbound.Check the outbound
Confirm that outbound or detour in the logs points to the expected proxy tag. If it hits direct, return to the routing settings and check the rules for the DNS server's IP address and port.
In system proxy mode, when a browser sends a domain name through a SOCKS or HTTP inbound, Xray can resolve it inside the core. But if an app resolves the name locally first and passes the IP address to the proxy, the logs will show only the destination IP and cannot recover the original domain from the proxy request. TUN mode covers more system traffic, but DNS hijacking and routing must still be configured correctly; otherwise UDP 53 may bypass them and connect directly.
Error: failed to find an available destination
Cause and fix: The node address or target domain could not be resolved. Check the server address for typos, switch to an available DNS server, select “Server” → “Restart service,” and test again.
Error: lookup server.example: no such host
Cause and fix: The current resolver returned no record for the node domain, or a failed result is still cached. Flush the system DNS cache, check reachability of the remote DNS, and make sure the node domain is not routed to an unavailable resolver.
Error: failed to start tun device
Cause and fix: The TUN adapter was not created successfully, so system queries cannot enter TUN as expected. Exit other programs using virtual adapters, restart v2rayN with administrator privileges, and check the TUN status.
Configure remote DNS and DNS outbound in system proxy mode
If you mainly use browsers and desktop apps that explicitly support proxies, system proxy mode may be sufficient. Open v2rayN “Settings” → “DNS settings” and select the DNS configuration page for Xray. Domains in mainland China and domains outside mainland China can use separate resolvers, but remote DNS servers must satisfy both reachability and routing requirements; do not enter an address without checking how its traffic will travel.
When remote DNS uses DoH, it normally creates an HTTPS connection over TCP 443, which is easier to include in proxy routing than raw UDP 53. After configuring it, check how the remote DNS hostname itself is resolved initially. If it must first use local DNS to obtain an address, a bootstrap dependency is created. Use a stable, reachable bootstrap resolver, or route the relevant DNS server addresses through an explicit outbound rule.
- Query strategy: If IPv6 is unavailable on the network, choose an IPv4-preferred strategy to avoid AAAA timeouts delaying the first connection. For dual-stack networks, keep both A and AAAA queries and verify them separately.
- Domain strategy: When routing relies on
geositerules, preserve domain information where possible instead of matching only the resolved IP too early. - DNS outbound: The built-in
dns-outsends matched DNS traffic to the core's DNS module; it is not an alias for an arbitrary public DNS address. - Port rules: For traditional queries, match UDP/TCP 53. DoH is HTTPS traffic, so decide whether it should use the proxy or connect directly based on the target domain, target IP, and port 443.
Open “Settings” → “Routing settings” and check for any high-priority rule that forces DNS server IPs to direct. If remote DNS is intended to use the proxy, such a rule conflicts with that design. Rules are matched in the order defined by the current core and generated configuration. Restart the service after changes and confirm the final outbound tag in the logs.
First confirm that the remote DNS server itself is reachable, then check whether DNS queries enter the core, and finally check whether the connection to the DNS server uses the proxy or goes direct. Change one setting at a time so you can identify which rule changed the result.
Use TUN mode to intercept system-level DNS requests
Game launchers, command-line tools, and some desktop programs do not follow the HTTP system proxy. To cover them, enable “Tun mode” in the v2rayN main window, then open “Settings” → “Parameter settings” → “Tun mode settings.” With v2rayN 7.13.3 as an example, check the TUN implementation, strict routing, MTU, and DNS interception options, then save and fully restart the core.
Disable conflicting adapters
Exit other network programs that create virtual adapters to prevent conflicts among the default route, interface metrics, and DNS interception rules.
Enable strict routing
Open “Settings” → “Parameter settings” → “Tun mode settings” and enable strict routing. This makes managed traffic follow the TUN routing table and reduces the chance that queries bypass it through the physical adapter.
Check the MTU
Start with the default value. If some pages fail to load, reduce it from 1500 to 1400 and test again. MTU affects packet delivery and should not be the first setting changed when troubleshooting DNS leaks.
Recreate the TUN interface
Turn “Tun mode” off and on again, confirm that the status area shows no startup error, and verify that the current virtual interface appears in the Windows network adapter list.
Verify UDP 53
Run a new
nslookupquery and confirm in the live logs that UDP 53 entered the TUN inbound and matched a DNS handling rule.
If nothing resolves after enabling TUN, do not immediately keep switching nodes. Check that the firewall allows v2rayN and Xray to access the network, confirm that the virtual interface has a valid route, and determine from the logs whether the problem is a query timeout, a rejected rule, or a TUN startup failure. If the node IP is reachable but its hostname is not, focus on the bootstrap DNS.
If the browser works in TUN mode but nslookup times out, DNS hijacking may cover only some protocols, or strict routing may be blocking the query. Test UDP 53, TCP 53, and DoH 443 separately, and confirm that DNS rules come before ordinary direct-connection rules. After making changes, run two more browser test rounds; do not rely only on the displayed TUN status.
Error: context deadline exceeded
Cause and fix: The DNS request entered the core but received no response before the timeout. Check the proxy outbound for remote DNS, connectivity to port 443, and bootstrap resolution, then compare with a server whose reachability has already been confirmed.
Error: operation was canceled
Cause and fix: A core restart, configuration change, or interrupted upstream connection canceled the query. Wait for the TUN status to stabilize, clear the caches, and retry. Check that the logs do not immediately show another startup error.
Use the results to locate cache, IPv6, and rule conflicts
If results do not change immediately after modifying DNS, caching is the most common cause. Windows DNS Client, the browser, the Xray core, and upstream resolvers all maintain separate caches. Close the browser, run ipconfig /flushdns, restart the v2rayN core, and test with a domain you have not visited. Reloading the page alone usually does not trigger a new DNS query.
IPv6 needs separate testing as well. The system may connect to the proxy over IPv4 while continuing to send AAAA queries through the physical adapter, or it may receive an IPv6 address and then time out because the current network lacks a complete IPv6 route. Use nslookup -type=AAAA alongside the logs to confirm whether the query was intercepted and whether the returned address is reachable.
- Only the browser is affected: Check Secure DNS and the browser cache before changing global routing.
- nslookup shows local DNS and the logs are empty: The standard system proxy has not intercepted system queries; check TUN for system-wide coverage.
- The logs show a query hitting direct: Adjust the routing priority for the DNS server's domain, IP, and port.
- The logs show a query using the proxy, but testing still looks wrong: Check whether the test page uses the browser's independent DoH, and compare with another browser.
- Everything times out after enabling TUN: Check the virtual adapter, firewall, strict routing, and bootstrap DNS. Do not use node latency as the only indicator.
Final verification should cover three points: browser tests no longer repeatedly show the ISP resolver from the direct baseline; a new nslookup query can be traced in the logs under TUN; and the Xray logs show DNS traffic reaching the expected outbound. Once all three agree, restore the temporarily elevated log level to limit long-term log volume.
Conclusion: Verify the complete request path
The test page reveals symptoms, nslookup distinguishes system resolution, and logs confirm the inbound and outbound path. Only by cross-checking all three methods can you determine whether the settings truly cover the target application.