V2Ray DNS Setup: Split DNS for China and Overseas Domains, and DNS Poisoning Protection

1. Distinguish App, Core, and Server-Side DNS

The first question with DNS settings is whether a query actually passes through them. When an app sends a domain name to the proxy, the core may resolve it for routing or a direct connection, or send the domain to the proxy server for remote resolution. If the app resolves the domain locally first and sends the resulting IP to the proxy, the client's dns section may not handle that query.

This flow describes cases where local resolution is needed; it does not mean every proxied connection starts with a local DNS query. If a domain-based rule can select the proxy outbound, the destination domain may be sent directly to the remote server. In that case, the absence of the domain from local DNS logs does not mean the configuration has failed.

• System DNS: Set by the operating system's network settings. Enabling a system proxy does not automatically send all system DNS queries through V2Ray.
• Core DNS: Defined by the configuration's dns section and used by the core's own resolution logic. It is not a service that automatically listens on system port 53.
• Browser Secure DNS: A browser may send queries over HTTPS on its own, bypassing the operating system's resolver.
• Server-side DNS: When a proxy outbound sends a domain to a remote server, the result depends on that server's DNS resolver and network environment.

2. What servers, domains, and queryStrategy Control

servers defines the available DNS resolvers; domains in a server object specifies which domains it should match first; and queryStrategy controls the address family to query. These settings answer three different questions: which resolver to use, which resolver gets priority, and which type of address to request. They are separate from outbound rules for website connections.

domains is not an access control list that limits a server to those domains alone. Matching domains generally get priority, while unmatched domains may still use a server through fallback. Adding skipFallback: true to the mainland China resolver keeps it out of the fallback list for unmatched domains; it does not disable all DNS fallback.

This guide uses UseIPv4 to narrow down the cause of issues; it does not mean IPv4 is always faster. If IPv6 works on both your network and node, switch to UseIP and test again. This affects only the built-in DNS queries, not IPv6 system-wide.

3. DNS Configuration for Split Resolution

The following is a top-level dns snippet, not a complete client configuration. When merging it into existing JSON, replace the existing field with the same name; do not add a second dns field to the same object. Before using geosite:cn, make sure the domain rule data is available in the runtime directory.

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "223.5.5.5",
        "port": 53,
        "domains": [
          "geosite:cn"
        ],
        "skipFallback": true
      },
      {
        "address": "https://1.1.1.1/dns-query"
      }
    ]
  }
}

1. Domains matching geosite:cn are sent to 223.5.5.5 first, preserving the nearby resolution commonly used by services in mainland China.
2. Domains that do not match a priority entry use a DoH server from the fallback list. The mainland China resolver is excluded by skipFallback.
3. If the preferred mainland China resolver fails, DoH may still be tried unless fallback has been explicitly disabled. This snippet sets a priority, not a hard separation.

If your requirements prohibit querying any other resolver when a mainland China domain fails, design a strict fallback policy based on the core's actual capabilities. Do not guess how it behaves by rearranging the array. V2Ray and Xray do not always support the same extensions or fields; check the documentation and startup logs for your core before copying advanced settings from another core.

This example uses a DoH address with an IP to reduce the bootstrap dependency of resolving the DNS server's hostname first. If you switch to a DoH service with a hostname, you also need to arrange its initial resolution to avoid the resolver waiting on itself. Keep DoH TLS certificate verification enabled; do not disable it to work around connection errors.

4. Route DNS Queries Through the Proxy

Encrypted DNS and proxy transport are separate. DoH protects queries between you and the resolver; routing determines whether the connection to that resolver goes direct or through the proxy. If the remote DoH server cannot be reached directly on your network, entering its URL alone will time out. The example below sends the DoH endpoint IP through the proxy and the mainland China DNS server direct.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": [
          "1.1.1.1/32"
        ],
        "port": "443",
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": [
          "223.5.5.5/32"
        ],
        "port": "53",
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

proxy and direct are outbound tags used in this example; they must exactly match the tag values in your existing outbounds. Merge these rules near the top of your existing routing rules without replacing the complete rule set. Later rules or the default outbound handle unmatched traffic; this snippet does not define a default outbound.

• Standard HTTPS DNS address: In this example, https:// queries are handled by the core's routing, so a route for the DoH endpoint is required.
• Address formats with local-direct semantics: For example, https+local:// in cores that support it behaves differently. Do not assume the proxy routing described in this example applies.
• Proxy node specified by hostname: Make sure the node hostname can be resolved independently. Otherwise, you can create a dependency loop: reaching remote DNS requires the proxy, while connecting to the proxy requires DNS.

routing.domainStrategy and dns.queryStrategy are separate settings. Here, AsIs means routing does not resolve domains proactively for IP rules. With IPIfNonMatch, it tries to resolve a domain and match IP rules when no domain rule matches. Enable this only if you need IP-based routing; do not change it blindly to “make DNS work.”

5. Apply and Test in v2rayN

Back up your current configuration before changing DNS. v2rayN generates the core configuration from its UI settings, and edits to a temporary generated file may be overwritten when you switch nodes or restart the core. A common UI path is Settings → DNS Settings. The section names can vary between versions, so make sure you are editing DNS settings for the core in use—not a field for a different core.

1. Check the core and configuration format. Identify the core used by the current node. The JSON in this guide follows the V2Ray/Xray configuration structure; DNS fields from other cores cannot be copied as-is.
2. Save DNS and routing separately. Enter only the object expected by the DNS editor; do not paste the entire top-level JSON into a single server field. Use the outbound tags from the generated configuration.
3. Restart the core and check startup logs. Fix JSON syntax errors, unknown fields, missing rule data, and other issues before testing websites. Network tests are meaningless if the core has not started successfully.
4. Control test variables. Choose one domain for a service in mainland China and one that requires the proxy. Check whether each app uses its own Secure DNS. Restart the test app after making changes to avoid reusing existing connections.
5. Check the connection path. If needed, temporarily increase the log level. Verify that connections to 1.1.1.1:443 use the proxy outbound and queries to 223.5.5.5:53 go direct. Restore the original log level when you're done.

On Windows, run ipconfig /flushdns to clear the system DNS cache. This does not clear the browser's own cache or every cache in the core. Running nslookup alone usually tests the system's configured resolver; it does not prove that the core's dns section is working.

6. DNS Poisoning Protection: Limits and Common Issues

The key to protecting against DNS poisoning is to send queries for the target domain to a trusted resolver and protect the query in transit. Mainland China UDP DNS is still unencrypted. It is included here to accommodate resolution for services in mainland China, not because it offers the same transport protection as DoH. If this branch behaves unexpectedly, switch to an encrypted resolver supported by your core and reachable on your network, then verify the routing again.

Different resolvers returning different addresses for the same domain does not necessarily mean DNS poisoning. A content delivery network may return different servers based on resolver location and network policy. Conversely, a plausible-looking public IP does not prove that the result is trustworthy. Do not add a static mapping just because two addresses differ: the address may become outdated and bypass normal service routing.

• Change one variable at a time—the resolver, query address family, or outbound route—so you can identify the cause.
• Temporary debug logs may include visited domains and connection details. Remove subscription URLs, credentials, and other sensitive information before sharing them.
• Final testing should cover access to services in mainland China, proxy access, and whether settings persist after a core restart—not just one page refresh.