V2Ray DNS Settings: Split DNS for China and Overseas Domains, Prevent DNS Poisoning

1. Understand DNS Resolution, Routing, and Proxy Egress

DNS translates domain names into IP addresses. Routing determines whether a connection goes direct or through a proxy. They’re related, but they aren’t the same setting: specifying a remote DNS server doesn’t guarantee DNS requests will use the proxy, and routing a site through a proxy doesn’t mean your browser didn’t already query the system DNS.

This sequence shows what to check, not that every connection must be resolved locally first. HTTP and SOCKS proxies can receive a domain name and resolve it remotely; rules that match IP addresses may trigger resolution by the local core. If an app resolves a domain first and sends the resulting IP to the proxy, the client may have less access to the original domain information.

• Distinguish the client from the core: v2rayN is a desktop configuration interface; actual DNS behavior depends on the enabled core, runtime configuration, and traffic-capture mode. v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. Don’t assume DNS fields are interchangeable across cores.
• Distinguish poisoning from leaks: DNS poisoning means receiving an incorrect or tampered response. A DNS leak means a query took an unintended route. A response can be correct even when the query leaked.
• Distinguish resolution failures from connection failures: If the logs show a DNS timeout, check DNS reachability first. If an address was returned but the connection timed out, also check routing, the node, the destination port, and network restrictions.

2. Choose Local and Remote DNS Resolvers and a Transport

“Local DNS” usually means a resolver used for direct connections, not necessarily a service running on your computer. “Remote DNS” usually means a resolver used for proxy traffic, but that doesn’t mean requests automatically go through the proxy. Assign each resolver by purpose, then verify its transport protocol, server address, and actual outbound route.

These are common protocol ports, not listener ports that you need to enter in the client. Whether a client field accepts a DoH URL depends on the version and field description. An HTTPS homepage isn’t automatically a DNS endpoint just because DoH uses HTTPS. DoT URLs aren’t supported by every DNS field either.

3. Check DNS and Routing Settings in v2rayN

Note the current operating mode and core, then open Settings → DNS Settings. In some releases, the relevant options may appear on a DNS tab in the settings window; follow the field descriptions in your version. Don’t paste a JSON snippet from the web into a field with a different purpose, and don’t assume DNS settings retain the same meaning after switching cores.

1. Record the current values. Note your local DNS, remote DNS, routing mode, and active core settings. If you use a custom DNS configuration, back up the original text so you can restore it after testing.
2. Configure direct DNS. Enter a reachable resolver in the local or direct DNS field. If you use 223.5.5.5, make sure your current network allows access. For corporate domains, prefer your organization’s DNS server rather than switching everything to a public resolver.
3. Configure remote DNS. Use a format supported by the active core in the remote DNS field. If DoH is supported, you can use https://dns.google/dns-query; this is only an example and may not be reachable on every network.
4. Review routing rules. Open Settings → Routing Settings and check the rules for mainland China domains, proxy-routed domains, and the default outbound. To split traffic by domain, don’t rely on IP rules alone.
5. Save and restart the core. Reload the configuration, then check the logs for invalid DNS configuration, resolution timeouts, or failed server connections. A successful save only means the settings were written; it doesn’t confirm that traffic is taking the intended route.

If your runtime configuration uses V2Ray/Xray routing.domainStrategy, understand the three common values. AsIs routes using the original domain without resolving it for IP rules. IPIfNonMatch attempts resolution after no domain rule matches, then continues matching. IPOnDemand resolves only when a rule requires an IP. These values don’t mean “direct,” “proxy,” or “global.”

4. Check VPN Capture and DNS in v2rayNG

In v2rayNG, open Settings from the sidebar and find Remote DNS, Local DNS, and any option to enable local DNS provided by your version. Labels may change between releases. After entering a local DNS server, make sure the corresponding feature is enabled; an address in the field alone doesn’t mean it’s active.

1. Confirm the connection mode. Start the configuration and check the system VPN status. In proxy-only mode, apps that don’t use the proxy won’t automatically be covered by these DNS settings.
2. Check local DNS. Enter a resolver for direct traffic that works on your current network, and check that the feature is enabled. Preserve access to internal names; public DNS usually can’t resolve company network names or home devices.
3. Check remote DNS. Enter an address supported by your version, then stop and restart the connection after saving. If you need encrypted DNS, confirm that the field supports the protocol before using it; don’t guess at a URL prefix.
4. Check routing and per-app settings. In Settings → Routing Settings, review how mainland China traffic is handled, and check per-app proxy settings. Excluded apps may continue to use the system network and system DNS.
5. Check Android and browser settings. Note whether Android Private DNS and the browser’s Secure DNS are enabled. Change one setting at a time while troubleshooting, then reconnect and compare the logs and resolution behavior.

Android Private DNS, browser-based DoH, and the core’s DNS can create multiple resolution paths. Don’t assume one setting always overrides another. Consider VPN coverage, excluded apps, and actual connection records. Browser DoH requests in particular may travel as ordinary HTTPS traffic through routing without using the client’s built-in resolver.

5. Pair DNS Resolution Rules with Connection Rules

“Local DNS for mainland China domains, remote DNS for overseas domains” requires two layers to work together: DNS rules select a resolver, while routing rules select the outbound path for application traffic. Changing DNS alone won’t route the connection through a proxy; changing traffic routing won’t undo DNS queries an app has already sent to the system.

• Add specific exceptions first. Explicitly handle internal domains, corporate services, and local network addresses that need direct access so broad proxy rules don’t override them.
• Then add domain categories. If your configuration uses rules such as geosite:cn, make sure the active core supports them and has loaded the required rule data. Category lists aren’t real-time geolocation and may not cover every mainland China site.
• Add IP-based fallbacks. geoip:cn classifies IP addresses, which is different from classifying domains. A mainland China domain may use an overseas IP, and an overseas domain may return a mainland China CDN address.
• Check what happens when nothing matches. Confirm which outbound handles domains outside the category lists and whether DNS falls back to another server. If you don’t know how fallback works, don’t assume overseas queries can never take a local route.

Handle the proxy server’s own domain separately. If a node needs to resolve its domain before connecting, but that resolution is allowed only through the proxy that isn’t connected yet, startup can get stuck in a loop. A remote DoH server that uses a domain may also need bootstrap resolution. Check how your core establishes the initial connection instead of forcing every resolver through the proxy.

6. Verify with Logs, Caches, and Comparison Queries

Verification should answer three separate questions: who receives the query, which route it takes, and which outbound handles the application connection. Seeing a usable IP doesn’t prove DNS didn’t take an unintended route; a webpage opening in the browser doesn’t prove every app is covered.

1. Choose test domains. Pick one public domain in mainland China, one domain that requires a proxy, and one internal name you actually use. Test the same set each time so you can compare results consistently.
2. Reconnect. After saving DNS settings, restart the client connection and reopen the test app. Browsers, the system, and the core all have caches; clearing just one may still leave an old result in use.
3. Check client logs. First rule out a configuration load failure, then look for resolution errors and outbound records. How much DNS detail appears depends on the core and log level; no log entry doesn’t mean no query occurred.
4. Compare with system-level queries. In a Windows terminal, run the commands below to compare the default resolver with a specified resolver. These commands test system-level queries and don’t replace verification of the client core’s DNS behavior.

nslookup www.qq.com
nslookup www.qq.com 223.5.5.5
ipconfig /flushdns

The first command typically uses the current system resolver; the second queries a specified address; the third clears the Windows DNS cache. Different resolvers commonly return different CDN addresses, so a mismatch alone doesn’t prove poisoning. Check whether the address is reasonable, resolution is stable, the destination is reachable, and what the client logs show.

7. Troubleshoot Common DNS Problems by Symptom

Keep a restorable record of your setup: note the active core, traffic-capture mode, local and remote resolvers, routing policy, browser DNS settings, and date of each change. Next time something breaks, revert the most recent change first. It’s easier to find the cause than changing the node, DNS, and routing all at once.