V2Ray DNS Leak Test: Prevent DNS Leaks in v2rayN

1. Check the DNS route, not just the location

DNS translates domain names into IP addresses. When using a proxy, web traffic and DNS queries can take different routes: your browser may access websites through the proxy while your operating system still sends domain lookups to your router or internet provider. If those queries are supposed to use the proxy, this unexpected direct connection is the DNS leak to investigate.

v2rayN is a desktop client, and DNS behavior depends on the selected core, generated configuration, app-specific settings, and system network. Changing a single remote DNS address won't control every app, and enabling the system proxy won't automatically capture all UDP traffic. Browsers can also use built-in encrypted DNS that bypasses the system resolver, creating a third route.

2. Run an online test and record a baseline with the proxy off

Open https://www.dnsleaktest.com/ and run the Standard or Extended test. The test asks your browser to look up a set of temporary domains, then shows the recursive resolvers that query their authoritative DNS servers. These are usually not the DNS addresses configured on your computer's network adapter, and they don't reveal the full network path between your computer and the resolver.

1. Record a baseline

   Temporarily turn off TUN, then select “Clear system proxy” from v2rayN's “System Proxy” menu. Run the test and note the time, web exit IP, resolver IPs, and provider names. Traffic will use your current network directly during this test, so proceed only if that is acceptable.

2. Keep the browser consistent

   Use the same browser profile and network. In the browser's settings, search for “Secure DNS” or “DNS over HTTPS” and note the current setting. To verify the client route first, you can temporarily turn off the browser's custom encrypted DNS, then test that feature separately afterward.

3. Enable the proxy

   Select a known working node, then choose “Automatically configure system proxy” from “System Proxy.” First confirm that the test site's web exit IP has changed. If it hasn't, check the system proxy, browser extensions, and bypass rules.

4. Run the test again

   Run the Standard test first, then the Extended test. Repeat each mode at least twice and compare the results with your baseline. Reload the test page after switching modes so you don't mistake an earlier result for a new one. Save screenshots for comparison.

3. How remote and local DNS work in v2rayN

Before making changes, note your v2rayN version, active core, routing mode, and current DNS values, and back up your configuration. In many versions, open the relevant page under “Settings” → “DNS Settings”; configurations are often core-specific. Field names and layouts vary by version. “Remote DNS” and “local DNS” below refer to their roles, so use the options shown in your version and don't paste one core's configuration format into another.

• Remote DNS: Used to resolve domains that should go through the proxy. If you enter a DoH address such as https://1.1.1.1/dns-query, make sure the field supports DoH and that connections to the service use the intended outbound route.
• Local or direct DNS: Used for domains routed directly and some initial lookups. Choose a trusted resolver that works on your network. For example, 223.5.5.5 is a specific public resolver address, but whether it's suitable depends on connectivity and your privacy requirements.
• Node hostname resolution: The node server's IP usually needs to be resolved before connecting. Requiring every lookup to go through a node that isn't connected yet can create a startup dependency loop. Use a separate resolution method supported by your core instead of forcibly removing all direct lookups.
• DNS outbound rules: These determine whether DNS connections go direct or through the proxy. Encrypted DNS protects the contents in transit, but if the DoH connection itself goes direct, the resolver still sees your local public IP. Encryption and proxy routing are separate goals.

Save changes one at a time

Open “Settings” → “DNS Settings” and select the page for the core you're using. Check what the remote and direct resolvers are for. Enter the addresses above only if the fields support them, then check whether your routing rules force connections to the DNS service to go direct. Save, restart the service or core, check the logs for configuration errors, and run the online test again. If you only see a custom configuration text box, verify the field syntax for that core instead of adding options based on similar names.

4. Check DNS hijacking and IPv6 in TUN mode

The system proxy mainly serves apps that respect proxy settings. TUN uses a virtual network interface to capture traffic and is better suited to apps that ignore the system proxy, but enabling TUN alone doesn't guarantee that all DNS traffic is captured. Check TUN routing, DNS interception rules, and core logs as well.

1. Find the active TUN settings. In many desktop versions, look under “Settings” → “Parameter Settings” for “Tun Mode Settings”; some versions have a separate page. Note the current values for auto-route, strict route, and DNS-related options. Change only fields explicitly provided by your version.
2. Confirm standard DNS interception. If the page offers DNS hijacking or DNS interception, make sure it covers the UDP/TCP 53 queries you expect. This directs standard DNS requests to the core's DNS flow; it doesn't turn arbitrary encrypted connections into DNS.
3. Handle encrypted DNS separately. DoH typically uses TCP 443 and may also use UDP 443 with HTTP/3. DoT typically uses TCP 853. Intercepting port 53 won't capture these connections; app settings and routing rules still matter.
4. Check the IPv6 route. Check whether the system has an IPv6 DNS server, whether TUN has IPv6 routes configured, and whether the proxy outbound supports the destination. Looking up an AAAA record is not the same as sending the query over IPv6, so disabling AAAA records alone won't tell you whether the issue is fixed.
5. Test after switching networks. Save the settings and test on your current network first, then reconnect and test again on the networks you actually use, such as wired and wireless. Switching networks can update system DNS and the default route, so an old result doesn't replace a fresh test.

If the network stops working after changing TUN settings, turn off TUN first to restore the baseline, then check permissions, the virtual interface, and route conflicts. Disabling IPv6 can be a temporary comparison test, but it changes system network behavior and isn't a general fix. If your setup needs IPv6, configure DNS interception and routing properly.

5. Use system commands to distinguish caching, proxy, and DNS failures

The examples below use Windows PowerShell. The first set of commands clears the local DNS cache and triggers a system lookup. This tests the system resolution path, not remote DNS in the client. Browsers and cores may have their own caches, so you may also need to fully close the browser and restart the core.

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

Next, use a SOCKS-capable curl command to test a connection that sends the target hostname to the proxy for resolution. The example assumes v2rayN's actual SOCKS or mixed inbound port is 10808. Before running it, check “Settings” → “Parameter Settings” for the local listening port and change the value if needed. The IP address 127.0.0.1 connects to the local proxy without requiring a separate lookup for the proxy hostname.

curl.exe --socks5-hostname 127.0.0.1:10808 --connect-timeout 10 -I https://example.com/

--socks5-hostname sends the target hostname to the SOCKS proxy for resolution; --socks5 usually resolves the target locally instead. Success with the first command only confirms that this explicit proxy route works. It doesn't prove that your browser or background services are free of DNS leaks.

6. Retest checklist: preserve routing and verify the expected exit

After making changes, record results separately with the proxy off, with only the system proxy, and in TUN mode. Use the same browser settings for each and note resolver providers, not just countries or regions. If the results don't match expectations, revert the most recent change and test again.

• Browser: Requests that should use the proxy exit where expected, and DNS results match the configuration. If you turn Secure DNS back on, run a separate test.
• Terminal: An explicit SOCKS connection succeeds, and the system DNS test returns a reasonable result. Record these as separate routes, not as one.
• Routing: Direct-routed domains remain accessible, and proxy-bound domains don't fall back to an unexpected direct route when remote resolution fails.
• Logs: No recurring DNS timeouts, connection loops, or configuration load failures. You can temporarily increase log verbosity to investigate, then restore the usual level.
• Configuration notes: Record the version, core, DNS addresses, TUN state, and test date. Before asking for help publicly, redact subscription URLs, node credentials, and any public IPs you don't want to share.

7. DNS leak prevention FAQ