Troubleshooting DNS in v2rayN and v2rayNG means checking both which resolver handles a query and where the DNS connection goes. This guide is for users who can connect to a node but see their local ISP in test results or run into domain lookup problems. First compare direct and proxied connections, then check the desktop system proxy or Android VPN, remote DNS, and routing rules. Finally, verify the results with logs and repeat tests.
1. How to Identify a DNS Leak
A DNS leak occurs when a query takes a different network path than intended. For example, if a domain that should use the proxy is still resolved by your local ISP, the query may be exposed to your local DNS path. A website showing the proxy server's exit IP only confirms that the page connection used the proxy; it does not prove that DNS queries did too.
v2rayN's system proxy only affects apps that honor the system proxy settings; it does not route every DNS query from your computer. v2rayNG's VPN mode can capture traffic from more apps, but per-app exclusions, browser Secure DNS, Android Private DNS, and IPv6 routing can still change the path. Enabling TUN or VPN is the start of testing, not proof that everything is routed correctly.
| Test result | What it tells you | What to check next |
|---|---|---|
| Website IP has changed | The website connection used a different exit | Check the DNS query path separately |
| A local ISP resolver appears | The test domain may have been resolved through your local DNS path | Check browser, system DNS, and direct-connection rules |
| Resolver country differs from node location | Public DNS anycast or forwarding may be involved | Check the provider and actual egress, not just the country |
| Both proxy and local resolvers appear | There may be multiple DNS paths or a fallback | Repeat the test and rule out caching, per-app settings, and fallback configuration |
Bottom line: judge leaks by domain purpose
Split routing may use local DNS for domains that connect directly. The issue to fix is proxy-routed domains unexpectedly using your local DNS path—not every local resolver entry.
2. Compare Direct and Proxied Connections
DNS leak test sites typically generate a random subdomain and check which recursive resolvers query it at the authoritative server. The result shows the service that ultimately performs the recursive lookup, which may differ from the address entered in the client. Public DNS forwarding and anycast can also affect geolocation, so note the provider, test mode, and current client settings as well.
-
Record a baseline
Disable the client proxy and open a DNS leak test site in the same browser, such as by entering
dnsleaktest.commanually. Record the website's exit IP, resolver provider, IPv4/IPv6 status, and whether browser Secure DNS is enabled. -
Enable the proxy
Start v2rayN or v2rayNG and confirm the active node and routing preset. Use the same network, browser, and test site, then run the full test again. Don't switch between Wi-Fi and mobile data between tests.
-
Isolate variables
Temporarily disable custom Secure DNS in the browser and test again, then re-enable it and run another test. Change just one setting per round, labeling each setup as “system proxy,” “TUN,” or “VPN” so results from different connection modes don't get mixed up.
-
Verify more than once
Run each configuration at least twice and check the client logs. After changing DNS, restart the core or VPN connection. Refreshing a regular webpage may reuse cached data and is no substitute for testing with a new random domain.
On Windows, use the commands below to check DNS addresses assigned to physical and virtual network adapters and clear the system cache. Clearing the system cache does not clear the browser's own cache or change which resolver an app uses.
Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClientServerAddress -AddressFamily IPv6
ipconfig /flushdns3. v2rayN: Configure Remote and Direct DNS Separately
In v2rayN, distinguish three DNS tasks: resolving domains accessed through the proxy, resolving domains accessed directly, and resolving the proxy server's own address. If the proxy server is specified by hostname, its IP must be resolved before the proxy connection can be established. Forcing that lookup through a proxy that isn't connected yet can create a DNS dependency loop.
DNS settings vary across v2rayN versions, interface types, and cores. The steps below refer to interfaces with a “Settings” → “DNS Settings” menu. If you see a DNS template or JSON editor instead, back up the existing configuration and edit the relevant settings for that core. Don't paste fields intended for a different core.
-
Back up the current configuration
Note the active node, routing preset, system proxy status, and TUN status on the main screen, then save the existing settings under “Settings” → “DNS Settings.” A subscription provides node details; don't assume it also configures every DNS routing rule on your device.
-
Separate DNS by purpose
Use remote DNS for domains that should be resolved through the proxy, and direct DNS for local or directly routed domains. For example,
https://1.1.1.1/dns-queryis a DoH service URL. It illustrates the format; whether the connection uses the proxy depends on your routing rules. -
Check the DNS connection's route
Review DNS settings and routing rules to ensure remote DNS connections use the proxy outbound and direct DNS connections use the direct outbound. Before using a DNS address format with local-direct behavior or a special resolution mode, confirm how the current core handles it. Don't rely on a “remote DNS” label alone.
-
Verify traffic capture
If only your browser needs the proxy, test the system proxy first. If an app ignores system proxy settings, consider TUN. After enabling TUN, check DNS capture, adapter routes, and IPv6. Avoid keeping multiple conflicting virtual adapter configurations active at once.
-
Restart and test again
Save the settings and restart the core, then repeat the checks from the previous section. If the node server's address won't resolve, restore a working bootstrap DNS path first instead of adding more proxy rules.
| Resolution method | Common port | Path to verify |
|---|---|---|
| Traditional DNS | UDP 53、TCP 53 | Check for queries sent directly through the physical adapter and TCP fallback |
| DoT | TCP 853 | Confirm encrypted DNS connections use the intended proxy route |
| DoH | Usually HTTPS 443 | Resolver address, bootstrap lookup, and HTTPS egress |
DNS encryption and DNS routing through a proxy are separate concerns. DoH encrypts queries between your device and the resolver, but if the DoH connection goes out over your local network, it still doesn't meet the goal of sending DNS traffic through the proxy. Conversely, traditional DNS carried inside a proxy tunnel doesn't mean queries were sent unencrypted over your local network.
4. v2rayNG: Check Local DNS, VPN, and App Coverage
v2rayNG uses the Xray core and routes app traffic through Android's VPN interface. “Enable local DNS” usually refers to DNS handling within the client; it doesn't mean that all domains are sent to your local ISP. The actual path depends on DNS settings, routing rules, and which apps are covered by the VPN.
-
Check DNS settings
Open “Settings” from the side menu and look for “Remote DNS,” “Direct DNS,” and “Enable local DNS.” These options may be in different sections. If one is missing in your version, check the client version and core rather than looking for a switch that isn't available.
-
Check which apps are covered
Go to “Settings” → “Per-app proxy” and check whether the browser or app you're testing is excluded. For testing, temporarily disable per-app restrictions. Once VPN capture is confirmed, restore exclusions one at a time.
-
Test Android Private DNS separately
A common Android path is “Settings” → “Network & internet” → “Private DNS,” though menu names vary by manufacturer. Note the original setting, temporarily disable the specified provider hostname, and compare results. On managed devices or networks, check with your administrator before changing settings.
-
Reconnect the VPN
Disconnect and restart the v2rayNG VPN, then check browser Secure DNS, IPv6, and results after switching networks. Changes may not take effect in an existing VPN session.
Check IPv6 in v2rayNG separately. An AAAA record means DNS returned an IPv6 address; the key question is whether the subsequent IPv6 connection is captured by the VPN. You can temporarily disable IPv6 for comparison, but the long-term fix is to correct VPN capture or routing—not to blame every issue on AAAA records.
5. DNS Routing and TUN: Prevent Conflicting Rules
Xray's built-in DNS, domain-based routing policies, and sniffing serve different purposes. Built-in DNS resolves names, routing rules select an outbound, and sniffing attempts to recover domain information from a connection. Changing a domain routing policy won't automatically send all system DNS through the proxy, and sniffing won't capture DoH connections made directly by the browser.
- Check broad direct rules first: If a DNS service address matches an earlier direct IP rule, later proxy rules may never apply. Check the order in the actual generated core configuration.
- Keep a bootstrap DNS path: If the proxy server and DoH service both use hostnames, make sure you know which resolver handles each initial lookup to avoid a startup dependency loop.
- Check internal corporate domains: Internal domains may only resolve through corporate DNS. Don't force every query to a public resolver; configure the relevant domains and reachable DNS paths separately.
- Verify DNS capture in TUN: Confirm what handles requests after they enter the virtual adapter, and how direct traffic avoids looping back into TUN. Save a restorable copy of the current configuration before making changes.
- Use FakeDNS with care: FakeDNS returns virtual addresses to preserve domain mappings; it is not a standalone encrypted DNS service. If traffic capture is incomplete, an app may receive a virtual address but fail to connect.
Bottom line: stabilize the connection mode before changing DNS routes
First get consistent results with one browser in one connection mode. Then restore split routing, per-app settings, and browser Secure DNS one at a time to identify which change affects the DNS exit.
6. Common Errors and Final Checks
DNS problems don't always show up as a “leak.” A remote resolver connection routed directly by mistake, an unreachable DNS address, or a missing bootstrap lookup for the node server can all stop pages from loading. Log messages vary by core and operating system. The examples below are realistic error snippets; check nearby destinations and timestamps to identify the cause.
lookup example.com: i/o timeout
Cause: The lookup did not return before timing out. The DNS service may be unreachable or the outbound route may be wrong. Fix: Check the resolver address and outbound rule, then test the connection to that service. Repeatedly switching the destination node alone won't help.
dial tcp: lookup example.com: no such host
Cause: Name resolution did not return a usable result. The domain may be misspelled or nonexistent, or the resolution policy may be misconfigured. Fix: Verify the domain and compare it with another working DNS path. Don't assume this means proxy authentication failed.
context deadline exceeded
Cause: The operation exceeded its deadline. This isn't specific to DNS; it can also happen while connecting to a resolver or destination server. Fix: Use nearby log entries to identify the failing stage, then check DNS, the TLS connection, and proxy egress separately.
A packet capture can complement browser-based tests, but filtering only UDP port 53 misses TCP 53, DoT, and DoH. When checking the physical adapter, look at the destination address and direction of connections to DNS services. If you see a connection on port 443, verify its destination; not all HTTPS traffic is DNS. Seeing no port 53 traffic alone doesn't prove DNS is working as intended.
- Resolver matches the domain's purpose: Proxy-routed domains no longer use the local DNS path unexpectedly, while internal and direct-connect domains still resolve correctly.
- Route matches the connection mode: Test the system proxy, TUN, and Android VPN separately; don't treat results from one as proof for another.
- Cache effects ruled out: Use a newly generated test domain, restart the relevant connection after changing settings, and run at least two tests.
- Still works after network changes: On Android, recheck VPN status after switching from Wi-Fi to mobile data. On desktop, check the VPN, virtual adapter, and DNS after waking from sleep.
- Keep a recovery record: Record the final remote DNS, direct DNS, routing preset, and browser Secure DNS settings so you can revert them one at a time if something breaks.
The goal of DNS leak prevention in v2rayN and v2rayNG is to give DNS queries and destination connections clear, separate routing rules. A page loading, a changed exit IP, or a public DNS resolver appearing in another country does not replace checking the actual paths. Keep a record of comparison tests and settings so changes are easier to spot when you switch nodes or networks.