V2Ray DNS Leak Test and v2rayN DNS Settings

What Counts as a DNS Leak?

When an app connects to a domain, it usually needs the domain’s IP address first. DNS queries and web connections can take different routes: a web connection going through a proxy node does not mean the DNS query went through it too. A DNS leak occurs when a query that was meant to use the proxy path is instead handled by the local network or another unintended resolver.

App requests a domain Resolver is selected DNS route is matched Outbound connection is established Result is returned

First, understand what each component does. v2rayN is a desktop client for managing subscriptions, nodes, routing, and core settings. Cores such as V2Ray and Xray handle the corresponding network traffic. Using a VMess or VLESS node does not automatically determine how DNS works for every Windows app. Whether the core resolves a domain also depends on whether the app passes it a domain name or an already-resolved address, and on which traffic is captured by the system proxy or TUN.

Web exit IP: Shows where this web connection exits. It does not identify the DNS resolver.
Detected DNS servers: Usually shows the public-facing addresses of recursive resolvers, which may differ from the addresses entered in the settings.
Direct DNS for selected domains: A split-routing setup may intentionally use direct DNS for local domains. That is not automatically a leak.
Resolver location: Anycast routing and load balancing can affect the reported location of a public resolver, so country or city labels are only a rough guide.

Run a DNS Leak Test: Record a Baseline, Then Compare

Use the same network, browser, and test site throughout. Enter dnsleaktest.com in your browser, run the standard test, then run the extended test. The test triggers fresh domain lookups so the authoritative side can identify the recursive resolvers. Record the provider names and web exit, not just the number of servers detected.

Establish a direct-connection baseline. If a brief direct connection is acceptable and you won’t access sensitive services, turn off TUN, select “Clear system proxy” in v2rayN, and note which resolvers the current network normally uses. If direct access is not acceptable, skip this step; don’t expose work traffic just to run a test.
Run a proxy comparison. Select a working node and choose “Automatically configure system proxy.” Keep the same routing rules and run the test again. Make sure the browser isn’t using a proxy extension that conflicts with the system settings.
Check the test domain’s route. If the test site or its domains are set to bypass the proxy, the results won’t reflect the proxy DNS path. Temporarily route the test traffic through the proxy, test again, then restore the original rules.
Retest; don’t just refresh. After changing the configuration, restart the core, close the old test tab, and start a new test. Compare the results before and after; cached results don’t reflect the new settings.

If the proxy test still shows the same local ISP resolver as the direct baseline, investigate further. If it shows several addresses belonging to the same public DNS provider, that may simply be load balancing. Conversely, seeing only one resolver does not prove that every app is covered.

Bottom line: Check the Resolver and Expected Route

First confirm that the test domain should use the proxy, then check whether its resolver still belongs to the local network. Don’t judge success by server count or location labels alone.

Configure Remote and Direct DNS in v2rayN

Back up your current settings and note which core is in use. Open “Settings” → “DNS Settings” and check the DNS options for that core. In some versions, the relevant options are under the DNS tab in “Settings” → “Parameter Settings.” Field names, templates, and supported address formats vary by core. If you can’t find an option, check the current interface and core first; don’t paste a full JSON configuration intended for a different core.

53

Common ports for traditional DNS over UDP/TCP

443

Common ports for HTTPS and DoH

10808

Example local proxy ports; check your actual settings

Port numbers identify services; they are not interchangeable. 127.0.0.1:10808 may be an active proxy listener, but that does not make it a DNS server. Only enter an address in your system DNS settings if a DNS service is explicitly listening there.

Configure remote DNS. In a field that supports the format, you can use a DoH URL such as https://dns.google/dns-query. This is only an example; it may not be reachable from your network. Remote DNS queries must also use the proxy outbound if they are meant to travel through the proxy. Otherwise, they’re simply encrypted and sent over the local network.
Configure direct DNS. For domains that should connect directly, choose a resolver reachable from the local network, such as one provided by your network administrator. 223.5.5.5 is an example of a public IPv4 resolver, but test whether it works on your network. For internal domains, follow your network’s DNS configuration.
Check bootstrap resolution. A DoH URL contains a hostname that must be resolved before the first connection. A proxy node address may also be a hostname that needs resolving first. Use the bootstrap or domain-resolution settings supported by your core so node resolution doesn’t depend on a proxy connection that isn’t established yet.
Save the settings and restart the core. Check the logs for resolution errors, then rerun the same online tests. Change one setting at a time so you can tell whether the resolver is unreachable or the outbound route is wrong.

Split Routing: Keep DNS and Connections Within the Intended Boundaries

Open “Settings” → “Routing Settings” and check the rules currently in use, not just an inactive rule set. Split routing involves at least two decisions: which resolver handles a domain, and which outbound carries the connection to its resolved address. These decisions are related, but controlled separately.

Traffic type	Expected DNS	What to check
External domains set to use the proxy	Remote DNS	Both DNS queries and traffic should use the proxy as intended
Domains set to connect directly	Direct DNS	The result should suit the local network and not use the remote path by mistake
LAN or workplace domains	Internal DNS	Preserve internal resolution; don’t send these queries to public resolvers
Proxy node hostname	Available bootstrap resolver	The node address should resolve even before the proxy connects

In Xray domain rules, geosite is a domain list and geoip is an IP list. Domain rules can match names directly; some IP-based checks may require resolving the name first. Before changing DNS behavior, understand when your current rules trigger resolution so you don’t add unnecessary local lookups just to match an IP rule.

Check rule priority. A broad direct-connection rule placed too early may take precedence over a test domain that should use the proxy.
Check outbound tags. DNS and traffic outbounds in custom configurations must reference tags that actually exist. Don’t copy example names as-is.
Distinguish the two meanings of “global.” Routing all traffic through the proxy affects only traffic that reaches the core. It does not automatically capture apps that bypass the system proxy.
Preserve internal DNS. Public resolvers may not be able to resolve internal domains required by a workplace network. Keep necessary exceptions before routing all queries remotely.

For a refresher on the basics, see the split routing guide and the proxy modes guide. Changing subscription groups won’t fix DNS routing automatically. After updating a subscription, check that the selected node and rules still work together as intended.

Check for Browser, TUN, and IPv6 Bypasses

The system proxy is mainly for apps that read the proxy settings. A browser may use its own Secure DNS, while other programs may query the system resolver directly or send DNS requests themselves. If a test still looks wrong with the system proxy enabled, don’t assume the node is faulty. First check whether the requests are actually using a path managed by v2rayN.

Control browser Secure DNS. In Edge, open “Settings” → “Privacy, search, and services” → “Security,” then check the options for “Use secure DNS.” For troubleshooting, you can temporarily turn off browser-level Secure DNS to reduce variables. If it’s managed by an organization policy, don’t bypass the policy; ask your administrator to confirm the DNS route.
Test TUN if needed. To handle apps that ignore the system proxy, run v2rayN as an administrator and enable “Enable Tun” in the interface. Check the virtual adapter, default route, and DNS capture settings. TUN behavior depends on the core in use; an enabled toggle alone doesn’t prove that all queries are captured.
Check IPv6. An AAAA query is not itself a leak. Check whether IPv6 traffic and DNS requests follow the same proxy policy. Handling IPv4 while leaving an uncaptured IPv6 route can result in inconsistent exits.
Check for other network layers. Other virtual adapters, workplace tunnels, or security software may change routing and DNS priorities. Record the current setup and test one change at a time; avoid changing several network configurations at once.

If only system proxy mode behaves unexpectedly, while a correctly configured TUN mode gives the expected results, first check whether the app is bypassing the system proxy. If both modes behave unexpectedly, check the DNS outbound, bootstrap resolution, and browser-level DNS. See the TUN configuration guide for details on what TUN captures.

Commands and Logs: Tell Resolution Failures from Routing Issues

Open PowerShell to check the DNS configuration for each network adapter, then clear the system cache. These commands inspect Windows DNS settings; they do not automatically use v2rayN’s HTTP or SOCKS proxy. A successful command only confirms that the relevant system resolution path works—it does not replace a browser DNS leak test.

Get-DnsClientServerAddress
ipconfig /flushdns
Resolve-DnsName example.com -Type A
Resolve-DnsName example.com -Type AAAA

ipconfig /flushdns clears only the Windows DNS client cache, not every browser or core cache. Before and after testing, reopen the browser test page. Restart the core after changing its DNS settings. No errors in the logs alone do not prove that DNS requests aren’t bypassing the intended route.

Error: no such host

Cause and fix: The hostname in the log could not be resolved. The node hostname may be misspelled, or the resolver may be unavailable. Check which domain the error refers to, then review bootstrap DNS and the current resolver.

Error: context deadline exceeded

Cause and fix: The operation exceeded its time limit. If the same log entry points to a DNS request, first check that the resolver is reachable and that its outbound route is correct. This error can also occur while connecting, so don’t assume it’s a DNS issue without checking the context.

Error: connection refused

Cause and fix: The target port refused the connection. If your configuration points to a local DNS service, check that the service is running and that its listening address and port match. Don’t enter a proxy listening port as a DNS port.

Bottom line: Use Tests to Verify the Route and Logs to Diagnose Failures

If websites load but the resolver isn’t the one you expect, check traffic capture and split routing. If a domain won’t resolve, first check the resolver, node hostname, and bootstrap path. Don’t keep switching nodes at random between these two types of problem.

FAQ and Final Checks

Why does DNS still use my local ISP after my exit IP changed?

First make sure the test domain isn’t matched by a direct-connection rule, then check whether the browser resolved it locally before the proxy. Set the browser’s Secure DNS options, verify the remote DNS outbound under “Settings” → “DNS Settings,” restart the core, and test again.

Websites stopped loading after I switched to DoH. Should I try another address?

Restore the last working configuration first. Check whether the DoH hostname can be resolved during bootstrap and whether remote DNS depends on a node connection that isn’t established yet. Treat an unreachable resolver and an unresolved node hostname as separate issues.

The test found three DNS addresses. Does that mean there were three leaks?

No. Multiple addresses may belong to the same recursive DNS provider. Compare the provider, direct-connection baseline, and expected configuration. Investigate further only if you find an unexpected DNS route; the number of addresses alone is not enough to draw a conclusion.

If TUN is enabled, can I ignore the browser’s DNS settings?

No. Browser-level DoH may pass through TUN as ordinary HTTPS traffic while still using a different DNS provider. If you want all queries handled by a specific resolver, coordinate the browser’s Secure DNS settings with the core’s DNS policy, and verify the IPv6 route too.

After setup, keep a record you can use to roll back: the current node, core type, system proxy or TUN status, remote and direct DNS settings, routing rule names, and results from two rounds of testing. Don’t share subscription URLs, node credentials, or full logs containing sensitive domain names.

Confirm that proxy-routed domains use the expected resolver and that direct and internal domains remain accessible.
Restart v2rayN and confirm the settings still work—not just in the current browser session.
Retest after switching between Wi-Fi, Ethernet, or a hotspot, paying particular attention to each adapter’s DNS and IPv6 settings.
Retest after updating the client, switching cores, or changing routing templates. Don’t assume results from the previous setup still apply.