This guide is for users who can connect to a node but still see their local ISP's DNS on a test page. First establish a direct-connection baseline, then check browser Secure DNS, system caching, and client routing. Adjust DNS and traffic interception in v2rayN, v2rayNG, or v2flyNG, then run three rounds of tests to confirm the query path.
How to identify a DNS leak
DNS translates domain names into IP addresses that can be reached. When a browser opens a website, it typically performs a DNS lookup first and then connects to the returned address. A proxy node can forward web traffic without ensuring that system DNS queries use the same path; different components handle them, so web traffic and DNS may take separate direct or proxied routes.
A DNS leak does not simply mean that a test page shows multiple resolvers. It means a query that should use a designated resolver or proxy path bypasses the expected channel. A common sign is that the web exit address has changed while the DNS test still shows the current ISP's resolver, a resolver supplied by the router, or resolution completed directly through port 53 on the local network.
| Test result | Possible cause | What to check |
|---|---|---|
| The exit address changed, but the resolver still belongs to the local ISP | System DNS or UDP 53 is not being intercepted by the client | Check TUN, the VPN service, and local DNS switches |
| Different browsers show different resolvers | One browser has its own Secure DNS enabled | Standardize browser settings and establish a new baseline |
| The router address appears intermittently in test results | A system fallback, cache, or network change triggered an alternate lookup | Clear the cache and run three consecutive tests |
| Only resolvers on the proxy service side appear | The domain query is handled remotely or by the designated resolver | Continue checking whether routing matches the rules |
Conclusion: define the expected path before judging a leak
The key is not the number of resolvers, but who they belong to and which path the queries take. Office networks, home routers, and browser Secure DNS can produce different results. State which resolvers you expect to use before testing so the results can be evaluated.
How to run an online test and establish a local baseline
Before changing any settings, run one test with the client fully disconnected and another after connecting to a node. Use the same browser, network, and test mode each time so browser differences are not mistaken for client problems. Choose a DNS test page that supports standard and extended tests; extended tests usually query more random subdomains and are better at exposing fallback resolvers.
Record the direct-connection result
Exit v2rayN or stop the Android VPN service, disable browser Secure DNS, and run one extended test. Record the exit network, resolver count, and resolver network ownership; there is no need to save temporary test domains.
Connect to the target node
Select a working configuration in the client. In v2rayN, enable the system proxy or TUN mode. In v2rayNG or v2flyNG, tap Connect and confirm that the system status bar shows the VPN service is running.
Clear old caches
On desktop, flush the DNS cache, then fully close and reopen the browser. On Android, disconnect and reconnect the client first; if the browser still reuses old results, terminate the browser process.
Run three consecutive tests
Leave at least 30 seconds between rounds and reload the test page each time. Seeing only the expected resolvers in all three rounds is more reliable than a single result for ruling out caching, fallback DNS, and brief network changes.
Compare the exit-address change
If the web exit address has not changed, fix proxy interception first. If it has changed but the resolvers still match the direct baseline, investigate the client's DNS settings.
Windows local diagnostic commands
Use the commands below to view the system's current DNS, clear the cache, and check whether a local process is listening on port 53. They cannot prove the outbound query path on their own, but they can reveal incorrect adapter settings and port conflicts.
ipconfig /all
ipconfig /flushdns
nslookup example.com
powershell -NoProfile -Command "Get-NetUDPEndpoint -LocalPort 53 -ErrorAction SilentlyContinue"Preventing DNS leaks in v2rayN on desktop
These steps use v2rayN 7.x with Xray Core as the reference setup. Minor releases may move labels, but the troubleshooting logic stays the same: confirm the Core type, configure DNS, then choose between the system proxy and TUN. The system proxy mainly handles apps that support HTTP or SOCKS proxies and usually does not capture every UDP 53 query. For broader system coverage, check TUN first.
Confirm the core
Open “Settings” → “Parameter Settings” → “Core Type” and confirm that the current configuration uses Xray. Save and restart the core so an old process does not keep using a previously generated configuration.
Configure DNS
Go to “Settings” → “DNS Settings” → “Xray DNS”. Start with the basic template supplied with your version, then configure direct DNS and proxy DNS according to your routing needs. Domains routed directly should use a resolver reachable from the local network; proxied domains should use a resolver reachable through the proxy.
Check routing
Review the current rules under “Settings” → “Routing Settings”. If a domain is resolved to an IP first, subsequent traffic may match only IP rules. When routing by domain, make sure the query strategy and routing rules work together; changing only the DNS address is not enough.
Enable TUN
To handle programs that ignore the system proxy, open “Settings” → “Parameter Settings” → “Tun Mode Settings”, check DNS hijacking and automatic routing, then enable TUN from the main interface. After first enabling it, follow the system prompts to grant any required permissions.
Restart and retest
Stop the old core, run
ipconfig /flushdns, and restart v2rayN. Open a regular webpage to confirm connectivity, then run three rounds of extended DNS tests.
System proxy vs. TUN
- System proxy: Best for browsers and desktop apps that actively read system proxy settings. If an app sends DNS packets directly, those queries may still leave through the physical network adapter.
- TUN mode: Uses a virtual network adapter to capture a broader range of IP traffic, making it suitable for UDP, standalone updaters, and apps that do not read system proxy settings.
- Using both: After switching modes, check that an old manual proxy still points to the correct local port. Common v2rayN ports are HTTP 10809 and SOCKS 10808; use “Settings” → “Parameter Settings” to confirm the actual local listening configuration.
- Routing comes first: DNS servers are also subject to routing rules. If a DNS server is mistakenly assigned to a blocked outbound, websites will usually fail to resolve altogether rather than merely producing an unusual test result.
Error:failed to find an available destination
Cause and fix:The outbound server domain cannot be resolved, or all available addresses were excluded by routing rules. Check the node address and system time first, then restore the basic DNS template and restart the core.
Error:lookup server.example: no such host
Cause and fix:The current resolver returned no result for the node domain, or the query was sent to an unavailable outbound. Temporarily route the node server domain through direct DNS, confirm that the node connects, and then restore your routing rules.
Error:bind: Only one usage of each socket address is normally permitted
Cause and fix:A local DNS or proxy port is already in use by another process. Use a port-checking command to identify it, stop the conflicting service, or change the listening port under “Settings” → “Parameter Settings” and update any dependent settings.
Android settings for v2rayNG and v2flyNG
Android clients typically use the system VPN service to capture traffic. Whether DNS passes through the client depends on local DNS, virtual DNS, and routing settings. v2rayNG uses the Xray core, while v2flyNG uses the v2fly core, so setting names and available options may differ. Do not copy advanced JSON from one client to the other; start with the current version's built-in DNS options and establish a working baseline.
Update the client
First, make sure you are using the stable version offered on the current download page. After upgrading, reopen the app so it can migrate the configuration, then select a node that has already been verified to connect.
Enable local DNS
In v2rayNG, open “Settings” → “Local DNS”, enable the option that lets the client handle DNS, and check that its listening port does not conflict with another local service. Common DNS listening ports are 53 or a high-numbered port assigned by the client; follow the value shown in the interface.
Check virtual DNS
Open “Settings” → “VPN Settings” and review FakeDNS or the corresponding virtual DNS option. Enable it when routing by domain is required and ordinary resolution would expose the target domain too early. If LAN devices or individual apps stop connecting, disable it temporarily for comparison.
Confirm per-app rules
If per-app proxying is enabled, confirm that the browser used for testing is included in the proxy scope. If the browser is excluded, both its web requests and DNS queries will use the direct path.
Disconnect and reconnect
After saving the settings, do not simply return to the home screen. Stop the current connection, wait 5 seconds, and reconnect. Then terminate the browser process, reopen the test page, and run three rounds of tests.
| Setting | v2rayNG | v2flyNG |
|---|---|---|
| Primary core | Xray | v2fly |
| Traffic interception | System VPN service | System VPN service |
| Check first | Local DNS, FakeDNS, per-app proxying | Local DNS, routing rules, per-app proxying |
| After changing settings | Stop the connection and restart the service | Stop the connection and restart the service |
Conclusion: intercept queries before choosing resolvers
Replacing one public DNS resolver with another cannot fix queries that bypass the client. On Android, first confirm that the test browser is covered by the VPN and per-app proxy rules, then adjust local DNS, FakeDNS, and routing rules.
How to diagnose a failed retest
If local resolvers still appear after configuration, do not keep switching nodes and DNS addresses. Change one variable at a time: keep the node and browser fixed, then check browser Secure DNS, the client's interception mode, system cache, and routing rules separately. When several variables change together, even a temporarily normal result cannot show which change worked.
Symptom: the exit address changed, but all three rounds show the local ISP's DNS
Cause and fix:Web traffic is proxied, but DNS is still sent through the system adapter. On desktop, switch to and verify TUN. On Android, check local DNS, the VPN service, and the per-app proxy scope.
Symptom: the first round is normal, but an extra resolver appears in the second
Cause and fix:There may be a fallback DNS, browser Secure DNS, or a network change. Keep the network fixed, disable the browser's independent DNS feature, clear the cache, and run three tests 30 seconds apart.
Symptom: LAN domains stop working after enabling FakeDNS
Cause and fix:LAN domains are being resolved virtually instead of being sent to local DNS. Add direct rules for LAN domains and private addresses, or temporarily disable FakeDNS to compare the results.
Symptom: every website fails to resolve after changing DNS
Cause and fix:The resolver is unreachable, the DNS outbound is blocked, or the configuration format is unsupported by the current core. Restore the client's built-in template, confirm basic connectivity, and then add custom rules one at a time.
What a useful retest record should include
- The client name, version series, and core type—for example, v2rayN 7.x with Xray—not merely “V2Ray connected.”
- Whether traffic was intercepted with the system proxy, TUN, or the Android VPN service.
- Whether the test browser had independent Secure DNS enabled and whether it was included in the per-app proxy scope.
- How resolver ownership changed between the direct baseline and the connected result, and whether all three rounds matched.
- The test time, current network type, and whether Wi-Fi changed, so changes in the network environment can be ruled out.
Does detecting two resolvers mean there is a leak?
Not necessarily. One DNS service may use multiple egress addresses, and load balancing can return resolvers from different regions. First check whether ownership matches expectations, then see whether any ISP resolver from the direct baseline has appeared.
Why did the DNS results stay the same after switching nodes?
DNS may be handled by a fixed resolver selected in the client and therefore remain unchanged when the node changes. As long as queries do not bypass the expected path, an unchanged resolver is normal.
Do I need TUN when the system proxy is enabled?
For browsers and other programs that follow the system proxy, start with the system proxy. Enable TUN when you need to cover games, standalone updaters, or programs that send UDP queries directly, and then check the DNS hijacking settings.
Should browser Secure DNS stay disabled?
Disable it during troubleshooting so the client's handling path can be verified. You can re-enable it afterward, but run three more tests to confirm that the browser's chosen resolver and proxy policy match expectations.
Can a failed subscription update also be caused by DNS?
Yes, it can. If the subscription server domain cannot be resolved, the update will time out. First let the subscription update use an available proxy, or resolve that domain through direct DNS, then check lookup and timeout entries in the core log.