For users who have imported a node and can browse the web but aren't sure whether DNS queries bypass the proxy. First, distinguish the website's exit IP from the resolver and the actual query path. Then check desktop system proxy coverage and Android VPN coverage separately. Finally, cross-check with browser tests, client logs, and packet captures. This guide doesn't provide a generic JSON file that overwrites your existing configuration, which could break subscription-generated outbounds and routing.
1. What Counts as a DNS Leak?
DNS translates domain names into IP addresses. A website connection going through a proxy doesn't mean the DNS lookup did too: the browser, operating system, or client core may perform the lookup. In this guide, a leak means a domain lookup that was supposed to go through the proxy was instead sent over the local network or another unintended route. If your routing rules intentionally send domestic domains direct and use local DNS, that's split tunneling—not a failure just because a local resolver appears.
V2Ray and Xray are proxy cores. v2rayN is a desktop GUI client; v2rayNG is an Android client using the Xray core; v2flyNG uses the V2Fly core. DNS options in the interface are translated into runtime settings for the selected core. VMess and VLESS are proxy protocols; they don't determine how every app on your system resolves domains.
| What you see | What it tells you | What to check next |
|---|---|---|
| The website's exit IP has changed | This website connection used the corresponding exit | Whether the domain was resolved by the local network |
| The test page shows a public resolver | The test domain was ultimately queried recursively by that resolver | Whether the query reached the resolver through the proxy |
| The resolver is in a different country from the node | The resolver and website exit are in different locations | Whether anycast routing or different egress locations are involved |
| UDP 53 traffic appears on the physical network adapter | Unencrypted DNS queries are leaving the device | Whether the queried domain is allowed to go direct |
2. Establish a Baseline: Compare Three Setups on the Same Network
First, note the current node, routing mode, browser Secure DNS setting, system DNS, and client mode. Don't change multiple settings at once, or you won't know what caused the results to change. Use the same device, browser, and network to record results with the client disconnected, with only the system proxy enabled, and with TUN or VPN capture enabled. Skip any mode you don't have; don't stack other networking tools just to complete the comparison.
- Record the direct-connection baseline. Disconnect the client, run a test on a DNS leak test page, and note the resolver name, address, and time. Test pages typically use random subdomains to reduce cache interference, but only test requests from the current browser.
- Record the proxy results. Connect to a node and rerun the full test on the same page—don't just refresh an old result. Record the website's exit IP at the same time to distinguish a change in connection egress from a change in the DNS path.
- Control for browser settings. Temporarily turn off the browser's built-in Secure DNS and test again. If you normally keep it enabled, turn it back on and verify that its HTTPS connection also uses the intended outbound route.
- Check other apps. Once the browser passes the test, check the software you actually use. A system proxy doesn't cover every command-line tool, app with its own resolver, or app that sends UDP directly.
Key point: the resolver name doesn't prove the query's route
If all you know is which DNS provider the test page displays, don't switch nodes yet. First check whether the query went directly out through the physical network adapter. Then decide whether to adjust traffic capture or the DNS outbound rules.
3. v2rayN: Check Traffic Capture Before Configuring DNS
These steps use common labels from the Chinese-language interface. Menu groups vary by version and selected core. Before making changes, note your v2rayN version and core, and back up the current settings. On desktop, Set system proxy mainly affects apps that honor the system proxy. TUN captures a broader range of traffic, but you still need to check exclusions and DNS capture rules. These modes aren't interchangeable.
-
Check the local proxy endpoint
Go to Settings → Parameter settings and check the local listening port. If the port is 10808, apps must use the matching protocol and port; don't treat a SOCKS endpoint as an HTTP endpoint. If mixed-protocol listening is supported, follow the interface's instructions.
-
Confirm the proxy mode
At the bottom of the main window, under System proxy, select Automatically configure system proxy. Then check that the proxy address and port match in your system settings. If you need to cover apps that don't honor the system proxy, consider enabling TUN from the main window and grant the requested permissions.
-
Check the DNS rules
Go to Settings → DNS settings. If your version or core puts this option under Parameter settings, use the corresponding DNS page. Check which remote resolver is used for proxied domains, and confirm that connections to it use a proxy outbound. Entering a server address alone isn't enough.
-
Check the routing scope
In Routing settings, review the direct domains, proxied domains, and default outbound. Temporarily switching to global proxy routing can help narrow down the issue, but it doesn't replace DNS capture or prove that every app on the system is covered.
-
Restart and test again
Save the settings and restart the core. Check the startup log for configuration errors, then repeat the same tests. If results keep changing after subscription updates, check whether the subscription regenerates DNS or routing settings instead of continuing to layer on more rules.
On macOS and Linux, the desktop environment and individual apps determine how system proxy settings work. Don't assume the same settings path as on Windows. Whatever the platform, verify whether app traffic reaches the client, which DNS the core uses, and which outbound route the DNS queries take.
4. v2rayNG: Check VPN Coverage and Remote DNS
On Android, seeing a VPN icon after connecting only confirms that the VPN service started; it doesn't guarantee that every app is covered. Per-app proxy settings, LAN bypass, other VPN services, and Android Private DNS can all affect the results. v2rayNG settings vary by version. Look for labels such as Remote DNS and Enable local DNS on the settings page. If an option isn't there, don't try to approximate it with an unrelated toggle.
-
Check which apps are covered
Open Settings → Per-app proxy from the side menu and check whether the selected apps are proxied or bypassed. Make sure the browser you're testing is included in the proxy scope. For troubleshooting, you can temporarily turn off per-app restrictions, but note the original app list first.
-
Configure DNS handling
Find the DNS section in Settings and check Remote DNS. If Enable local DNS is available, read its description before turning it on. Here, “local” usually means DNS handling inside the client; it doesn't mean sending queries to your ISP's DNS.
-
Check system settings
On Android, go to Settings → Network & internet → Private DNS and note the current setting. Menu paths vary by manufacturer; you can search Settings for “Private DNS.” Temporarily disable it for comparison tests, then restore it and test again.
-
Reconnect and check the logs
Save your settings, disconnect, and reconnect. Open Logs from the side menu and check for query timeouts or outbound failures. Repeat the tests on both Wi-Fi and mobile data to make sure the selected resolver is reachable on each network.
If both browser Secure DNS and Android Private DNS are enabled, change only one setting at a time. DoH uses HTTPS; DoT commonly uses TCP port 853. Both encrypt DNS queries in transit, but whether they go through the proxy depends on traffic capture and routing. After switching networks, being able to open previously visited sites may just mean the results are cached—not that DNS is working reliably.
- After using global proxy routing for comparison, restore your original routing rules and retest both proxied and direct domains.
- LAN printers and internal corporate domains may rely on local DNS. Keep explicit rules for them rather than replacing every resolver with a public service.
- v2flyNG uses a different core and interface. Don't copy v2rayNG runtime settings directly; check the DNS fields and routing capabilities again when migrating.
5. Logs and Packet Captures: Find Where the Request Fails
First determine whether the failure happens during the query, connection, or listening stage. The examples below may appear in the core or in lower-level network errors; exact prefixes vary by version. Treat them as troubleshooting clues, not proof of a DNS leak on their own.
Error: context deadline exceeded
Cause: The operation didn't complete within the time limit. Near a DNS query, this may indicate an unreachable resolver or an incorrect query route.
Fix: Check the destination address and outbound records for the same time. Verify the resolver's network path before changing timeout settings.
Error: no such host
Cause: Name resolution didn't return a usable result. Possible causes include a misspelled domain, a nonexistent response from the upstream resolver, or a filtering rule.
Fix: Identify whether the failed lookup was for the node domain or an app domain, then cross-check it using a separate DNS path. Don't change all routing rules at once.
Error: address already in use
Cause: Another process is already using the address or port, so the client endpoint may not have started at all.
Fix: Find the process using the port or choose another listening port. Update the app's proxy settings to match, then restart the core and confirm that it starts listening.
Windows: Check system DNS and clear the cache
Run these commands in PowerShell to check your network adapters' DNS settings, clear the system DNS cache, and test command-line name resolution. The last command typically uses the DNS servers configured for Windows; enabling an HTTP system proxy doesn't automatically route it through the client. So it's normal for the result to differ from your browser's.
Get-DnsClientServerAddress
Clear-DnsClientCache
nslookup example.comCheck for unencrypted DNS and IPv6
If you can capture packets, apply the filter below on the physical network adapter. Close unrelated apps first, then trigger a fresh domain lookup. Seeing traffic on port 53 alone isn't enough; check the query name and timestamp to confirm it came from the app under test. Conversely, no port 53 traffic doesn't guarantee there's no leak: the query may use encrypted DNS or come from cache.
udp.port == 53 || tcp.port == 53
tcp.port == 8536. DNS Leak Prevention Checklist and Rollback
Check your setup against the intended policy rather than trying to make the page show just one resolver. If all app DNS queries should go through the proxy, check the resolver and outbound route for each covered app. If you use split routing for domestic and international domains, test both the direct and proxied domains. DNS queries and website connections can follow different policies, but those differences should be deliberate—not an accidental bypass.
- Configuration is active: The core starts normally after a restart, with no DNS configuration or listener errors in the logs.
- Routes match expectations: The test browser is within the capture scope, and remote DNS connections use the intended proxy outbound.
- Cache is ruled out: Clear the system cache or use a fresh query generated by the test page so old results aren't mistaken for the current setup.
- Networks are covered: Test again on Wi-Fi, mobile data, or another desktop network. Record any differences; don't assume one test represents every network.
- Startup works: After a device restart, the first connection can resolve the node address without relying on cache left over from a previous connection.
- Rollback is clear: Keep the original DNS, routing, and Private DNS settings. If something breaks, revert the most recent change first, then verify basic connectivity.
Key point: fix one route at a time
If websites load but DNS takes an unexpected route, first fix DNS capture and the query outbound. If the node domain itself won't resolve, restore the bootstrap lookup first. Handling these as separate issues makes results easier to reproduce than changing the protocol, node, and every DNS setting at once.
When sharing troubleshooting details, include the client version, core, routing mode, error timestamp, and redacted logs. Subscription URLs, node credentials, and full runtime configurations may grant access and shouldn't be posted publicly. For further help, see Troubleshooting and check startup, listening, connection, and DNS resolution in that order.