For desktop users whose websites load but DNS leak tests still show their local ISP's DNS. First, distinguish web traffic from DNS lookup paths. Establish a baseline with the proxy off, then check browser Secure DNS, remote and direct DNS in v2rayN, and TUN coverage. Finish by repeating the tests and checking the logs; a country label alone does not prove a leak.
What is a DNS leak? Web traffic may use the proxy while DNS lookups do not
Before connecting to a domain, an app usually needs to look up its IP address. A DNS leak occurs when a domain lookup that should follow a specific proxy route is sent to an unexpected resolver, such as your local ISP's DNS server. A changed public IP address does not prove that DNS queries took the same route.
v2rayN is a client management interface; actual connection and DNS behavior also depend on the selected core, the generated configuration, and how traffic enters the client. Setting a system proxy only affects apps that honor the system proxy settings. An app that sends UDP DNS requests directly, or a browser using its own Secure DNS, may take a separate lookup route.
Ports can help identify traffic, but they do not prove that a connection is secure. DoH sends DNS queries over HTTPS; if that connection goes direct, DNS may still bypass the proxy. Conversely, traditional DNS sent through a proxy tunnel is not necessarily a leak just because it uses port 53.
DNS leak test: establish a baseline, then compare proxy results
DNS leak test pages usually have your browser request a set of random subdomains, then show the recursive resolvers based on queries received by authoritative DNS servers. The results reflect the lookup path triggered by that browser test—not an audit of every app on your computer. Enter dnsleaktest.com in the address bar and compare the Standard and Extended tests.
-
Record a baseline
On a network where direct testing is permitted, first turn off the v2rayN system proxy and TUN. Record your public IP, the resolver IPs detected, and the ISP name. Test domains generate real network requests, so do not disable protection casually in environments with confidentiality requirements.
-
Use the same browser
Test with the same browser and profile. In Edge, for example, go to Settings → Privacy, search, and services → Security and check the Use secure DNS option. Wording may vary between versions; search settings for “Secure DNS.” Note the original setting and turn off independent DNS resolution for the test.
-
Turn on the proxy
In the v2rayN main window, select Set system proxy automatically from the System proxy menu and confirm that the current node works. Start with the system proxy only; don't also switch TUN, nodes, or routing templates, or it will be hard to tell which change made a difference.
-
Run the test again
Reopen the test page and run both Standard and Extended tests. Repeat each test twice, noting the time, public IP, resolvers, and routing mode. A resolver missing from the results does not mean other apps cannot use it.
-
Compare the paths
If a resolver from your baseline ISP still appears with the proxy on, check the browser and system DNS settings. If only public resolvers appear, confirm that they are the ones you expect and that connections to them actually go through the proxy.
Bottom line: compare resolver identities, not just countries
Resolvers may use anycast, forwarding, or egress points in other regions, so their reported location may not match your proxy node. Compare resolver IPs and providers, then check routes and logs. Don't keep switching DNS servers just to make the country names match.
Remote DNS vs. direct DNS: what each one does
These instructions follow the v2rayN 7.x desktop interface. The usual path is Settings → DNS settings; older releases or other interface builds may put the options under Settings → Parameters settings. Check your local menus and selected core first. If you can't find a matching field, don't paste in configuration intended for a different core.
| Setting | Main purpose | What to check |
|---|---|---|
| Remote DNS | Resolve domains intended to use the proxy | The DNS request's outbound route matches the intended route |
| Direct DNS | Resolve domains for direct connections and, when needed, node hostnames | Broad rules must not send domains meant for the proxy to a direct resolver |
| System DNS | Used by the operating system and apps not handled by the client | The system proxy usually does not intercept every system DNS request |
| Browser Secure DNS | The browser uses DoH or another method to resolve domains independently | Browser policies and connection routes may bypass the client's DNS settings |
For remote resolution, you can use a DoH URL supported by the settings interface, such as https://dns.google/dns-query. For direct resolution, choose a reachable resolver for your network, such as 223.5.5.5. These are example service addresses, not universal recommendations. After entering an address, confirm that the selected core supports its format and check which outbound route will carry the queries.
- Save the original configuration. Note the current remote DNS, direct DNS, routing template, and core. Keep a copy of any custom configuration so you can roll back individual changes.
- Configure remote resolution. Under Settings → DNS settings, adjust the remote DNS option for the selected core. If the interface lets you choose an outbound route for DNS traffic, select the proxy outbound. If there is no such option, inspect the generated configuration and related routing rules.
- Keep direct resolution where needed. Use direct DNS for domains that should connect directly. If the proxy server is specified by hostname, it also needs a bootstrap lookup path that does not depend on the proxy itself; otherwise, you can end up in a loop where the proxy must connect before its address can be resolved.
- Apply changes and retest. Save and confirm that the core reloads successfully. If it does not reload automatically, stop and restart the connection. Return to the same test page and repeat the tests, then check that sites intended for direct access still work.
TUN and FakeDNS: check traffic coverage and address mapping separately
System proxy mode works well for browsers and other apps that honor proxy settings, but it does not automatically cover every app. TUN receives IP traffic matching its routes through a virtual network adapter, making it useful for apps that do not use the system proxy. Whether it also captures DNS depends on DNS interception rules, system routes, IPv6, and other networking software—not just whether the TUN switch is on.
FakeDNS is a separate mechanism: the core returns a synthetic IP from a pool for a domain, then maps that address back to the domain when the connection is made, allowing domain-based routing. A common IPv4 FakeDNS pool in Xray is 198.18.0.0/15. Returning a synthetic IP does not encrypt DNS or automatically route lookups through a remote proxy.
- Check compatibility first: In v2rayN, confirm that the selected core and configuration mode support FakeDNS. Fields and implementations vary between cores; don't copy the Xray
fakednsconfiguration directly into another core. - Ensure DNS and connections are handled together: An app that receives a synthetic address must also have its subsequent connection handled by the same mapping mechanism. Changing DNS without capturing the connection can leave domains resolving successfully while their websites fail to load.
- Check IPv6: Configuring IPv4 DNS or IPv4 routes alone does not show that the IPv6 path is covered. Check AAAA lookups and IPv6 connections separately instead of treating IPv6 as something to disable as a general fix.
- Clear caches after disabling: After turning off FakeDNS or TUN, run
ipconfig /flushdnsin a Windows terminal, then close and reopen the browser. Browser and app caches may not be cleared when the system cache is flushed.
Bottom line: test regular DNS first, then try FakeDNS
First use regular DNS to confirm that the node works, resolvers are reachable, and routing is correct. Then enable FakeDNS on its own. If only one app has problems, check whether both its DNS and connections are being handled before switching your entire node setup.
DNS timeouts and connection failures: troubleshoot by error message
Read errors alongside the surrounding log entries. Prefixes, domains, and addresses vary between core versions; the examples below are common snippets, not complete logs. Changing the node, DNS, routes, and browser settings all at once makes it much harder to find the cause.
Error: lookup example.com: i/o timeout
Cause and fix: The DNS lookup timed out. The resolver may be unreachable, the wrong DNS outbound may be selected, or packets may be getting dropped. Check the resolver address and its route, change only one DNS setting, restart the connection, and test again.
Error: no such host
Cause and fix: The lookup returned no usable host record. Possible causes include a misspelled domain, a negative cache entry, or the resolver's response. Check the exact domain in the log and determine whether it is the node address or the destination site. Then clear the cache and compare results using another trusted lookup path.
Error: connect: connection refused
Cause and fix: The destination port refused the connection; this does not mean there is a DNS leak. If this happens during a local SOCKS test, first check that v2rayN is running and that the actual listening port matches the command.
The commands below help distinguish system DNS resolution from the SOCKS proxy route. The example assumes the local SOCKS listener is at 127.0.0.1:10808; check your local settings or startup logs for the actual port first. Keep the listener bound to the local machine. Troubleshooting DNS does not require exposing the proxy port to your entire LAN.
# View system DNS configuration
ipconfig /all
# Query the system's default resolver; this command does not automatically use the system HTTP proxy
nslookup example.com
# Send the destination hostname through SOCKS so curl does not resolve it locally first
curl.exe --socks5-hostname 127.0.0.1:10808 --connect-timeout 10 -I https://example.com/
# Clear the Windows DNS cache after changing DNS settings
ipconfig /flushdns--socks5-hostname sends the destination hostname to the SOCKS proxy, but the core configuration determines how the proxy ultimately resolves it. A successful command only shows that this request path works; it does not prove that the browser or other apps aren't resolving domains outside it. Likewise, the local DNS address shown by nslookup is not, by itself, evidence of a browser leak.
Verify the fix: save test results with the usage scenario
The goal of fixing a DNS leak isn't to make a test page show only one result. It is to ensure that lookups and connections meant to use the proxy follow the correct route while necessary direct traffic continues to work. Extended tests may show multiple egress IPs for the same DNS service; a change in count is not necessarily a problem.
- Retest the browser: With Secure DNS set to the recorded state, run two rounds of tests and confirm that results do not unexpectedly include the ISP resolver from your baseline.
- Retest other apps: Test a regularly used app that may not honor the system proxy on its own. A successful browser test does not prove that the app is covered.
- Retest split routing: Visit sites expected to connect directly and through the proxy, and check the outbound selection in the logs. If you temporarily raise the log level, restore it afterward to avoid recording excessive browsing details.
- Retest after changing networks: Switch from your home network to a mobile hotspot and test again. Changes to DNS, IPv6, and routing on the new network may expose gaps in the configuration.
- Keep rollback notes: Record the v2rayN version, core version, proxy mode, DNS service addresses, and test time. Before sharing logs, remove subscription URLs, credentials, and any unnecessary destination domains.
If websites work as usual and only the test page shows a region different from your node, first check the resolver's identity and forwarding path. If switching DNS makes every node unreachable, restore the original settings and check the bootstrap lookup for the node hostname. Troubleshooting browser settings, DNS outbound routing, and system traffic capture in that order is usually more effective than enabling everything at once.