For users who can connect to a node but aren’t sure whether DNS queries are going through the proxy. First, distinguish browser, system, and core DNS paths. Then compare test results to identify where queries exit, and configure remote resolution, local DNS routing, and FakeIP in TUN mode. The goal isn’t to make a test page show just one address; it’s to route queries for proxy-bound domains as intended.
How to determine whether DNS is leaking
DNS translates domain names into IP addresses. A website connection going through a proxy doesn’t mean its DNS lookup does too: an app might query the router first, then pass the resolved address to the proxy. For domains you intend to resolve through the proxy, that local lookup is a path deviation worth investigating.
v2rayN is the client interface; actual traffic routing and DNS behavior depend on the active core and its configuration. Browser Secure DNS, Windows network adapter DNS, and the core’s built-in DNS are separate entry points. Setting a public DNS address in one place doesn’t guarantee the other two will behave the same way.
| DNS entry point | Common path | What to check |
|---|---|---|
| Windows system resolver | DNS configured on the network adapter, possibly via the router | The system proxy typically doesn’t capture regular UDP DNS traffic |
| Browser Secure DNS | The browser’s own DoH service | Whether it bypasses the client’s DNS rules, and whether the connection itself uses the proxy |
| Core’s built-in resolver | Local or remote resolver specified in the configuration | Both resolver selection and the query’s outbound route must be correct |
| DNS handled by TUN | Captured DNS requests are passed to the core | Whether DNS interception, route scope, and exceptions are working |
Traditional DNS typically uses UDP or TCP port 53; DoH usually uses HTTPS port 443; DoT usually uses port 853. Encryption protects the contents in transit; a proxy controls the route out. They aren’t substitutes for each other.
How to test: establish a baseline, then check the resolver
Choose a DNS test page that shows resolver addresses and their network providers. Use the same page and browser throughout testing, changing only one setting per round. The page typically shows the egress IP used by the recursive resolver to access its test domain. It may not match your computer’s public IP or the node’s exit IP.
-
Record a baseline
In a test environment where a brief direct connection is acceptable, turn off the proxy and note the resolver addresses and network providers shown on the test page. Skip this step if direct access isn’t appropriate. For the remaining checks, rely on routing logs rather than drawing conclusions from location alone.
-
Isolate the browser
Search the browser settings for “Secure DNS,” temporarily turn off custom Secure DNS, and note its original setting. This helps prevent the browser’s built-in DoH from interfering with client tests. Restore it afterward if needed.
-
Test the system proxy
From the v2rayN tray menu, open “System Proxy” and select “Set system proxy.” Keep the node and routing rules unchanged, then run the test again. Note whether the resolver changes; a webpage loading successfully doesn’t prove that DNS is being handled by the proxy.
-
Compare with TUN
Turn off other traffic-capture tools, then enable “Enable TUN” on the main screen. Follow the system prompts to grant permissions and confirm the core is running properly. Clear the cache, retest, and compare the results in system proxy and TUN modes.
-
Check the logs
Review DNS and routing entries in the client logs for the test period. If needed, temporarily increase the log level to check which resolver and outbound route handled the queries. Restore the previous level afterward to avoid logging visited domains over time.
In Windows PowerShell, use the following two commands to check the system’s DNS path. The first clears the Windows DNS cache; the second sends a regular DNS query. Neither command automatically uses v2rayN’s HTTP or SOCKS proxy. Browsers and cores may keep separate caches, so restart or clear them individually.
ipconfig /flushdns
nslookup example.comBottom line: resolver location alone doesn’t determine whether DNS is leaking
If the test shows a local network provider, first check whether the domain was intentionally set to resolve directly, then review the outbound logs. Public DNS services use distributed infrastructure, so a nearby location alone doesn’t prove a leak.
v2rayN remote DNS: configure the address and outbound route
DNS forms vary across desktop interfaces and cores. Open “Settings” → “DNS Settings” and confirm which core is active and which configuration page applies. If that option isn’t available, check the interface and settings menu for your installed version. Don’t paste configuration text for a different core.
Remote DNS is intended to resolve proxy-bound domains through the expected DNS service. For example, https://1.1.1.1/dns-query is a specific DoH endpoint, not a subscription or node address. After entering it, make sure the connection to the service uses the proxy outbound route.
-
Save the current configuration
Record the existing values under “Settings” → “DNS Settings,” along with the active core and routing mode. Keep a copy you can restore, and don’t delete existing DNS rules before testing.
-
Set up remote DNS
Enter a supported resolver address in the remote DNS field for the active core. If you’re using the DoH address above, make sure the field accepts a complete HTTPS URL rather than an IP address only.
-
Check the query’s outbound route
Check the DNS query’s outbound selection or related routing rules, and make sure the remote resolver connection uses the proxy. In Xray configuration,
https+local://means a local direct connection; it does not force traffic through the proxy. -
Restart and test again
Save the settings and restart the core, then clear the cache and run the test again. If webpages stop loading, check for DNS timeouts and node-domain resolution errors in the logs. Don’t change the node, DNS, and routing mode all at once.
Even with the core’s DNS configured correctly, check whether apps hand their domain names to the proxy. Some apps resolve names through the system first, then pass the destination IP along; in that case, the core’s DNS settings may not be involved. To cover these apps, check TUN and DNS interception rather than repeatedly switching remote resolvers.
Local DNS routing: define the boundary between direct and proxied traffic
Using local DNS isn’t inherently a misconfiguration. LAN devices, internal domains, and sites intentionally accessed directly may need local resolution to return reachable addresses. The key is to scope the rules carefully: don’t send proxy-bound domains to a local resolver, or force every query through a remote service.
| Domain use | Resolution strategy | How to verify |
|---|---|---|
| LAN devices and internal domains | Use the DNS service on the current network and keep LAN traffic direct | Check that internal names resolve to the correct private addresses |
| Sites intentionally accessed directly | Use local DNS according to the domain rules | Confirm that both resolution and connections follow the direct-connection rules |
| Sites accessed through the proxy | Use remote DNS and route the query through the proxy | Check both resolver selection and the proxy outbound logs |
| Node server domain | Use a bootstrap resolver that doesn’t depend on connecting to that node | Confirm the first connection succeeds after restarting the core |
For example, 223.5.5.5 may be a suitable public local resolver in some network environments, but it won’t resolve enterprise internal domains and isn’t a universal default. For internal names, prefer the resolver provided by the network. Follow that network’s policies when handling internal domains.
- Check the rule order first: Put specific domain rules before broad fallback rules; otherwise, the specific rules may never take effect.
- Then check fallback behavior: If remote resolution fails and queries automatically fall back to local DNS, make sure that’s what you want. Don’t check only the preferred resolver.
- Finally, check address families: Test both A and AAAA queries. Testing IPv4 alone doesn’t prove IPv6 traffic follows the same proxy route.
Bottom line: route DNS by domain purpose, not to make test results look better
Keep local resolution where it’s needed, and tighten the query path only for proxy-bound domains. If your requirements call for all queries to go through the proxy, explicitly disable the relevant local fallbacks, then verify that node bootstrap resolution and LAN access still work.
FakeIP and TUN: coverage matters more than the toggle name
FakeIP first returns a synthetic address to the app while the core stores the mapping between that address and the domain. When the app connects, the core can then route the connection using the domain name. This can help when an app resolves a domain early and loses the name before connecting, but it isn’t a standalone “DNS leak protection” switch. The result depends on whether DNS queries are intercepted and subsequent connections return to the core.
In Xray, the related mechanism is usually called FakeDNS; other cores use different FakeIP configuration structures. The core used by v2rayN’s TUN feature may also differ from the one used for regular proxy connections, so check the active settings and logs. Don’t copy Xray’s fakedns field into another core’s DNS configuration.
- Confirm DNS interception: Even with TUN enabled, check that regular DNS requests reach the core. An app’s encrypted DNS connection shouldn’t be treated as a UDP port 53 request that can simply be intercepted.
- Check routing for synthetic addresses: Some implementations use an address pool within
198.18.0.0/15. This range is reserved for benchmarking, not real public destinations; check the configuration for the actual pool in use. - Keep exceptions for internal domains: Set appropriate real-resolution exceptions for LAN discovery and internal services that depend on actual addresses, so synthetic addresses don’t break access.
- Clear caches after switching: After disabling FakeIP or changing cores, apps may still have synthetic addresses cached. Restart affected apps and clear their caches; if needed, restart the core to rebuild the mappings.
Common errors and a verification checklist
Log wording varies by core. The snippets below are common examples; check the surrounding entries to identify whether the error concerns the DNS server, node server, or destination site. A single error doesn’t prove that DNS is leaking.
Error: lookup example.com: i/o timeout
Cause: The DNS lookup timed out. The resolver may be unreachable, or the query may be using the wrong outbound route.
Fix: First check the resolver address and query path, then see whether a firewall or route is blocking the connection. Don’t disable certificate verification as a quick fix.
Error: no such host
Cause: The current resolution path didn’t return a usable result. Possible causes include a misspelled domain, a negative cache entry, or an incorrect routing rule.
Fix: Confirm the domain is valid, clear the cache, and compare local and remote resolution results. For internal domains, check whether they were incorrectly sent to a public DNS service.
Error: network is unreachable
Cause: The current network stack has no usable route to the destination. Possible causes include IPv6, TUN routing, or a connection to a synthetic address.
Fix: Check the destination address in the error and review the network adapter and route scope. If it’s in the FakeIP address pool, clear old mappings and confirm TUN is running properly.
After configuration, verify the four items below. A browser test covers only traffic generated by that browser; it can’t replace checks for other apps. v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. When moving to Android, check each app’s DNS and traffic-capture settings again; desktop system-proxy test results don’t automatically apply.
- Proxy-bound domains: Resolver selection matches expectations, the query and destination connection use explainable routes, and there are no unexpected local fallbacks.
- Direct-connection domains: Intended local resolution remains in place, and LAN devices and necessary internal services are still accessible.
- After restarting: Quit and reopen the client. Node domains should resolve on the first connection, without relying on cache from the previous session.
- Restore your everyday setup: Re-enable your planned browser Secure DNS settings and test again. Also check IPv4, IPv6, and the apps you actually use.