DNS Leak Testing and Fixes: v2rayN and v2rayNG Anti-Leak Configuration Guide

A connected proxy node does not mean every domain lookup is traveling through the proxy chain. Before opening a website, browsers, system services, and regular apps typically send the domain to a DNS resolver. If the default resolver on the current network still handles that request while the webpage traffic later leaves through VMess, VLESS, or another proxy outbound, the result is the familiar DNS leak. During troubleshooting, treat “who resolves the domain” and “where the webpage data exits” as two separate paths. Checking only the exit address is not enough.

DNS Leak Paths and How to Interpret Results

A typical web request can be divided into four stages: domain lookup, address resolution, route matching, and proxy outbound. A system proxy mainly handles traffic from apps that support proxy settings; it does not necessarily take over system queries sent to UDP port 53. TUN mode can capture a wider range of connections at the virtual network adapter layer, but it still needs explicit DNS rules. Otherwise, queries may be sent to a direct connection by mistake or loop between local and remote DNS.

The key question is whether the resolver belongs to the path defined by your current configuration. For example, if the client explicitly uses remote DNS but a test page repeatedly shows resolvers provided by your current broadband or mobile network, investigate further. By contrast, results showing multiple cities do not automatically indicate a leak: public DNS services may use anycast nodes, and a test site may identify the same service as different data centers.

• System proxy scenario: Browser traffic may pass through a local HTTP or SOCKS port, while UDP port 53 queries from other apps can still go directly to the network.
• TUN scenario: Check the virtual adapter, DNS hijacking, routing rules, and remote DNS together; enabling the switch alone is not enough.
• Browser encrypted DNS: The browser’s built-in DNS settings may bypass the client configuration, making test results differ from the system setup.
• Cached results: The system, browser, and client may all retain old answers, so refreshing once immediately after changing the configuration is rarely conclusive.

Online Testing: Establish a Baseline, Then Compare Through the Proxy

Before testing, close other proxy programs that could alter the network path and leave only the client under test running. Prepare two results: a baseline with the proxy disconnected and a comparison after connecting to a node. Run both the standard and extended tests; extended tests usually send multiple batches of random subdomain queries, making directly connected resolvers easier to detect.

1. Disconnect v2rayN or v2rayNG and record the current exit address, DNS service name, country or region, and number of detected servers.
2. Clear the DNS cache, then close and reopen the browser so old query results are not reused.
3. Connect to a stable node, confirm that ordinary websites load, and run the first standard test.
4. Run the extended test and wait for all queries to finish. Do not judge the result from only the first record shown when the page opens.
5. Test again after 30 seconds and compare whether both rounds are consistent. If one old record appears occasionally, clear the cache and repeat the test.

A reproducible test record should include the time, client version, operating mode, and result count. For example: v2rayN 7.15.4 in system proxy mode detected two local resolvers while disconnected, and the same two resolvers still appeared after connecting. After switching to TUN and restarting the core, both extended test rounds showed only one group of remote DNS services. This before-and-after comparison is more useful than a single screenshot.

v2rayN: Remote DNS, DNS Outbound, and TUN Configuration

The steps below use the v2rayN 7.15.4 interface as an example. Menu labels may vary slightly between 7.x releases, but the goal is the same: assign remote resolvers to the Xray core, route DNS queries through a dedicated outbound, and enable TUN when you need to cover apps that do not understand proxy settings. Before making changes, save the working configuration through 「Servers」→「Export Selected Server」 or the configuration backup feature.

Step 1: Check the Local Listener and System Proxy

1. Open 「Settings」→「Parameter Settings」 and note the local mixed-listener port. The common default is 10808; if you changed it, follow the value shown in the interface.
2. Make sure the port is not occupied by another program, then return to the main window and select 「Auto Configure System Proxy」.
3. Open the core log and confirm that the inbound listener has started without errors such as bind or access denied.
4. Complete one test in system proxy mode first. If the browser works but other apps still leak DNS, move on to TUN configuration instead of changing every option at once.

Step 2: Specify Remote Resolvers

Go to 「Settings」→「DNS Settings」 and select the Xray DNS configuration currently in use. Remote DNS can use an address that supports encrypted queries or a regular IP resolver; the important point is that routing must send those queries through the intended proxy outbound. The example below illustrates how the fields relate; when saving, follow the structure generated by the client.

{
  "dns": {
    "hosts": {
      "dns.google": "8.8.8.8"
    },
    "servers": [
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "223.5.5.5"
    ],
    "queryStrategy": "UseIP"
  }
}

queryStrategy controls the preferred address family in returned results. Use UseIPv4 when only IPv4 is reliable; in a dual-stack environment, UseIP may be appropriate. If you choose an IPv6 strategy that cannot connect properly, the symptom is usually not “a detected leak” but slower lookups, timeout messages in the log, or some websites failing to load.

Step 3: Check DNS Outbound and TUN

• In the routing configuration, make sure DNS queries do not fall through to the default direct rule. When using a dedicated DNS outbound, point the relevant inbound tag or port rule to that outbound.
• Go to 「Settings」→「Parameter Settings」→「TUN Mode」, enable the virtual network adapter, and restart the core. The first activation may require confirmation of system permissions.
• Make sure DNS hijacking covers port 53 while retaining the resolution scope required by your local network; internal company domains should not be sent blindly to a public resolver.
• Check the log to see whether DNS requests return from the remote server. When finished, clear the cache and run two rounds of the extended test.

v2rayNG: VPN DNS and Local DNS Configuration on Android

v2rayNG takes over traffic through the system VPN interface. Whether DNS enters the tunnel depends on the VPN DNS, local DNS, remote DNS, and routing configuration. The example below uses v2rayNG 1.10.16. Before starting, update the subscription once, select a working node, confirm that the core type is Xray, and record the current routing mode so a failed node is not mistaken for a DNS problem.

Step 1: Enter the VPN DNS

1. Open the top-right menu and go to 「Settings」→「VPN DNS」, then enter the resolver address you plan to use, such as 1.1.1.1.
2. Go to 「Settings」→「Remote DNS」 and configure the server used for proxy-domain lookups. When using an encrypted DNS address, make sure its own hostname can be resolved initially.
3. Check 「Domain Strategy」 against your network environment. When IPv4 is the only reliable option, prefer IPv4 to avoid unreachable AAAA addresses slowing connections.
4. Return to the main screen, disconnect, and reconnect so the VPN interface and DNS parameters are recreated.

Step 2: Decide Whether to Enable Local DNS

「Enable Local DNS」 does not simply keep every query on the device. It lets the client process app requests according to its configuration and then choose a remote or direct resolver. After enabling it, check the local DNS, remote DNS, and domain rules together. Turning on the switch while leaving conflicting routes in place can cause the same domain to be sent to two resolvers in succession.

After saving the settings, disconnect for 10 seconds and start again. Check the core log for recurring DNS timeout messages. If websites load, run two consecutive tests in the same browser, then use another regular app to open a new domain. This confirms that the result is not caused only by the browser’s encrypted DNS.

Post-Fix Verification and Common Problems

Do not keep changing the node, routes, or DNS during verification. Fix one route, one browser, and one test procedure so you can identify which setting made the difference. Record each result with four fields: mode, resolver count, whether a baseline resolver appeared, and time to first load.

1. Clear the system DNS cache. On desktop, reconnect to the network or use the system’s built-in refresh operation; on Android, disconnect the VPN, switch networks once, and reconnect.
2. Close every browser window and reopen it. First visit a domain you have not opened before to avoid using a cached result.
3. Run both the standard and extended tests twice, with at least 30 seconds between rounds.
4. Check the core log for repeated resolution timeouts, query loops, or entries routed to the wrong outbound.
5. Repeat the test after switching to a different network environment. If only one network leaks, investigate its DNS hijacking or IPv6 path.

Configuration Trade-offs: Split Routing, Internal Domains, and Stability

Preventing DNS leaks does not mean forcing every domain through one public resolver. Network storage, printers, and internal company services may depend on local DNS; sending all of them to a remote server will make those names fail to resolve. A safer approach is to group traffic by domain and network: send internal domains to the local resolver, proxy domains to the remote resolver, and use matching routing rules to send each DNS request through a direct or proxy outbound.

• Keep explicit local-resolution rules for internal domains, and do not use broad rules that cover every suffix.
• GeoSite rules match domain collections, while GeoIP rules match destination addresses; neither replaces DNS outbound configuration.
• VMess and VLESS describe how the node connection works; they do not automatically determine who handles system DNS.
• With v2rayN, start by validating individual apps through the system proxy, then use TUN to expand the coverage.
• With v2rayNG, check VPN DNS, remote DNS, domain strategy, and routing mode as one configuration set.

If first-lookup time rises from about 200 ms to several seconds after the fix, check whether remote DNS is taking a roundabout route, whether the encrypted DNS hostname needs an additional lookup, and whether routing has created a loop. A stable setup should meet three conditions: repeatable test results, normal lookup speeds for common domains, and a correct DNS path that can be rebuilt after switching networks. Chasing a particular region on the test page while ignoring timeouts and compatibility can turn a leak problem into a connectivity problem.