A proxy client showing a successful connection only proves that the node handshake and some outbound traffic are working. It does not prove that DNS queries are using the same proxy route. Before a browser opens a website, the domain usually has to be resolved to an IP address. If that step is still handled by the local network, router, or ISP DNS, the website traffic may pass through the proxy while requests revealing which domains were queried take a different path.
Troubleshooting a DNS leak means looking beyond which country or region appears on a test page, and not treating every local resolver as abnormal. Check how application traffic is captured, along with system DNS, browser Secure DNS, the client’s remote DNS, and routing rules. Then compare results before and after the changes to determine whether the traffic paths have actually converged.
This guide is for users who can already connect to VMess or VLESS nodes but still see local resolvers in DNS tests, occasional DNS failures, or unexpected split-routing results. The process starts with a test baseline, covers v2rayN and v2rayNG separately, and uses logs, system commands, and repeated tests to verify the fix.
Where a DNS leak occurs
A typical web request includes several stages: the application requests a domain, DNS returns an address, the application connects to that address, and routing rules choose an outbound path. The system proxy mainly handles connections from applications that support HTTP or SOCKS proxies; UDP port 53 queries generated by the operating system do not necessarily enter the proxy automatically. Even if the Xray core is configured with remote DNS, the core may never see the query if the application calls the system resolver directly.
TUN mode uses a virtual network adapter to capture a broader range of IP traffic, including processes that ignore system proxy settings and DNS packets. On Android, v2rayNG usually provides similar interception through the system VPN interface. Capturing the traffic is only the first step: make sure DNS traffic on ports 53, 853, or 443 is not allowed through prematurely by direct-routing rules.
A browser’s built-in Secure DNS is another variable. The browser may bypass system DNS and send HTTPS requests directly to a specified DoH service; a test page will then show a different resolver. Whether this is a leak depends on whether that HTTPS connection ultimately uses a direct route or the proxy—not on whether the page shows a familiar DNS name.
Establish a repeatable DNS test baseline
Do not change the configuration immediately. Recording the pre-fix state lets you distinguish a real improvement from a cached test page. Use the same browser, network, and node for three rounds of testing. Close the test tab between rounds and wait about 30 seconds. A standard test gives a quick view of resolvers; an extended test generates more random-domain queries and is better at revealing both local and remote DNS being used at the same time.
-
Record the current mode
Record the client name, core type, node protocol, and capture mode. For example: v2rayN 7.x, Xray core, VLESS node, system proxy mode. Do not write only “proxy enabled.”
-
Temporarily close other network tools
Exit other running proxies, corporate network clients, and standalone DNS tools to prevent multiple virtual adapters or local listening ports from affecting the results.
-
Check browser DNS
In the browser’s privacy or security settings, record whether “Use Secure DNS” is enabled and which provider it uses. For the initial baseline, you can temporarily disable it to isolate the system and client paths.
-
Run an extended test
Open a trusted DNS leak test page, run both the standard and extended tests, and record resolver names, address counts, regions, and the time to the first query.
-
Compare after disconnecting
Disconnect the client, refresh the network connection, and test again. If the resolvers are exactly the same before and after connecting while the web exit address changes clearly, DNS is probably not following the proxy route.
On Windows, system commands can help confirm the DNS addresses assigned to the current network adapters. This only shows where the system is prepared to send queries; it does not prove which outbound path the packets ultimately use. It is still useful for finding router addresses, old virtual adapters, and manually configured resolvers.
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName example.com
ipconfig /flushdnsIf the list includes a physical adapter, a virtual adapter, and an old disconnected adapter, first focus on the adapter with the active default route. After changing settings, clear the cache and resolve a new random domain. Repeatedly querying the same domain may hit the system, browser, or client cache and never generate a new external request.
Error: DNS request timed out.
Cause and fix: The configured DNS server is unreachable, or the current network is blocking port 53. Restore an accessible resolver first, then check whether TUN routing is capturing DNS.
Error: server failed
Cause and fix: The resolver returned SERVFAIL, commonly because of an upstream outage, domain validation failure, or an incorrect forwarding configuration. Switch to another remote DNS service, clear the cache, and test again.
v2rayN fix path: handle system proxy and TUN separately
When v2rayN uses the system proxy, browser HTTP/HTTPS requests usually enter the local proxy port, while Windows DNS may still go directly to the resolver configured on the network adapter. A common local port pair is SOCKS 10808 and HTTP 10809; use the values shown under “Settings” → “Parameter settings” for the actual ports. A listening port does not mean UDP 53 is being captured.
If the goal is only to make proxy-aware browsers use a specific DNS path, adjust the browser’s Secure DNS settings as well and confirm that its DoH requests go through the proxy. To cover more desktop applications, command-line tools, and system DNS queries, use TUN and check DNS interception and routing rules. The two approaches have different coverage, so system-proxy results should not be treated as equivalent to TUN results.
-
Confirm the core type
Go to “Settings” → “Parameter settings” → “Core type” and confirm that the selected core is compatible with the node protocol. Restart the client after changing the core so an older process does not continue using the previous configuration.
-
Set a remote DNS service
Open “Settings” → “DNS settings” and enter a specific DNS service under Remote DNS. For a single-variable test, start with 1.1.1.1 or 8.8.8.8. Once the setup is stable, adjust it for your network environment.
-
Enable TUN capture
Enable TUN mode on the main screen and grant the system permissions required to create a virtual network adapter. After enabling it, confirm that the virtual adapter exists and that another network tool has not replaced the default route.
-
Check DNS split routing
Review rules for DNS server addresses, UDP 53, TCP 853, and the DoH domain in use. Queries expected to use the proxy must not be matched first by a “LAN direct” rule or an overly broad IP rule.
-
Clear the cache and restart
Close the browser, run
ipconfig /flushdns, restart the v2rayN core, and then reopen the test page. Use a new random domain to trigger a query instead of reading an old cached result.
The Xray DNS module can resolve domain names for routing decisions and forward queries to a specified upstream, but it does not automatically capture every system request. DNS settings can take effect only after the request enters the core. If the logs show target connections but no corresponding DNS queries, check the capture mode first rather than repeatedly changing the upstream address.
Error: failed to lookup ip
Cause and fix: The core could not obtain the node or target address from the current DNS configuration. Check the server address spelling, remote DNS reachability, and DNS outbound rules, then restart the core.
Error: no such host
Cause and fix: The domain returned a nonexistent result, or a failed result remains in the local cache. Confirm that the server domain in the subscription is complete, clear the system DNS cache, and test again with another remote resolver.
Error: context deadline exceeded
Cause and fix: The upstream DNS service did not respond before the timeout, often because a direct rule is blocking the DoH connection. Check outbound traffic on port 443 and the domain rules; if necessary, switch temporarily to regular remote DNS to isolate the issue.
v2rayNG fix path: coordinate VPN capture with Private DNS
When v2rayNG captures traffic through the system VPN interface, DNS is generally more likely to enter the tunnel than with a desktop system proxy, but it can still be affected by Private DNS, per-app proxy settings, LAN bypass, and routing rules. With the Xray core in v2rayNG, remote DNS, domain strategies, and FakeDNS are separate settings. When troubleshooting leaks, establish a stable baseline with regular remote DNS first, then decide whether FakeDNS is needed.
Android Private DNS typically uses DoT over TCP 853. If a hostname is configured, the system will continue trying to connect to that service. Whether the connection uses the current node depends on VPN coverage and split-routing rules. To isolate variables, set “Settings” → “Network & internet” → “Private DNS” to “Automatic” or “Off” during the initial check, then restore each setting after validating v2rayNG.
-
Check the running mode
Confirm that v2rayNG shows an active VPN connection and that the system VPN indicator appears in the status bar. Changing the configuration without starting the connection will not make remote DNS capture requests from other applications.
-
Enter a remote DNS service
Open the top-left menu and go to “Settings” → “Remote DNS,” then enter a clearly reachable resolver. During testing, do not enter several upstreams with unknown behavior at once; otherwise the result will be difficult to attribute.
-
Check local DNS
In “Settings,” check “Local DNS” and “Enable local DNS.” Local DNS mainly handles the client-side query entry point, while Remote DNS determines the upstream path after the query enters the core. They are separate settings.
-
Disable per-app bypass
During troubleshooting, temporarily disable per-app proxy rules, or make sure the browser and test tool are included in the proxy list. Excluded apps use the physical network directly, so their results will naturally differ from the node’s exit.
-
Reconnect and retest
Stop the connection, wait about 10 seconds, and start it again. Force-close and reopen the browser, run two rounds of extended testing, and compare the results recorded separately on mobile and Wi-Fi networks.
v2rayNG and v2flyNG use different core implementations, and setting names and available features may change between versions. The Xray DNS configuration from v2rayNG cannot be copied unchanged as a v2fly core configuration for v2flyNG. Migrating a subscription imports node information only; it does not copy the device’s DNS, routing, or per-app settings. Establish a new baseline after switching clients.
Error: Unable to resolve host
Cause and fix: The application or core did not receive a domain result. Confirm that the VPN is connected, then check remote DNS, Android Private DNS, and whether the current network is blocking the relevant port.
Error: network is unreachable
Cause and fix: DNS traffic was routed to an unavailable interface, often because an old VPN route was not refreshed after switching Wi-Fi networks. Stop v2rayNG, switch networks once, and reconnect.
What a successful retest looks like
A successful fix does not require the test page to show only one address. Public DNS services may use anycast and return multiple endpoints for the same service across queries; some test pages also show the resolver frontend separately from the recursive nodes. A more reliable standard is that, after connecting the client, the results no longer include the home router, the current network operator, or any clearly unexpected local resolver—and that the results remain consistent after restarting the client, browser, and device.
Split routing must also be verified. If domains in mainland China connect directly while other domains use the proxy, DNS may likewise use different upstreams by domain group. That is an intended result, not a reason to demand a single resolver everywhere. The key is for each group’s queries to match its corresponding outbound route, without first using local DNS to obtain network-influenced addresses and then handing the connection to the proxy.
Why did the DNS results stay the same after the exit address changed?
The system proxy captured only web connections, while system DNS continued through the physical network adapter. In v2rayN, switch to TUN and check the DNS routes; then clear the cache and test again.
Is it normal for the test page to show two remote resolvers?
It can be normal. Confirm that both belong to the selected upstream or its recursive nodes, then repeat three rounds of testing. If one remains fixed after disconnecting the proxy, check the local network configuration.
Will enabling FakeDNS always solve the problem?
Not necessarily. FakeDNS stores domain mappings against synthetic addresses and works well with TUN and domain-based routing, but it does not fix queries that were never captured. First confirm that DNS packets are entering the core.
Do I need to test again after switching nodes?
Yes. Different nodes may use different routes, exit regions, and DNS upstreams. Run at least one standard test; if the resolver changes unexpectedly, run an extended test as well.
What if websites work but subscription updates fail?
The subscription updater may use a separate network path. Check whether subscription settings allow updates through the proxy, and look in the core logs for DNS resolution timeouts or connection timeouts.
Final acceptance checklist
- After restarting the client, the node connects normally, and VMess or VLESS handshake logs show no persistent DNS errors.
- Neither the standard nor extended test shows the current home router or an unexpected network-operator resolver.
- On Windows, the physical adapter, TUN virtual adapter, and old virtual adapters have no conflicting default routes.
- Android Private DNS, per-app proxy rules, and v2rayNG Remote DNS settings match the intended traffic-capture scope.
- The browser Secure DNS setting has been recorded, and after restoring it, its HTTPS requests are confirmed to use the expected outbound route.
- After switching nodes, Wi-Fi, and mobile networks, run at least one retest for each; the results must not revert to the local DNS path.
If retests remain unstable, check in this order: whether the application is captured, whether DNS requests enter the core, whether the upstream is reachable, whether the routing rule matches, and whether the cache was cleared. Do not change TUN, DNS, routing, and browser settings all at once. Change one variable per test and save the result so you can identify the setting that actually affects the route.