V2Ray DNS Leak Test and v2rayN DNS Settings to Prevent Leaks

At a glance

If your web traffic exits through the proxy but a DNS test still shows your local ISP, first distinguish browser, system, and core DNS resolution. Then troubleshoot the relevant layer. This guide uses v2rayN on Windows and covers comparison tests, remote DNS routing, TUN takeover checks, and log troubleshooting. It’s for users who have imported a node and can connect, but want to verify that domain queries follow the intended route.

What Counts as a DNS Leak?

DNS translates domain names into addresses. A successful proxy connection only shows that one connection used the proxy; it doesn’t mean every app resolves domains the same way. A browser may use its own encrypted DNS, Windows may query the router, and the proxy core may resolve names separately for node connections or routing decisions. Check each path independently.

Here, a leak means a domain query that was supposed to go through the proxy was instead sent to a resolver on the local network. If your rules intentionally send domains in mainland China directly and proxy other traffic, using local DNS for those domains may be expected. A local location in the test results alone does not mean the entire configuration has failed.

App requests a domainResolver selectedDNS outbound matchedUpstream recursive lookupResolution returned

v2rayN is a client interface; actual DNS behavior depends on the selected core, generated configuration, and app settings. Connection protocols such as VMess and VLESS do not automatically take over system DNS. A test page usually shows the recursive resolver that queried the test domain’s authoritative server—not necessarily the proxy node’s address. The resolver’s country alone also cannot tell you whether the query was encrypted.

Run a Comparison: Test the Exit, Then DNS

Use the same computer, network, and browser throughout. Search for and open a DNS test page from DNSLeakTest or BrowserLeaks. The test service will receive test queries, so review its privacy policy first if you’re in a sensitive environment. Never share subscription URLs, node credentials, or your full client configuration.

Record a direct-connection baseline. Turn off the v2rayN system proxy and TUN, and make sure the browser has no manually configured proxy. Note your public IP, the resolver names shown by the test, and the browser’s current Secure DNS status.
Enable only the system proxy. Select a working node, then use the tray menu: “System Proxy” → “Automatically Configure System Proxy.” Confirm that your web traffic exits as expected, then run a full DNS test again.
Change one variable at a time. Keep the node and routing mode unchanged while adjusting DNS or the browser’s Secure DNS setting, then test again. Don’t switch nodes, change networks, and enable TUN all at once—you won’t know what caused the result.
Compare with TUN enabled. Check and record the system proxy status, then enable TUN and repeat the same tests. Restart the browser after switching so it doesn’t reuse existing connections.

What you see	Possible explanation	Next step
Web exit IP unchanged	The browser may not be using the proxy, or the destination may match a direct-connection rule	Check the system proxy and routing match first; don’t change DNS yet
Web exit IP changed, but the resolver is still your local ISP	Queries may be going through a local path, or a direct-connection rule may be matching them	Check the test domain’s route and the browser’s DNS settings
Multiple public resolvers appear	The browser, core, or upstream service may be using different resolution paths	Compare logs and packet captures to identify each source
Resolver address differs from the node address	The node may use a separate recursive resolver or public DNS	Don’t assume this means there’s a leak

Bottom line: judge by the intended path, not the number of addresses

First specify which domains must be resolved through the proxy, then check how those queries actually travel. Multiple resolvers aren’t proof of a leak by themselves. The issue to fix is a target domain query unexpectedly going to a local resolver.

System Proxy and Browser DNS: Rule Out Bypass Paths

The system proxy affects apps that honor its settings; it doesn’t take over every network connection. Some programs resolve names themselves before connecting, while others ignore the system proxy entirely. Browser Secure DNS—DNS over HTTPS (DoH)—uses a separate connection whose outbound route needs checking. Enabling it does not automatically send DNS queries through the proxy.

Traditional DNS commonly uses UDP/TCP port

443

HTTPS port commonly used by DoH

10808

Example local proxy ports; use the values shown in your interface

Check the listening address and port. Find the current local listener details on the v2rayN main screen. If your settings include “Settings” → “Parameter Settings” → “Basic Settings,” check the local listening port there. Menu names vary between versions; don’t assume the example port applies to your setup.
Set a consistent browser DNS policy. Search the browser settings for “Secure DNS” and note the provider and whether it’s enabled. For diagnosis, you can temporarily turn it off so the browser uses the system or proxy-provided resolution path, then test its behavior separately with Secure DNS enabled.
Check manual SOCKS settings. If the app offers an option to “resolve domain names through the proxy,” enable it explicitly. If the app resolves the domain locally and then sends the IP through the SOCKS proxy, the page may still load successfully—but the domain was queried locally.
Keep WebRTC and DNS tests separate. WebRTC address exposure is a different test. Don’t attribute every address shown on the same test page to DNS.

Don’t set your Windows network adapter’s DNS to 127.0.0.1 as a one-size-fits-all fix. This only works if a DNS listener is actually running on your machine at that address on port 53. v2rayN’s local HTTP and SOCKS proxy ports are not system DNS ports, and they aren’t interchangeable.

v2rayN DNS Settings: Check the Server and the Route

Back up your current configuration and note the selected core before making changes. Open “Settings” → “DNS Settings”; in some versions, these options are under Parameter Settings. If you don’t see an identically named menu, use the DNS options in your actual interface—don’t paste JSON meant for a different core. Field names, available templates, and DNS routing support vary by core.

Separate the roles of direct and proxied DNS. If you keep split routing, use direct DNS for domains intended to connect directly and remote DNS for domains that must use the proxy. If your goal is to resolve all traffic’s domains through the proxy, make sure the test configuration doesn’t still send those domains to direct DNS.
Choose a reachable remote resolver. DNS servers can use plain DNS or an encrypted method supported by your core. Entering a public DNS address alone won’t change the outbound route. For example, changing the server to 1.1.1.1 won’t make queries go through the proxy if they still leave over your local network.
Check the route for DNS requests. Make sure connections to the remote resolver use the intended proxy outbound, rather than matching an earlier direct rule for private addresses, regional addresses, or broad address ranges. DoH commonly uses port 443, so a rule that only covers port 53 won’t be enough.
Plan for initial resolution. If your proxy node address is a domain name, it usually needs to be resolved before the proxy can connect. A DoH server specified by domain name also needs an initial lookup. Give these startup queries a defined route to avoid a loop where the proxy needs DNS to connect, but DNS depends on a proxy that isn’t connected yet.
Save and restart the core. Check the startup logs for errors, then test with a new domain. If you saved the settings without reloading the configuration, results may still reflect the previous setup.

Routing Rules and TUN: Check System DNS Queries

TUN uses a virtual network adapter to take over IP traffic that matches its routing conditions, making it useful for apps that ignore the system proxy. But enabling TUN doesn’t automatically send all DNS queries to the core’s resolver. Check whether the selected core supports DNS interception or hijacking, which traffic it covers, and whether any routes are excluded. Don’t copy fields with the same name across different cores; they may mean different things.

Make sure TUN starts successfully. Grant any permissions requested by the interface, then check the logs for errors such as virtual adapter creation or route setup failures. An enabled toggle isn’t proof of successful traffic takeover if the adapter was never created.
Check traditional DNS interception. Verify that UDP/TCP queries on port 53 enter the intended resolution path. Covering UDP alone misses TCP queries; covering IPv4 alone may miss IPv6 traffic.
Check encrypted DNS outbound separately. Browser DoH is HTTPS traffic, not a traditional query on port 53. Check its route using the resolver’s domain name or address.
Check rule order. Rules are usually evaluated in the order defined by the core. A broad direct-connection rule may match before a remote DNS rule. Check the generated configuration and logs instead of relying on whether a rule appears in the interface.
Check IPv6 and multiple adapters. Wi-Fi, Ethernet, and other tunnels may be active at the same time. Check the DNS servers and routes for each active interface. Rather than permanently disabling IPv6 as a general fix, make sure its traffic is covered by the intended interception path.

FakeDNS isn’t a required DNS leak prevention switch. It returns virtual addresses and keeps domain mappings for traffic handling; both DNS queries and subsequent connections must pass through the corresponding core. If the system cache retains a virtual address but traffic leaves that processing path, connections may fail. If ordinary remote DNS meets your needs, start with a simpler setup.

Windows Commands and Common Errors

Run these commands in PowerShell to view interface DNS settings, check the local cache, and clear the system DNS cache. Clearing it affects the next query from other apps on your computer, but won’t clear every browser cache or close existing connections. After clearing the cache, fully exit the browser and reopen it before testing.

Get-DnsClientServerAddress
Get-DnsClientCache
Clear-DnsClientCache
Resolve-DnsName example.com

Resolve-DnsName and nslookup aren’t browser proxy test tools. With only the system proxy enabled, their queries usually won’t go through an HTTP or SOCKS proxy. In TUN mode, whether they’re intercepted depends on DNS interception settings and routing. A successful command only proves that the name was resolved; it doesn’t prove the query took the intended path.

Error: i/o timeout

Cause: The request didn’t get a response in time. In DNS logs, this may mean the upstream server is unreachable or the corresponding outbound route isn’t working.

Fix: Check the destination address and outbound route in the same log entry, then test the proxy connection and DNS server separately. Don’t keep increasing the timeout every time a request times out.

Error: no such host

Cause: Name resolution failed. The domain may be misspelled, the upstream server may have returned a nonexistent-domain response, or the initial resolution path may be misconfigured.

Fix: Identify whether the error refers to the node domain, DNS server domain, or destination you’re trying to visit, then check the resolver used for that domain. Not every resolution failure is a node problem.

Error: connection refused

Cause: The destination port refused the connection. This often happens when DNS points to the local machine but no DNS service is listening there, or when the wrong local proxy port is configured.

Fix: Compare the settings with the actual listening details shown in the interface. Distinguish DNS port 53 from proxy ports, and remove any loopback address setting that has no service listening behind it.

For stronger evidence, capture traditional DNS traffic on the physical network adapter and check the destination addresses and test domains for UDP/TCP port 53. Looking only at the virtual adapter can hide the final outbound route. Seeing encrypted proxy traffic on the physical adapter is normal. Not seeing port 53 traffic doesn’t rule out queries sent directly to a DoH service, so also check browser settings and core logs.

FAQs and How to Verify the Fix

Why does the test still show my original ISP after I change the remote DNS server?

First check whether the browser uses its own Secure DNS, then make sure the DNS settings were saved and the core restarted. Next, check whether a direct-connection rule matches the test domain. Changing the server address without changing the query’s outbound route usually won’t change how the query travels.

If the system proxy test passes, can other apps still leak DNS?

Yes. The test page only checks queries made by the current browser. For apps that ignore the system proxy, check their proxy and DNS settings individually, or enable and verify TUN interception. One browser test doesn’t cover every app.

Does seeing resolvers in multiple countries mean my setup is wrong?

Not necessarily. Public DNS services may use distributed exits, and IP geolocation databases can be inaccurate. First compare results with other browser resolution paths disabled, then check outbound logs and physical adapter traffic. Don’t remove servers based only on country labels.

What should I check first if no websites load after enabling TUN?

Turn off TUN first to restore your previous connection, then check the virtual adapter, route permissions, and any startup resolution loops. Once you have a working setup again, change one setting at a time. Don’t add FakeDNS, global routing, and a new DNS template all at once.

After fixing the issue, record results separately for “system proxy test,” “TUN test,” and “real app test.” Each time, check the web exit IP, resolver, browser Secure DNS status, and core error logs. If you keep direct connections for domains in mainland China, record those expected queries separately from queries that must use the proxy so normal split routing isn’t mistaken for a leak.

Test domains that must use the proxy don’t unexpectedly appear in local, unencrypted DNS queries.
Connections to remote DNS use the intended outbound route, with no persistent timeouts or startup resolution loops in the logs.
Results are reproducible after restarting the client and browser. Test again after switching networks.
If you need browser Secure DNS, enable it separately and retest its connection route.