v2rayN DNS Setup: Configure Split DNS Without Leaks

What split DNS changes in v2rayN

DNS is the step that turns a domain name such as example.com into one or more IP addresses. In a v2rayN setup, that lookup can be performed by the operating system, by the Xray core, by a local DNS service, or by a resolver reached through the proxy. Split DNS means that different domain groups use different resolvers instead of sending every query to one server. A common arrangement sends local domains to a direct resolver and remote domains to a resolver reached through the proxy.

This separation is useful because DNS and traffic routing are related but not identical. A browser may ask for an address before the proxy rule is evaluated, or the core may resolve a domain in order to apply an IP-based rule. If the operating system resolves every name directly while the connection itself uses a proxy, the selected resolver may still observe the domain names. Conversely, forcing every lookup through a remote resolver can add delay to local services and make local websites, printers, or intranet hosts harder to reach.

v2rayN is a Windows client interface rather than a single network core. Depending on the installed version and selected core, the generated configuration may be handled by Xray or another compatible core. Menu names and available DNS fields can therefore differ slightly. The reliable method is to identify the active core first, make one controlled change, restart the core, and verify both DNS results and connection routing.

The numbers above describe common service ports, not a requirement that every configuration use them. A resolver may expose DNS over HTTPS on port 443, DNS over TLS on 853, or ordinary DNS on 53. The important question is whether the query travels through the intended outbound and whether the resolver can be reached reliably from the current network.

Choose direct and remote resolvers

A practical split-DNS design normally contains two logical groups. The direct group handles domains that should stay on the local network or use a local resolver. The remote group handles domains that should be resolved through the proxy path. The names “direct” and “remote” describe the path taken by the DNS request; they do not automatically describe whether the returned address is geographically local or remote.

For the remote group, a provider may supply a DNS-over-HTTPS URL, a DNS-over-TLS hostname, or a normal DNS address. Use the exact format supported by the active core. For example, an HTTPS endpoint may look like https://resolver.example/dns-query, while a TLS resolver can be represented by a hostname and port. Do not paste a web page URL into a field that expects only an IP address. Likewise, do not assume that changing 8.8.8.8 to another address automatically sends the request through the proxy; the route for the DNS connection still matters.

Bootstrap resolution is an important detail. If the remote resolver is identified by a hostname, v2rayN or the core must first resolve that hostname before it can connect to the resolver. That first lookup may use the operating system or a configured bootstrap address. A good configuration keeps the bootstrap path small and reliable, then sends subsequent remote queries through the chosen secure resolver. If the bootstrap address is unreachable, the remote DNS group can appear broken even when its URL and credentials are correct.

Configure split DNS in v2rayN

Before editing anything, record the current v2rayN version, active core, active profile, and current system proxy state. Open v2rayN and check the core information shown in the main window or in the core management area. Then export or duplicate the profile you are about to modify. A duplicate makes it possible to compare the new DNS behavior with the original settings without reconstructing the subscription.

1. Check the active core

   Open v2rayN, confirm the selected profile, and use the core management or version information area to identify whether the profile is running with Xray. DNS fields generated for one core may not be accepted unchanged by another core.

2. Open DNS settings

   Go to Settings → Parameters Settings and inspect the DNS-related options. In some builds, DNS options are exposed through the profile editor or advanced JSON configuration rather than one standalone page.

3. Add the resolver groups

   Define one direct resolver and one remote resolver. Use the documented endpoint format, set a sensible query strategy such as IPv4 and IPv6 only when the network supports both, and avoid adding many fallback servers during the first test.

4. Match domains to groups

   Assign local domain categories to the direct DNS group and remote categories to the remote group. Keep the first rule set small, for example one local suffix and one remote test domain, so that a mistake is easy to locate.

5. Route DNS requests

   Make sure the DNS connection itself is handled by the intended outbound. A rule that only matches application traffic is not enough if the core sends DNS through a separate direct path. Review the generated routing order from top to bottom.

6. Restart and test

   Save the profile, restart the core from the v2rayN main window, clear the Windows DNS cache with ipconfig /flushdns, and test one direct domain and one remote domain before changing additional parameters.

The exact labels may vary between v2rayN releases, but the sequence remains useful: identify the core, define resolvers, attach domain conditions, route the resolver connection, and verify the generated behavior. If the graphical settings page exposes only basic DNS choices, use the profile's advanced configuration view and compare the resulting JSON with the core's supported schema. Do not add fields copied from an unrelated client without checking whether the active core recognizes them.

Start with a minimal policy

For an initial test, choose one direct domain category and one remote domain category. A direct rule might cover a local suffix such as lan or a known internal hostname. A remote rule can cover one public domain that is normally routed through the proxy. Avoid importing a large rule set before the two basic paths work. Large lists can hide whether the problem is DNS selection, routing order, an unreachable resolver, or an unrelated node failure.

Place more specific domain rules before broad catch-all rules. If a general rule sends every DNS request to the direct resolver, a later remote-domain rule will never be reached. The same principle applies to routing: a broad direct rule placed above a proxy rule can capture the connection before the proxy rule is evaluated. After saving, inspect the log while querying a test domain. A successful browser page alone does not prove that the intended resolver group was selected.

Verify DNS selection and possible leaks

Verification should use several checks because no single Windows command reveals the complete path. First clear the cache, then query the same domain under controlled conditions. Run ipconfig /flushdns in Command Prompt, open the test domain once, and inspect the v2rayN or core log. Look for DNS query errors, resolver connection failures, repeated fallback messages, or a direct connection to an unexpected server address.

ipconfig /flushdns
nslookup example.com
nslookup example.com 192.0.2.53
ping -4 example.com
ping -6 example.com

The address 192.0.2.53 above is a documentation placeholder, not a public resolver to configure. Replace it only with a resolver that you intentionally operate or have been instructed to test. nslookup shows which Windows resolver answers a conventional query, so it is useful for checking the adapter baseline. It does not always show a query handled internally by the Xray core. For that reason, combine the command output with the core log and a packet capture or resolver-side log when you need stronger evidence.

Check both address families if IPv6 is enabled. A configuration may route IPv4 through the proxy while an IPv6 result creates a direct connection, or the reverse. If the selected node, local network, or resolver does not support IPv6 reliably, set the query strategy to IPv4 only as a temporary diagnostic step. If browsing becomes stable, investigate IPv6 routing rather than treating the temporary restriction as a complete security solution.

A DNS leak test website can provide a useful external observation, but interpret its result carefully. A resolver shown in the result may belong to the proxy exit network, the local network, or a provider upstream of the selected DNS service. The test confirms what resolver was visible from the outside; it does not prove which v2rayN rule selected that resolver. Use the external result together with local logs and a known direct-versus-remote domain test.

When a domain resolves to an address but the page does not open, DNS may already be working. Check the next stages separately: whether the route selected the correct outbound, whether the node is reachable, whether the destination requires IPv6, and whether the browser has cached an old connection. Do not keep changing DNS servers when the actual failure is a busy local proxy port, an expired subscription node, or an incorrect transport parameter.

Troubleshoot failures and restore defaults

The most common failure after enabling split DNS is a configuration that depends on the remote resolver before the proxy is available. The core tries to resolve the remote resolver hostname, cannot establish the bootstrap connection, and then reports a timeout. Another common problem is a routing loop: the DNS request is assigned to the proxy outbound, but the proxy server's own hostname also requires the same unavailable DNS path. Keep the bootstrap address reachable and ensure that the proxy server endpoint can be resolved independently.

If all browsing stops immediately after saving the new profile, use a controlled rollback instead of editing multiple fields at once. Stop the core, select the original duplicated profile, or disable the custom DNS section and return to the system resolver. Then restart v2rayN and test the node without split rules. Once the original connection works, reintroduce the direct resolver first, test it, add the remote resolver second, and add domain matching last.

1. Stop the running core from the v2rayN main window.
2. Switch back to the saved profile or remove the custom DNS entries.
3. Restore the original routing mode and system proxy mode.
4. Run ipconfig /flushdns and restart v2rayN.
5. Test a normal website, a local service, and the subscription update function.
6. Reapply one DNS change at a time while keeping a written record of each result.

Do not solve a DNS failure by adding ten fallback servers. Each fallback can make the configuration harder to audit and may create direct queries that you did not intend. A small configuration with one direct resolver, one remote resolver, one bootstrap path, and clear routing rules is easier to verify than a long list of partially understood options.

Frequently asked questions

The following questions cover the situations most often encountered after a v2rayN DNS change. The safest troubleshooting habit is to return to the last known-good profile, confirm the node works, and then test DNS independently from application routing.