How to Detect DNS Leaks: Practical V2Ray DNS Leak Prevention

First, confirm that the result is really a DNS leak

DNS translates domain names into IP addresses. When a browser visits a website, it usually queries a resolver first, then connects to the server returned by that resolver. A working proxy does not mean the query also used the proxy: web traffic may leave through the node while DNS requests still go to the router, the ISP resolver, or a server configured by the operating system.

You cannot identify a leak merely by counting the DNS addresses shown on a test page. Public resolvers often use global routing, so the apparent exit city may differ from the node's city; the resolver name may belong to a public provider or its upstream network. The key question is whether a local ISP resolver seen before connecting still appears afterward, and whether queries bypass the intended proxy or encrypted path.

1. Fully exit the client and record the current public exit region, the number of DNS providers, and the resolver regions.
2. Start the client, choose a node with a clearly identified location, enable the system proxy or TUN, and refresh the test page.
3. Test again with a new domain to avoid having the browser or system DNS cache return an old result.
4. Compare both results rather than just the IPs. Check whether the provider name, network ownership, and region still point to the local access network.

Why DNS Can Bypass a V2Ray Connection

A system proxy mainly handles application connections that support HTTP or SOCKS proxies; it does not automatically capture every DNS packet sent by the operating system. Some applications call the system resolver to obtain an IP before handing the connection to the proxy, so the query has already left through the physical network adapter. Others support remote resolution through SOCKS and pass the domain directly to the proxy; the results are not equivalent.

Browser secure DNS, router-provided DNS, enterprise network policies, and virtual network adapter settings can each create a separate resolution path. Troubleshooting requires separating who sends the query, who receives it, and which outbound path carries the packet. Changing one DNS address without changing the query's outbound path usually does not solve the routing problem.

Four Common Bypass Paths

• System proxy handles web connections only: System DNS still sends UDP queries to the router's port 53.
• Browser resolves independently: The browser's secure DNS ignores the client's built-in DNS rules, so its test results may differ from those of other applications.
• Incomplete TUN coverage: Physical adapter priority, excluded routes, or application bypass settings can keep some port 53 traffic out of the virtual adapter.
• The node hostname must be resolved first: Before connecting to a node, the client needs the server's IP. This bootstrap lookup usually occurs before the tunnel is established, so it needs a trusted direct resolver configured separately.

Configure Built-in DNS and Routing in v2rayN

The steps below use the v2rayN 7.12.5 and Xray-core 25.6.8 test interface. Menu names may change between minor releases, but the order remains the same: choose the resolvers, route local and remote domains through the appropriate rules, then inspect the generated configuration and core logs. When using only the system proxy, v2rayN's local SOCKS entry is usually 127.0.0.1:10808; an application must support proxies or be controlled by the system proxy to use it.

1. Open “Settings” → “DNS Settings” and back up the current contents before editing, so you can restore them if something goes wrong.
2. Set the remote resolver to an address that supports encrypted queries, such as https://1.1.1.1/dns-query, and make sure rules send its connection through the proxy outbound.
3. Keep a separate resolver for domains in mainland China, such as 223.5.5.5, and use geosite:cn with geoip:cn to limit the matching scope.
4. Open “Settings” → “Parameter Settings”, confirm that the core type is Xray, and check that the routing mode does not force every DNS connection through the direct outbound.
5. Save and restart the core. In the logs, look for resolution timeouts, an unresolvable node hostname, or a rejected DNS outbound.

Users with custom configurations can use the structure below to understand built-in DNS routing. It is not a universal file that every subscription can overwrite directly. The graphical interface may merge user settings with subscription-generated entries, so verify the final generated configuration rather than relying only on the input fields.

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"],
        "expectIPs": ["geoip:cn"]
      },
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": ["geosite:geolocation-!cn"]
      }
    ]
  }
}

queryStrategy determines which address type to query first. If you only need IPv4, UseIPv4 can reduce uncertainty on dual-stack networks. Choose a strategy that includes IPv6 only after confirming that the network, node, and destination all support it reliably. This setting does not decide whether the DNS connection uses the direct or proxy outbound; routing rules still control that.

Handle Remote DNS in v2rayNG

On Android, the key difference is that VPN mode uses a virtual network interface to capture more traffic. The steps below use v2rayNG 1.10.31 with the Xray core: open “Settings” → “VPN Settings” and check “Remote DNS”, “Local DNS”, and whether Local DNS is enabled. Labels may vary slightly by translation; follow the purpose of each field.

1. In “Settings” → “VPN Settings” → “Remote DNS”, enter the resolver intended for proxied domains, such as https://1.1.1.1/dns-query.
2. Keep a directly reachable resolver under “Local DNS”, such as 223.5.5.5, for mainland-China rules and the lookups required before connecting to a node.
3. Open “Settings” → “Routing Settings” and confirm that the rules for mainland-China domains appear before the fallback rule, so they are not matched by a global proxy rule first.
4. Disconnect and reconnect the VPN instead of merely returning to the main screen; the old virtual interface and DNS cache may remain active.
5. Test with the browser and another network-enabled application separately. If only the browser behaves unusually, check the browser's own secure DNS settings.

v2rayNG uses the Xray core, and both VMess and VLESS nodes can work with built-in DNS and routing rules. The protocol name itself does not prevent DNS leaks; the result depends on VPN coverage, DNS configuration, and outbound rules. v2flyNG follows the same troubleshooting approach when using the v2fly core, but supported configuration fields depend on what the client actually generates. Do not copy extensions that apply only to Xray.

What Else to Check in TUN Mode

TUN mode uses a virtual network adapter to capture applications that do not support the system proxy, making it better suited to handling DNS consistently. But enabling the switch is not the end. Virtual-adapter route priority, DNS hijacking rules, LAN bypass scope, and IPv6 paths must align. If the physical adapter still has usable IPv6 DNS, an IPv4 test may look normal while some queries leave through another path.

TUN Checklist

• Confirm that the client has sufficient privileges to create the virtual adapter and that the logs show no route installation failure.
• Check that both UDP and TCP traffic on port 53 are handled; do not verify only the more common UDP queries.
• Make sure LAN bypass rules cover only private networks; do not mistakenly classify public DNS addresses as direct network ranges.
• If IPv6 is not being used for now, keep the client's DNS query strategy consistent with the system network layer rather than disabling it on only one side.
• If FakeDNS is enabled, confirm that domain sniffing and routing rules can map the synthetic address back to the original domain.

FakeDNS first returns a reserved address, while the core stores a mapping between the virtual IP and the original domain. This helps capture connections that carry only a destination IP and keeps domain-based routing effective, but it is not the same as completing remote resolution. Before reaching the destination, the core still has to obtain the real address according to the rules. Mapping-pool conflicts, overly long application caching, or disabled sniffing can all cause connection failures.

Use Core Logs to Locate DNS Errors

A test page shows the result; core logs are better for finding the cause. Temporarily set the log level to info or warning, reconnect, and visit a domain that has not been opened before. Focus on whether the error occurs while resolving the node address, connecting to the remote resolver, or sending traffic outbound after obtaining the destination address.

If the logs show no DNS errors but tests still reveal local resolvers, the problem is probably outside the core: the application may use the system resolver, the browser may create an independent connection, or DNS packets may not enter TUN. Compare system-proxy and TUN modes instead of repeatedly switching between VMess and VLESS nodes.

How to Verify the Fix

Final verification should cover at least three states: the first query, repeated queries, and recovery after disconnecting. The first query checks the actual resolution path, repeated queries show cache stability, and reconnect recovery can reveal a virtual adapter or routing rule that failed to reload.

1. Exit the client and record the baseline, including the exit region, DNS network ownership, and resolver count.
2. Clear system and browser DNS caches, start the client, and visit a domain that has never been tested.
3. Run three consecutive tests, at least 10 seconds apart, and record whether a local ISP resolver reappears.
4. Disconnect for 15 seconds, reconnect, and run three more tests to confirm that the configuration remains active after reconnection.
5. Switch once between Wi-Fi and mobile data, reconnect, and check whether bootstrap DNS and TUN routes adapt to the network change.

The goal is not to make the test page display exactly one address forever, but to make the resolution path explainable and repeatable. DNS routing is complete only when mainland-China domains use direct resolution according to the rules, remote domains use the designated resolver and outbound, and node hostnames have an independent bootstrap path.