A proxy connection showing as active only proves that some application traffic has entered the V2Ray or Xray core. Before a connection is established, a domain usually has to be resolved to an IP address. If the system network's default DNS still handles that step, the query record may leave independently through the local network. The key to troubleshooting a DNS leak is not repeatedly switching nodes, but identifying who sends the query, which entry point it uses, and which resolver group ultimately answers it. This guide uses v2rayN 7.14.x and v2rayNG 1.10.x as its baseline. Menu labels may vary slightly in older versions, but the troubleshooting order remains the same.

Quick overview

This guide is for users whose proxy works but a leak-test page still shows local resolvers, whose domain access breaks after rule-based routing, or whose DNS results change when switching mobile networks. After baseline testing, core DNS configuration, port 53 interception, and retesting, you can determine whether the leak comes from the browser, operating system, routing rules, or client mode.

What is a DNS leak? Start with the domain-resolution path

When you access a domain, the application may resolve it itself, pass it to the system resolver, or send the complete domain to an HTTP or SOCKS proxy. These paths determine whether the DNS query enters the proxy core. In system-proxy mode, only traffic from applications that follow the system proxy settings is captured. Background processes, some command-line tools, and applications that send UDP queries on their own may still access the DNS configured on the network interface directly.

Application submits domain System selects resolver Core matches rules DNS outbound query Target address returned

A DNS leak is not the same as seeing multiple resolvers on a test page. Public DNS services often use anycast nodes, so one query may appear to come from several locations. When encrypted DNS is enabled in the browser, it may also bypass the operating system settings and communicate directly with the browser's chosen resolver. What matters is whether the results include a resolver operated by the current broadband or mobile network provider, whether the resolver sets before and after connecting the proxy are identical, and whether plaintext UDP or TCP port 53 traffic leaves the local interface.

The dns object in V2Ray and Xray configurations handles resolution inside the core, but it does not automatically take over every DNS request generated by the operating system. The built-in DNS settings can work only after a domain has entered the core, or when system DNS traffic is captured by TUN, a transparent inbound, or a similar mechanism. This is the most common reason that adding DNS settings produces no change in test results.

Bottom line: verify the capture scope before changing DNS addresses

System-proxy mode handles only connections that follow the proxy settings. To cover more applications, first verify whether TUN mode captures DNS, then configure the built-in resolvers and routing rules.

Establish a baseline: one test is not enough

Before testing, disable any browser security DNS feature that may operate independently, and temporarily turn off other network proxy tools. Keep the current network connection, and record the system DNS addresses, the v2rayN or v2rayNG mode, the selected node, and the routing mode. This lets you distinguish the browser's own results from those produced after the client takes over.

  1. Record the direct-connection result

    Fully exit the client, open a DNS leak-test page, and run both the standard and extended tests. Record the number of resolvers, their networks, and their countries or regions. Run the extended test twice in succession.

  2. Enable the system proxy

    In v2rayN 7.14.x, choose “System Proxy” → “Auto Configure System Proxy”. Keep the default local SOCKS port 10808 and HTTP port 10809, then repeat the test in a new browser window.

  3. Switch to TUN mode

    Go to “Settings” → “Parameter Settings” → “TUN Mode Settings”, confirm the DNS hijacking scope, and enable TUN. Reconnect the node, wait 10 seconds, and run the same test again.

  4. Compare all three data sets

    Compare the direct-connection, system-proxy, and TUN results. If local resolvers still appear in system-proxy mode but disappear in TUN mode, the issue is usually the system DNS capture scope rather than the node itself.

  5. Run a disconnected retest

    Close the client and refresh the test page to confirm that the system network returns to its baseline result. If abnormal DNS settings remain after exit, check for manually configured addresses left on the network adapter, then disconnect and reconnect the network once.

A single extended test may generate 20 to 50 queries, which public resolvers distribute among multiple nodes. A more reliable approach is to run three rounds with about 15 seconds between rounds and treat repeatedly appearing resolvers as the stable result. If one different address appears in only one round, first rule out caching, network changes, and resolver load balancing rather than immediately changing the entire configuration.

You can also use the operating system's built-in network tools to check port 53. During the test, open only one leak-test page and watch for UDP or TCP connections targeting port 53 from the physical network adapter. If direct port 53 traffic continues after TUN is enabled, an application may be bypassing capture, or the DNS hijacking rules may not cover the relevant protocol family.

Test state Example result What to check first
Direct connection 3 local network resolvers, 42–68 ms Baseline data; keep it for comparison
System proxy The same 3 resolvers still appear The browser or system DNS did not enter the core
TUN mode Only the configured public resolvers appear, 85–120 ms DNS capture and proxy outbound routing are working
TUN mode Public and local resolvers appear together A bypass query exists, or one protocol family is not covered

Bottom line: three-way comparison beats a single screenshot

When direct, system-proxy, and TUN results are available together, you can tell whether the issue is in the proxy capture layer or the DNS outbound layer, instead of mistaking multiple public resolver nodes for a leak.

v2rayN fixes: configure built-in DNS and routing together

The v2rayN desktop client usually runs the Xray core. Before fixing anything, confirm the core type and configuration source. Regular subscription nodes use a client-generated runtime configuration, while custom JSON is maintained directly by the user. Do not edit the same field in both places: a subscription update or core restart may overwrite manual changes with a newly generated configuration.

  1. Confirm the core type

    Open “Settings” → “Parameter Settings” → “Core Type” and confirm that the current node uses Xray. Save, restart the core, and check the name and version of the actually loaded core at the top of the log.

  2. Check local ports

    In “Settings” → “Parameter Settings” → “Basic Settings”, check whether another program is using SOCKS port 10808 or HTTP port 10809. A port conflict can cause the browser to fall back to a direct connection.

  3. Set the domain strategy

    Go to “Settings” → “Routing Settings” and inspect the domain strategy in the active rule set. Use IPIfNonMatch when rules need to match based on resolved IPs; when routing only by domain rules, do not unconditionally resolve every domain in advance.

  4. Enable DNS capture

    Go to “Settings” → “Parameter Settings” → “TUN Mode Settings”, enable DNS hijacking, and confirm that UDP 53 is covered. Save, exit, and restart the client so the virtual adapter and routing table are rebuilt completely.

  5. Check the runtime log

    Connect to a node, open the log, and visit a domain that has not been resolved before. Normally, the log should show the domain entering routing evaluation; repeated local-resolution timeouts or target-address lookup failures should not appear.

The structure below illustrates the key fields for built-in DNS and should not be used to overwrite the full configuration generated by the client. queryStrategy controls the returned address family, while servers defines the candidate resolvers. If the current network has unstable IPv6 routing, start with UseIPv4 to establish a reproducible baseline, then adjust the address-family strategy to suit actual needs.

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

Adding server addresses alone is not enough. DNS requests sent by the core also need an explicit outbound path; otherwise, encrypted DNS connections may still go direct under the default rules. For configurations that route domains inside and outside mainland China differently, make sure the domain or address of each specific resolver matches the intended outbound, and place the final DNS rule before any broad rule that could intercept it first.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "network": "udp",
        "port": 53,
        "outboundTag": "proxy"
      }
    ]
  }
}

Error: failed to find an available destination

Cause and fix: The outbound server domain could not be resolved, or the DNS outbound was sent back to itself by an incorrect rule. Keep a reachable bootstrap resolution path for the node server address, then restart the core.

Error: lookup example.com: no such host

Cause and fix: The current resolver returned no result, the domain rule is incorrect, or a failed lookup remains cached. Check the spelling, switch to a reachable resolver, and restart the core to clear the cache for this run.

Error: context deadline exceeded

Cause and fix: The DNS query or encrypted DNS connection did not complete before the timeout. Check outbound routing for port 443, the system clock, and current network reachability, then compare direct and proxy-outbound latency.

v2rayNG and v2flyNG: check VPN capture on mobile networks

v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. Their supported DNS fields and defaults are not identical, so do not copy a desktop custom configuration and enable it unchanged. On mobile, first confirm that the VPN connection is actually established, then check local DNS, remote DNS, domain strategy, and the per-app proxy scope.

  1. Record the network type

    Test separately on Wi-Fi and mobile data. After switching networks, stop the connection and start it again. Do not reuse the leak-test tab from before the switch, as cached results may contaminate the new data.

  2. Check VPN settings

    In v2rayNG 1.10.x, open “Settings” → “VPN Settings”, confirm that VPN mode is active, and check whether the per-app proxy list excludes the browser running the test.

  3. Check DNS entries

    Go to “Settings” → “VPN Settings” → “DNS Settings” and inspect local and remote DNS. Choose a remote DNS address reachable on the current network, then stop and restart the connection after changing it.

  4. Check the domain strategy

    Go to “Settings” → “Routing Settings” and inspect the domain strategy and predefined rules. If the rules rely on the destination IP, confirm that the resolved result can be used by the relevant rule and that the domain is not resolved through the wrong outbound first.

  5. Retest on both networks

    Run three rounds of extended testing on each network, with 15 seconds between rounds. If local resolvers appear only on mobile data, check the VPN rebuild after the network switch and IPv6 routing first.

Per-app proxying is a frequent omission on mobile. If the browser running the test is not on the proxy list, both the page and its DNS queries access the network directly, so the result naturally remains local. Conversely, if the browser is covered by the VPN while another background app is excluded, that app's DNS requests may continue using the default network. System-level observation will then show bypass traffic, although the browser's test page may not reveal queries from the background app.

When v2flyNG uses the v2fly core, follow the fields actually accepted by that core. If an imported subscription contains only the node protocol, address, and port, DNS and routing are usually still controlled by the client's local settings; a simple node link does not automatically provide a complete policy. When migrating a configuration, verify the VMess or VLESS node parameters, transport settings, DNS, and routing rules separately rather than comparing only node names.

  • Wi-Fi works, mobile data fails: Rebuild the VPN connection and check IPv6 reachability and whether resolvers supplied by the mobile network are still being used.
  • Local resolvers appear on every network: Check whether the browser is excluded, whether remote DNS is working, and whether the client is in VPN mode.
  • Tests look normal but some domains fail: Check the domain strategy, DNS split-routing rules, and the resolver's response for the target domains.
  • Node IP connects but node domain fails: Give the server domain an independent, reachable bootstrap resolver so establishing the proxy does not create a circular dependency.

Post-fix validation: check resolution, routing, and failure fallback

After fixing the issue, do not rely on a single test page. Full validation should cover cold start, network switching, node switching, and client exit. Cold start checks bootstrap resolution; network switching checks VPN and routing-table reconstruction; node switching checks resolution paths for different server addresses; exiting the client confirms that system settings are restored.

Clear browser cache Restart proxy core Run extended test Monitor port traffic Switch networks and retest Exit and confirm recovery

Keep a short validation record. An example baseline could read: v2rayN 7.14.x, Xray core, TUN mode, remote DNS over HTTPS, three consecutive test rounds with no local network resolvers, and no sustained direct UDP 53 traffic on the physical adapter during observation. Recording the exact state is more useful than simply writing “fixed” when comparing changes caused by a client upgrade or rule adjustment.

Validation item Pass condition What to check after failure
Cold-start resolution The node domain resolves and the connection is established within 10 seconds Bootstrap DNS, server domain, and outbound loops
Continuous testing Results remain stable for 3 rounds with no local network resolvers Browser secure DNS, system cache, and bypass applications
Port 53 observation No sustained direct DNS queries from the physical adapter TUN capture scope, UDP, and TCP rules
Network switching Resolution results match those before the switch after reconnecting VPN rebuild, IPv6 routing, and remote DNS reachability
Exit recovery System DNS returns to the pre-change baseline Manual DNS on the network adapter and leftover proxy settings

Symptom: tests look normal, but nslookup still shows the local DNS

Cause and fix: Browser traffic enters the proxy while the command-line query calls the system resolver directly. The two tests use different entry points, so observe the command-line query again in TUN mode to see whether it is captured.

Symptom: the first visit times out after switching nodes

Cause and fix: The new node's server domain depends on a proxy DNS path that has not been established, creating a startup-order problem. Configure a directly reachable bootstrap resolver for the server domain and avoid sending that query back through an unconnected proxy outbound.

If the results remain unstable, narrow the scope layer by layer: application entry point, system capture, core DNS, DNS outbound, and final routing. Do not change remote DNS, domain strategy, routing rules, and operating mode at the same time. Change one item per iteration and repeat the same test so you can identify which layer actually fixed the issue.

Frequently asked questions

Two public DNS addresses appear on the test page. Is that a leak?

Not necessarily. Public resolvers may return multiple nodes through anycast or load balancing. Check the networks that own the addresses and compare them with the direct-connection baseline. If no local network provider resolver appears and there is no direct port 53 traffic, the number of addresses alone usually does not indicate a leak.

Why do local resolvers still appear after enabling encrypted DNS?

Encrypted DNS describes only how queries are transported; it does not mean every application uses it. The browser, operating system, and proxy core may each have a separate resolution path. First confirm that the test browser enters the proxy, then check whether TUN captures system DNS.

Can system proxy mode handle all DNS traffic by itself?

Not in every case. Applications that pass the complete domain to the proxy can use remote or core resolution, but applications that call the system resolver directly may bypass the system proxy. To cover more applications, use a mode that captures the relevant traffic and retest.

Do VMess and VLESS determine whether DNS leaks?

No. VMess and VLESS define the proxy protocol between the client and server. Whether DNS enters the core mainly depends on the application's resolution method, the client mode, built-in DNS, and routing rules.