V2Ray DNS Leak Test and Prevention: Remote DNS and FakeDNS in v2rayN

What Is a DNS Leak? Check Web Traffic and DNS Resolution Separately

DNS translates domain names into IP addresses. Routing web traffic through a proxy does not mean DNS queries use the proxy too. If an app sends a domain to a resolver on your local network before the proxy can handle it, that network may still see the query. The issue is a mismatch between the intended and actual DNS paths.

v2rayN is a desktop client; DNS behavior depends on the active core, inbound type, and generated configuration. Protocol names such as VMess and VLESS do not tell you whether DNS is leaking. Simply switching protocols usually won't fix browser-side resolution or incorrect routing order.

This flow is a troubleshooting model; not every request follows the exact same sequence. An app may resolve a domain locally first, or the core may resolve it to match an IP rule. Ask two questions: who initiated the query, and which outbound route carried it?

• Remote DNS: Handles queries for domains that should be resolved through the proxy. A server being located elsewhere does not mean the request is automatically sent through the proxy.
• Direct DNS: Handles queries for domains explicitly allowed to connect directly, with the goal of matching their local access route.
• Browser Secure DNS: The browser's own encrypted DNS channel may bypass system DNS settings. Whether it also bypasses the proxy depends on its connection route.
• Proxy server hostname resolution: May be required before connecting to the proxy server, so it cannot depend on the same proxy connection that has not yet been established.

DNS Leak Test: Record a Baseline, Then Compare Proxy Results

Visit a DNS leak test page such as DNSLeakTest and run a standard or extended test. Record the resolver addresses, provider, and region. Test pages typically show the exit point of the final recursive resolver, not necessarily the DNS server your computer connected to directly. Geolocation databases can also be inaccurate, so a different country alone doesn't prove a leak.

1. Record a baseline: Turn off the proxy and TUN, restart the browser, then visit a DNS test page that doesn't involve sensitive information. Note your public IP and the resolver's network provider.
2. Enable the standard proxy: Start a node you've confirmed works. From the v2rayN tray menu, select “System Proxy” → “Automatically configure system proxy.” Wording may vary by version; follow the options shown in your client.
3. Repeat the same test: Confirm that your public IP has changed, then run the DNS test. Keep the browser, node, and test page the same if possible.
4. Isolate browser settings: Note the current Secure DNS setting, temporarily turn it off, and test again. Don't change the node and routing at the same time, or you won't know which change made a difference.
5. Test other apps: Once the browser passes, check the app you're troubleshooting. A system proxy does not capture all system traffic, so one browser passing the test doesn't mean every app is covered.

Verify Ports and Commands: Distinguish Local DNS from Proxy DNS

First, check the active local listening port and inbound type under “Settings” → “Parameters.” The example below uses 10808 as a SOCKS inbound; this isn't a claim that every version uses it as the default. Use the commands only after confirming that the port supports SOCKS.

Run these commands in Windows PowerShell. The first only checks whether a TCP connection to the local port can be established; the other two compare where the domain is resolved. Using curl.exe avoids environments where curl is an alias for another command.

Test-NetConnection 127.0.0.1 -Port 10808

curl.exe --socks5 127.0.0.1:10808 --connect-timeout 10 -I https://example.com

curl.exe --socks5-hostname 127.0.0.1:10808 --connect-timeout 10 -I https://example.com

• --socks5: curl resolves the target domain locally, then passes the target IP to the SOCKS proxy.
• --socks5-hostname: Sends the domain to the SOCKS proxy for resolution further along the proxy chain. This alone doesn't prove which DNS server ultimately handled the query.
• If only the second command succeeds, first check whether local DNS resolution is blocked. If both fail, troubleshoot the node, listening port, and outbound connection.
• nslookup example.com typically queries the DNS server configured for your system. Enabling an HTTP system proxy does not automatically route it through v2rayN. Its output alone cannot disprove a browser test result.

Remote DNS and Direct DNS in v2rayN: Configure the Address and Outbound Route

Back up your client configuration before making changes, and note the current node, routing mode, and DNS settings. Open “Settings” → “DNS Settings” and check the options for the active core. If your version puts DNS under Parameters, use the DNS section on that page. Core configuration formats aren't interchangeable; don't paste the same JSON into every core.

The addresses in this table illustrate configuration relationships; they're not a required list of services. Choosing DoH for remote DNS encrypts the connection, but if the DoH request goes direct, your local network can still see that you're connecting to the resolver. To route DNS traffic away from your local network, check the routing rules too.

1. Limit the scope first: During troubleshooting, you can temporarily use the client's global proxy routing mode to reduce split-routing variables. Restore your usual routing after testing; don't mistake a temporary mode for a final configuration.
2. Configure remote resolution: Enter a DNS address in a format supported by the active core. Standard DoH is not the same as some cores' local, direct-resolution modes; HTTPS alone doesn't prove the request goes through the proxy.
3. Check rule order: If a “direct for foreign IPs” rule or a direct rule covering the resolver's address is present, check whether it matches first. Rules are generally evaluated from top to bottom, so a later proxy rule can't override a direct rule that already matched.
4. Handle node bootstrap resolution: If the node uses a hostname, give it a separate, reachable way to resolve it. Don't make the node hostname dependent on that same node for resolution.
5. Save and restart the core: Check the logs for configuration errors, then repeat the same tests. If the issue returns after restoring split routing, focus on domain rules and the resolver's outbound route.

FakeDNS and TUN: Preserve Domain Names After IP-Based Inbound

FakeDNS doesn't return a domain's real server address. Instead, it assigns a synthetic IP and stores a mapping between the domain and that address. When a later connection targets the synthetic IP, the core can recover the domain and continue processing it. This solves a domain-information handoff problem; it isn't a standalone encrypted DNS service and can't replace proxy outbound rules.

Xray commonly uses 198.18.0.0/15 as its FakeDNS IPv4 range, but check the generated configuration in use. This range is reserved for benchmarking, not for public website addresses. The mapping is useful only when the request and subsequent connection are both handled by the same FakeDNS-capable path.

1. Verify the basic proxy first: Complete the remote DNS tests above without FakeDNS enabled. Don't turn on multiple advanced options while the node still can't connect.
2. Confirm implementation support: Check whether the active TUN implementation and core support the relevant FakeDNS or fake-IP mode. Similar names don't mean configurations are interchangeable, and there's no need to force it on for a standard SOCKS setup.
3. Enable DNS interception: Use the TUN and DNS interception options available in your client. Enabling a virtual network adapter alone doesn't mean the core now handles every DNS query.
4. Verify domain recovery: Check whether the generated configuration can recognize FakeDNS mappings, and review any FakeDNS sniffing settings if needed. Enabling HTTP and TLS detection for regular sniffing alone doesn't complete the setup.
5. Clear caches and retest: Restart the app under test and, if needed, run the system cache-clearing command below. Browsers may have their own cache, so restart them as well.

ipconfig /flushdns

Browser DoH, app-specific DNS, and IPv6 are common blind spots. Intercepting UDP port 53 alone won't handle every HTTPS-based DNS request. If IPv6 routing isn't covered, an app may use a separate network path. Configure IPv6 according to what's supported, or temporarily disable IPv6 on the relevant adapter during an isolated test and compare results. Don't treat temporary deactivation as a general fix.

Can't Load Websites After Changing DNS? Use Logs to Find the Failing Layer

Start with the target address, outbound route, and failure time in the logs, then check the error keyword. The examples below are common snippets, but the exact wording may vary. Temporarily increasing log verbosity can help; before sharing logs, redact subscription URLs, node credentials, and personal domains you've visited.

If only some websites fail after a change, check split-routing rules and IPv6 first. If all websites fail immediately, check the DNS address format, node bootstrap resolution, and TUN routing. If the client can no longer load its configuration, roll back the latest change instead of adding more rules.

• Rollback order: Restore the DNS backup, turn off newly added FakeDNS or TUN settings, restart the core, then clear caches.
• Keep a record: Note whether the failure occurred in standard proxy or TUN mode, and which resolver was in use.
• Change one variable at a time: In each test, change only the DNS address, outbound rule, or browser Secure DNS setting.

FAQ: How to Interpret DNS Test Results and Prevent Leaks