v2rayN DNS Settings: How to Configure Split DNS on Windows

DNS configuration is easy to overlook when a v2rayN node appears to work. A browser may successfully reach a website through a VLESS or VMess connection while Windows still sends some domain lookups to the router, ISP, or a manually configured local resolver. That is the problem split DNS is designed to solve: different domain groups use different DNS servers and different outbound routes, while internal or trusted names can continue using a local resolver.

In v2rayN, DNS behavior is affected by more than one switch. The client’s DNS server list, Xray’s DNS configuration, routing rules, TUN mode, Windows adapter settings, browser Secure DNS, and the selected core can all change the final result. A reliable setup therefore starts with a clear policy: decide which domains should use local DNS, which should use a remote resolver through the proxy, and how failures should be handled.

What Split DNS Means in v2rayN

Split DNS is a policy rather than a single DNS server address. Instead of sending every query to one resolver, the client classifies the requested domain and chooses a resolver according to the rule that matches it. A private company hostname may go to the local network DNS, while a public domain that needs to follow the proxy route may go to a remote DNS server through the proxy outbound.

This distinction matters because DNS has two separate decisions. The first decision is which resolver receives the query. The second is how the query reaches that resolver. Configuring https://dns.example as a remote resolver does not automatically guarantee that the HTTPS request uses the proxy. The Xray DNS configuration and routing rules must send that request to the intended outbound.

In a basic Windows system-proxy setup, v2rayN commonly exposes an HTTP listener on 127.0.0.1:10809 and a SOCKS listener on 127.0.0.1:10808. These listeners handle applications that respect proxy settings, but Windows DNS queries do not automatically become HTTP or SOCKS requests. An application that calls the Windows resolver directly can therefore bypass the DNS policy configured in the client.

TUN mode changes the capture layer. When enabled and working correctly, the virtual network adapter can capture DNS packets and traffic from applications that ignore the Windows system proxy. That does not mean every query is automatically remote. TUN captures traffic first; Xray routing and DNS rules still decide whether the query is handled locally, sent through the proxy, or blocked.

Choose a DNS Policy Before Changing Settings

Before opening v2rayN, write down the domains that need special treatment. Many users only need two groups: local domains and public domains. A local resolver is useful for internal hostnames, router management pages, company services, or regional domains that resolve faster and more accurately from the local network. A remote resolver is useful when local DNS returns incorrect results, blocks a domain, or exposes queries through a network that should not see them.

Do not put every domain into the local group simply because the local resolver responds faster. A fast response can still be inaccurate, filtered, or visible to an untrusted network. Conversely, do not force every query through a remote resolver when internal services depend on split-horizon DNS, where the same hostname returns a private address inside the local network and a public address elsewhere.

Resolver protocols also have trade-offs. Plain DNS normally uses UDP or TCP port 53 and is simple to test, but the query is not encrypted between the client and resolver. DNS over TLS generally uses port 853, while DNS over HTTPS uses HTTPS and commonly uses port 443. DoH can blend with ordinary web traffic, but it still needs a correct route and a reachable endpoint. A resolver that is technically secure but unreachable from the current network is not a practical fallback.

Configure DNS Settings in v2rayN on Windows

The exact labels can change between v2rayN 7.x minor releases and between Xray core versions. In the main window or tray menu, look for “Settings,” “Parameter Settings,” “DNS,” “Routing,” or an advanced JSON configuration area. The important point is to identify whether a field belongs to v2rayN’s local behavior, the generated Xray configuration, or Windows itself. Changing Windows adapter DNS alone does not create split DNS inside Xray.

1. Confirm the core

   Open v2rayN and check the active core under “Settings” → “Parameter Settings” → “Core Type.” Select the Xray core when the profile or feature set depends on Xray DNS and routing behavior.

2. Open DNS options

   Go to “Settings” → “DNS Settings” or the equivalent advanced configuration panel. Record the current resolver entries before changing them so you can restore a known working state.

3. Add resolver groups

   Define one local resolver and one remote resolver. Use the protocol supported by your configuration, such as a normal DNS address, DoT endpoint, or DoH URL, and avoid entering a URL into a field that expects only an IP address.

4. Set domain rules

   In “Routing Settings,” create rules for private or local domains first, then public domains that should use the remote resolver. Make the more specific rules appear before broad fallback rules.

5. Choose the outbound

   Assign the local DNS group to the direct outbound and the remote DNS group to the proxy outbound. Save the profile, restart the core, and watch the log for DNS startup or configuration errors.

6. Test one group at a time

   Resolve a known private hostname and a public hostname separately. Confirm both the returned address and the route shown in the v2rayN log before adding more rules.

When using a graphical settings panel, the terms may be “domain strategy,” “query strategy,” or “DNS routing.” A setting such as IPv4-only, IPv6-preferred, or parallel queries changes address selection and timing; it does not by itself decide whether the query is local or remote. If a website works over IPv4 but stalls while IPv6 is preferred, compare the A and AAAA results and temporarily choose a strategy compatible with the node and network.

Routing order deserves special attention. A broad rule such as “all domains use direct” placed above a more specific proxy rule will prevent the intended split from taking effect. Likewise, a final “match all” rule can send unmatched DNS requests to the wrong outbound. After saving, inspect the generated configuration if v2rayN provides a configuration preview or log entry. Confirm that the DNS server names, rule order, and outbound tags are present in the active profile rather than only in an unused template.

Verify and Debug the Result

Verification should compare the baseline, the changed configuration, and the post-restart state. First disable the new split-DNS rules or record the current result. Use Windows Terminal to run nslookup example.com and note the server line, response time, and returned records. Then apply the v2rayN settings, restart the core, clear only the relevant application cache if necessary, and repeat the same query.

nslookup example.com
nslookup internal.example
ipconfig /displaydns
ipconfig /flushdns

nslookup primarily demonstrates which Windows resolver it contacts directly. It does not always represent how a browser using its own Secure DNS behaves, and it may bypass a client-level DNS design when the client is not capturing system DNS traffic. Use it as one observation, not as the only proof. If TUN mode is enabled, test after confirming that the virtual adapter is present and that v2rayN logs show the active TUN and DNS components without repeated route or permission errors.

Check the v2rayN log for DNS query failures, timeout messages, rejected outbound connections, and unexpected direct routing. A successful DNS response followed by a failed TCP or TLS connection points to a different layer: node reachability, routing, SNI, transport, or certificate negotiation. A DNS timeout before any connection attempt usually points to the resolver endpoint, its route, firewall policy, or an incorrect protocol field.

Browser Secure DNS is especially important on Windows. A browser can send encrypted DNS directly to its configured provider instead of asking the Windows resolver. That is not automatically a leak: the relevant question is whether the browser’s DoH connection uses the desired direct or proxy route. For a controlled test, temporarily disable the browser’s custom provider or select the operating-system provider, test v2rayN, and then re-enable the browser feature only if you can confirm that its route matches your policy.

Also test cached and uncached conditions. A cached answer may appear instantly even when the current resolver is unavailable, while a new hostname exposes the real path. Use several unrelated domains, repeat the test after restarting v2rayN, and compare results from a normal browser window and a private window. Do not treat a single public DNS test page as conclusive evidence; it can show resolver infrastructure that is shared, proxied, or selected through browser-specific behavior.

Common Split-DNS Mistakes on Windows

• Changing only Windows adapter DNS: This changes the system resolver but does not necessarily configure Xray DNS or route remote resolver traffic through the proxy.
• Assuming system proxy captures DNS: HTTP and SOCKS proxy settings affect compatible applications; ordinary UDP port 53 traffic needs TUN capture or a client-aware DNS path.
• Putting a broad rule first: A catch-all direct rule can match before a specific remote-DNS rule and make the split configuration appear broken.
• Adding too many fallbacks: Several fast-looking resolvers make it difficult to identify which server answered and whether the route was direct.
• Ignoring IPv6: A query may return an AAAA record while the node or local route handles IPv6 differently from IPv4. Compare both record types when connection behavior is inconsistent.
• Testing only with cached data: Cached answers hide resolver failures. Flush the Windows DNS cache or use a fresh test hostname when appropriate.
• Editing an inactive profile: v2rayN may contain multiple routing or subscription profiles. Confirm that the selected profile is the one generating the active Xray configuration.
• Enabling TUN before validating the node: TUN broadens traffic capture but does not repair an invalid UUID, expired subscription, incorrect transport, or unreachable server.

If connectivity is lost after saving DNS changes, use a controlled rollback. Stop TUN if it is enabled, restore the last known resolver list, remove newly added domain rules, restart the Xray core, and confirm that the normal system proxy works. Only then reintroduce one remote resolver or one rule at a time. This approach separates a malformed DNS entry from a route conflict and keeps the recovery path short.

Split DNS FAQ

A good v2rayN split-DNS configuration is one that can be explained and reproduced: each domain group has a resolver, each resolver has an outbound route, the fallback is intentional, and the result survives a core restart. Start with a small policy, verify it with logs and fresh queries, and expand only after local and remote groups behave as expected.