Your public IP may change while DNS queries still travel through your local network. This guide covers the browser, system resolver, and proxy core to help you establish a baseline, configure remote DNS, check TUN coverage, and distinguish expected direct DNS from leaks. For desktop and Android users who can connect to a server and want to verify where DNS queries go.
1. What Is a DNS Leak? First, Decide Which Queries Should Use the Proxy
DNS translates domain names into IP addresses, but web traffic and DNS queries do not necessarily take the same route. When a browser accesses a site through a proxy, it may send the domain name to the proxy for resolution. Other apps may query the system DNS first, then send the resulting IP address through the proxy. In that case, your web traffic exits remotely, but your local network may still see the domain you looked up.
Whether this counts as a leak depends on your routing goals: a query leaks when a domain meant to be resolved through the proxy is instead sent to your local network or an unexpected resolver. If local DNS is supposed to handle LAN names and sites accessed directly, seeing a local resolver does not necessarily mean your entire setup is misconfigured.
- System proxy: Only affects apps that honor the system proxy settings. It does not automatically capture all UDP port 53 queries.
- TUN mode: Routes traffic through a virtual network adapter. Whether DNS is captured also depends on DNS hijacking, routing, interface exclusions, and IPv6 settings.
- Secure DNS in the browser: The browser may resolve names over HTTPS, bypassing system DNS. You still need to check whether its HTTPS connection goes through the proxy.
- Routing rules: Determine where app traffic and DNS queries go. They are related, but controlled by separate settings.
2. Test for DNS Leaks: Compare Three Sets of Results
Before enabling the proxy, note your public IP, DNS resolver operator, and current network. Then enable the proxy and repeat the test. Choose a DNS leak test site that supports random test domains and multiple rounds. These sites typically show the resolver's exit point, not the DNS address your computer connects to directly. Anycast routing and geolocation databases can also affect the reported location, so don't rely on the flag alone.
| Test setup | What to record | What it tells you |
|---|---|---|
| Proxy off | Public IP, resolver operator, network type | Establish a local baseline for your current network |
| System proxy only | Web IP, browser Secure DNS status, resolver changes | See which DNS path the browser actually uses |
| TUN enabled | Resolver list, IPv4 and IPv6 connections, core logs | Check which system traffic and DNS queries TUN captures |
Run at least two rounds for each setup. After changing a setting, clear the cache and reopen the test page. On Windows, run the command below in a terminal. It clears the system DNS cache only; it does not clear your browser's cache or change your DNS server settings.
ipconfig /flushdns
Get-DnsClientServerAddressThe second command is for PowerShell and lists the DNS addresses assigned to each network adapter, which can help you tell physical and virtual adapters apart. This is not proof of a DNS leak: seeing your router's address on an adapter does not mean every query bypassed TUN. Conversely, nslookup example.com does not use the standard HTTP system proxy. It can help you inspect that tool's query path, but it cannot replace tests in a browser or across the whole device.
Bottom line: Check the resolver operator, then verify the actual outbound route
If the same local ISP resolver appears before and after enabling the proxy, first check whether it is expected under your direct-connection rules. For domains that must use the proxy, verify the DNS logs and traffic on the physical network adapter before switching servers.
3. Configure Remote DNS and Domain Routing in v2rayN
Before making changes, note your v2rayN version, the core used for app traffic, and the core used by TUN. DNS settings layouts vary between versions. The steps below refer to the interface with a Settings → DNS Settings entry. If separate settings are shown for different cores, edit the one currently in use. A custom full configuration may also override settings generated by the GUI.
-
Record the current settings
Go to Settings → Parameters and note the local listening port and relevant core settings. Save your existing DNS configuration. If the local listening port is
10808, configure apps to use that actual port; don't copy10809from another guide. -
Identify the resolvers
Go to Settings → DNS Settings and distinguish the remote DNS for proxied domains from the local DNS for direct connections. For a field that supports DoH, you can enter a full endpoint such as
https://dns.google/dns-query. Don't enter a URL in a field that accepts IP addresses only. -
Check the outbound route
Check the DNS outbound option or the routing rules in the generated configuration to ensure remote DNS queries use the proxy as intended. Local DNS may still be needed for direct connections and initial lookups. A field labeled “remote” does not, by itself, mean the query is sent through the proxy.
-
Review the domain strategy
Go to Settings → Routing and review the domain strategy. In Xray routing,
AsIs,IPIfNonMatch, andIPOnDemandcontrol whether a DNS lookup is triggered during route matching; they are not DNS encryption settings. First make sure your domain rules match correctly, then decide whether you need to resolve domains for IP-based rules. -
Apply changes and retest
Save your settings, restart the service or reconnect to the server, and check the core startup logs for configuration errors. Then clear the DNS cache and repeat the same tests. Change one setting at a time and keep a copy of the original working configuration so you can roll back.
4. Prevent DNS Leaks in TUN: Check DNS Capture, IPv6, and Browser Settings
If you need to cover apps that ignore the system proxy, consider enabling Enable TUN on the v2rayN main screen. The first launch may require administrator privileges. TUN does not automatically prevent every DNS bypass: some versions use a separate core for TUN, with DNS settings that differ from those in standard proxy mode.
- Confirm the virtual adapter starts: Check the logs to make sure the TUN interface was created successfully; don't rely on the toggle's appearance. If the driver or route fails to initialize, fix that first.
- Check DNS capture rules: Verify that queries sent over UDP/TCP port 53 are captured. Capturing traditional DNS ports does not automatically detect apps that use their own DoH over port 443.
- Check IPv6: IPv6-capable networks may generate both AAAA queries and IPv6 connections. Check whether IPv6 routes are captured. Temporarily disabling IPv6 can help isolate the issue, but it is not a suitable long-term fix for every network.
- Keep browser settings consistent: Note the Secure DNS setting under the browser's Settings → Privacy and security; the exact location varies by browser. Keep the DNS method consistent during testing, then restore your preferred setting and test again.
- Check other virtual adapters: Other VPNs, virtual machines, and corporate networking tools can change DNS, route priorities, or interface metrics. Disable them one at a time during troubleshooting rather than changing several network paths at once.
For a more advanced check, monitor whether the physical network adapter sends port 53 queries to unexpected addresses. Limit the capture to a specific time window, and distinguish lookups for target sites from LAN queries and initial server lookups. Not seeing plaintext traffic on port 53 does not prove that all DNS goes through the proxy; apps may connect directly to encrypted DNS services.
Bottom line: Test the domains you care about, not whether every resolver matches
Keep direct DNS resolution where needed, and verify that both DNS and app traffic for proxied domains follow your rules. Tighten direct-connection exceptions only if you need to proxy the entire device, then check that LAN services still work.
5. v2rayNG DNS Troubleshooting Checklist for Android
v2rayNG uses the Xray core, with Android's VPN interface routing traffic from apps included in its coverage. v2flyNG uses the V2Fly core, so you cannot copy every DNS and routing setting between them. This checklist is for v2rayNG. Setting names and layouts may vary by version; follow the guidance shown in your current app.
- Confirm the connection mode: In v2rayNG Settings, check that VPN mode is enabled and that Android shows the VPN connection. In local proxy mode, other apps must be configured to use the proxy themselves.
- Check DNS options: In Settings, review the options for Remote DNS, DNS for China, and Local DNS. Some settings only apply in specific modes. Record the current values, change one group at a time, then reconnect and check the logs.
- Check per-app proxy settings: Go to Settings → Per-app proxy and make sure the browser you're testing is included in VPN coverage. When bypass mode is enabled, the list works in the opposite way from proxy-only-selected-apps mode, so don't rely on whether an app is simply checked.
- Check Android Private DNS: Search Android's system settings for Private DNS and note whether it is set to Automatic, Off, or a provider hostname. How it interacts with DNS capture in the client depends on the Android version and configuration. Compare before and after rather than assuming one setting overrides the other.
- Test each network separately: Run a test on both Wi-Fi and mobile data. Reconnect the client after switching networks, check whether the resolver changes, and keep IPv6 and browser Secure DNS in mind.
If only one app uses a different resolver, check its per-app settings and any built-in DNS options first. If all apps are affected, check the VPN connection, Android Private DNS, and current network. This narrows the issue to a specific layer instead of repeatedly refreshing subscriptions or switching protocols.
6. No Connection After Changing DNS? Troubleshoot by Error Message
A common sign of a bad remote DNS setting is that the server appears selected but websites won't load. First revert the setting you just changed and confirm the service starts. Then use the logs to distinguish a DNS resolution failure, connection timeout, or configuration error. These messages can occur at different points in the connection chain, so read them alongside the surrounding target address, outbound tag, and timestamp.
Error: no such host
Cause and fix: Usually means the requested name could not be resolved. Check whether the domain in the error is the server address, DoH endpoint, or website. Then verify the spelling, resolver availability, and initial lookup path. Don't assume every error of this kind means the server is down.
Error: context deadline exceeded
Cause and fix: An operation did not finish in time; it may involve a DNS request or a later connection. If the surrounding log shows a DNS timeout, check the resolver's actual outbound route and network reachability. If it occurs while connecting to the server, continue troubleshooting the server connection.
Error: network is unreachable
Cause and fix: There is no usable network route to the selected address. This may be related to IPv6, TUN routing, or a changed network interface. Check the address family in the logs, reconnect, and review the routes. Don't mask an interface problem by changing DNS at random.
After making a change, retest with the same browser, network, and proxy mode, and keep notes from before and after. DNS leak tests check whether queries follow the expected path; they don't need to show just one server. Repeat the baseline comparison after changing cores, updating the client, or editing routing rules.