How to Detect V2Ray DNS Leaks and Configure the dns Module to Prevent Them

Where Does a DNS Leak Occur?

When you access a domain, an application usually passes it to the system resolver before connecting to the resulting IP address. A system proxy only handles HTTP or SOCKS connections that support proxy settings; it does not automatically rewrite DNS queries sent by the operating system over UDP 53 or TCP 53. So even when web traffic is forwarded through a VMess or VLESS node, domain lookups may still go directly to the resolver configured on the network adapter.

A leak does not necessarily mean the node has failed. More precisely, the application connection goes through the proxy while the DNS request follows an unexpected separate path. If a test page shows your local network provider, router address, or corporate resolver, check the system settings as well. The appearance of a public DNS provider alone does not prove that the query went through the proxy: the same resolver can be reached either directly or through a remote node.

The top-level dns module in an Xray configuration mainly handles domain resolution and matching required by the core itself, such as resolving a node server's domain or obtaining a destination IP for routing rules. Merely defining it in the configuration does not take over every query made by the operating system. Handling DNS submitted by applications to the system requires all three parts to be in place: a listening inbound, system DNS pointing to it, and the corresponding outbound.

A browser's built-in encrypted DNS follows a separate path. It usually connects to a resolver over HTTPS instead of using local port 53. If browser traffic is handled by the system proxy, this connection may go through the proxy; if the application bypasses the system proxy, it may go out directly. During troubleshooting, temporarily disable the browser's secure DNS first, test the system resolution path, then re-enable it and verify the browser settings separately.

Establish a Repeatable DNS Leak Test Baseline

A single test can be affected by caches, browser prefetching, and resolver anycast nodes. A more reliable approach is to run two rounds on the same network, with the same node and browser settings: record the results without DNS interception first, then apply the configuration, clear the cache, and test again. Run at least three queries for random domains in each round so an old cache does not bypass an actual lookup.

1. Record the Network Adapter DNS

   Open PowerShell and run Get-DnsClientServerAddress -AddressFamily IPv4. Record the active adapter name and ServerAddresses. On home networks, the router address is common; public networks may also provide two resolver addresses directly.

2. Remove Test Interference

   Temporarily disable the browser's secure DNS and exit other programs that modify the network stack. Then run ipconfig /flushdns to clear the Windows DNS cache, and close any test pages that are already open.

3. Record the Direct-Connection Results

   Disconnect the v2rayN system proxy, reopen the DNS test page, and run two consecutive tests. Record the number of resolvers, network ownership, and region. This is the baseline for the local path; do not save only the country or region shown on the page.

4. Retest After Connecting

   Connect to the target node and confirm that v2rayN's local SOCKS port 10808 and HTTP port 10809 are listening. Clear the cache again and test. If the result is exactly the same as the direct-connection baseline, the system DNS is probably not being intercepted.

5. Verify the Specified Inbound

   After configuring the local DNS inbound, run nslookup example.com 127.0.0.1. Only when an address is returned and the Xray log shows dns-in and dns-out can you confirm that the query entered the intended path.

The example environment uses Windows 11 24H2, v2rayN 7.12.5, and Xray-core 25.6.8. The initial direct-connection test showed three local network resolver endpoints, with an average lookup time of about 18 ms. After the selected resolver was accessed through a remote node, the page showed only the chosen public DNS service, with an average of about 136 ms over consecutive queries. The added latency is a normal cost of forwarding traffic across a node; the exact figure varies with route distance, so 136 ms is not a fixed benchmark.

Route DNS Through the Proxy Chain with an Inbound and Outbound

The configuration below uses 127.0.0.1:53 as the local DNS inbound, sends TCP and UDP queries to the outbound tagged dns-out, and forwards them through the existing proxy outbound. Before applying it, confirm the outbound tag of the selected node in the active configuration. If the actual tag is not proxy, change proxySettings.tag to the existing tag.

Port 53 may already be occupied by a system service, virtual network adapter program, or local DNS software, and listening on a low-numbered port usually requires administrator privileges. You can temporarily change the inbound port to 1053 to verify that Xray starts with the configuration, but Windows network adapter DNS settings cannot specify a nonstandard port. To fully intercept system queries, free port 53 and point the active adapter's IPv4 DNS to 127.0.0.1.

{
  "dns": {
    "servers": [
      {
        "address": "1.1.1.1",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      {
        "address": "223.5.5.5",
        "domains": [
          "geosite:cn"
        ]
      }
    ],
    "queryStrategy": "UseIPv4",
    "disableCache": false
  },
  "inbounds": [
    {
      "tag": "dns-in",
      "listen": "127.0.0.1",
      "port": 53,
      "protocol": "dokodemo-door",
      "settings": {
        "address": "1.1.1.1",
        "port": 53,
        "network": "tcp,udp"
      }
    }
  ],
  "outbounds": [
    {
      "tag": "dns-out",
      "protocol": "dns",
      "settings": {
        "address": "1.1.1.1",
        "port": 53,
        "network": "tcp",
        "nonIPQuery": "drop"
      },
      "proxySettings": {
        "tag": "proxy"
      }
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "inboundTag": [
          "dns-in"
        ],
        "outboundTag": "dns-out"
      }
    ]
  }
}

queryStrategy: UseIPv4 makes the built-in DNS prefer IPv4 results, which is suitable when the node or local network does not have reliable IPv6 egress. If the route fully supports IPv6, you can use UseIP instead, but also check the proxy node, system routes, and remote resolver so you do not obtain only an AAAA record without usable IPv6 egress.

nonIPQuery: drop discards DNS outbound queries other than A and AAAA records. This suits streamlined setups that only need ordinary web resolution, but it may affect enterprise services that rely on TXT, SRV, or other records. If email verification, service discovery, or internal application resolution fails, remove this setting and test again instead of blaming the VMess or VLESS protocol.

domainStrategy Is Not a DNS Leak-Prevention Switch

routing.domainStrategy determines whether the routing module resolves a destination domain to an IP while matching rules. It controls whether routing rules perform an additional lookup, not where operating-system DNS queries are sent. Changing it from AsIs to IPIfNonMatch may give IP rules a chance to match, but it does not automatically intercept UDP 53 requests from the network adapter.

A common choice is IPIfNonMatch: let domain rules run first, then resolve for geoip or explicit IP rules only when there is no match. This avoids triggering a lookup for every request while retaining IP-based routing. If the routing list places IP rules very early, IPOnDemand may significantly increase core DNS queries. Watch the logs rather than choosing solely by the name.

Domain-based routing in top-level dns.servers and routing.rules follow two separate sets of logic. The former determines which resolver handles a class of domains; the latter determines whether the connection goes to direct, proxy, or block. If geosite:cn uses a nearby resolver while all DNS queries must be forwarded through a remote node, clarify whether those goals conflict. Design the resolver address and transport path separately.

• If you only want domain rules to take priority, use AsIs and handle system DNS separately.
• If you also need geoip routing after a domain fails to match, use IPIfNonMatch.
• Do not treat changing domainStrategy as proof that testing is complete; still check port 53 and the logs.
• When the node server address itself is a domain, ensure a usable bootstrap resolution path exists during startup; otherwise the proxy cannot resolve the node before it is established.

Apply the Configuration in v2rayN Without Losing It to Overwrites

Standard subscription nodes in v2rayN are used to generate a runtime configuration. Direct edits to a temporary JSON file may be overwritten when you switch servers, update the subscription, or restart the core. For full control over the DNS inbound and outbound, use a custom configuration server and merge the existing node parameters, routing rules, and the DNS structure above into one valid configuration.

1. Confirm the Core Type

   Go to Settings → Parameters → Core Type and confirm that the current server uses the Xray core. Save the change and restart the core so the configuration is not interpreted by a different core.

2. Check the Outbound Tag

   Open the active runtime configuration and find outbounds.tag for the selected node. This guide uses proxy; if the actual file uses another name, the proxy tag referenced by the DNS outbound must match it exactly.

3. Add a Custom Configuration

   Under Servers → Add Custom Configuration Server, select the prepared JSON file. Keep the local DNS inbound on port 1053 for the initial startup test, and verify that the syntax and routing logs are normal first.

4. Free Port 53

   Run Get-NetUDPEndpoint -LocalPort 53 and Get-NetTCPConnection -LocalPort 53 to check what is using the port. Resolve any conflict, change the configured port back to 53, and restart v2rayN with administrator privileges.

5. Update the Active Network Adapter

   Set the IPv4 DNS server for the active network adapter to 127.0.0.1. Do not keep the local ISP DNS as a fallback at the same time; if the local service briefly stops responding, the system may automatically switch to the fallback resolver.

6. Clear the Cache and Verify Again

   Run ipconfig /flushdns, verify the inbound with nslookup example.com 127.0.0.1, and run three rounds of testing. Then check whether the logs show dns-in reaching dns-out.

If you use only the system proxy without TUN, applications that ignore system proxy settings may still connect directly. DNS interception fixes only the resolution path; it does not replace full-traffic interception. With TUN, also check DNS hijacking and routing rules: traditional UDP and TCP 53 traffic can be captured, but an application's own HTTPS resolver connection appears as ordinary 443 traffic, whose destination is determined by that application's traffic rules.

Common Errors and Troubleshooting Order

During troubleshooting, first check whether the core started, then whether the port is listening, and only afterward inspect the test page. The test page is at the end of the chain; refreshing it repeatedly adds no information when either of the first two checks fails. You can temporarily set the log level to info for diagnosis, then restore the usual setting to avoid generating large access logs over time.

If the logs show requests hitting dns-in but not reaching dns-out, check the order of the routing rules. Xray matches routes from top to bottom; an earlier general inbound rule may send the request to direct first. Move the rule for dns-in before general rules and make sure there are no duplicate tags.

If the Xray logs are complete and system queries work normally but the browser test still differs, the browser is usually using an independent resolution path. After re-enabling secure DNS, treat it as ordinary HTTPS traffic: check whether the browser process uses the system proxy or TUN instead of continuing to change port 53 settings.

Keep the listen address at 127.0.0.1; do not change it to 0.0.0.0 for convenience. The latter listens on every network adapter, allowing LAN devices to reach the port and expanding the firewall scope. Bind to a LAN address and add access controls only when you intentionally provide DNS service to other devices.