This guide is for users who have imported a server and can browse through a proxy, but want to fine-tune direct connections in mainland China and proxy routing elsewhere. Using V2Ray/Xray routing fields, it explains how domain and IP databases, rule order, and the default outbound work together, then shows how to configure them in v2rayN. You’ll also learn to use logs to distinguish between unmatched rules, DNS resolution errors, and requests that never reached the core.
1. First Check Whether Traffic Reaches the Core
Routing rules only apply to connections that reach the proxy core. If your browser isn’t using the system proxy, or an app connects directly on its own, changing geosite:cn won’t affect those requests. In the v2rayN main window, select “System Proxy” → “Set up system proxy,” then make sure no browser proxy extension is overriding the system settings.
Use the port shown in your current client. For example, if the local mixed listener uses port 10808, configure the app to connect to 127.0.0.1:10808. Don’t use the remote server port as your local proxy port. Check the listening port under “Settings” → “Parameter Settings,” then test with a known working server before changing your routing rules.
- v2rayN: Manages servers, routing settings, and core processes; it isn’t a transport protocol.
- V2Ray/Xray: Runs the routing logic described here. Supported fields depend on your core version.
- VMess/VLESS: Define proxy connection protocols; they don’t determine whether domestic domains connect directly.
- System proxy and TUN: Control how requests reach the core. Check which routing rules actually apply with either setup.
2. geosite Matches Domains; geoip Matches Destination IPs
geosite:cn references the cn collection in a domain database; geoip:cn references mainland China addresses in an IP database. These aren’t two ways to write the same rule, and a domain’s suffix alone doesn’t determine how it’s classified. Domain matching depends on the data file in use, so updates can change whether individual sites match.
| Rule value | Field | What it does |
|---|---|---|
geosite:cn | domain | Matches mainland China-related domains in the domain database without requiring an IP lookup first. |
geoip:cn | ip | Matches by destination IP location, including direct IP connections and resolved addresses. |
geoip:private | ip | Matches private and special-use addresses in the database, commonly used for direct connections on local networks. |
geosite:category-ads-all | domain | Matches the ad-domain collection; make sure the current domain database includes it. |
domain:example.com | domain | Matches the specified domain and its subdomains, for manually defined exceptions. |
full:example.com | domain | Matches the exact domain only, not its subdomains. |
Within a rule’s domain array, multiple entries usually work as “match any.” But if you include both domain and ip in one rule, conditions from both fields must be met. To send mainland China domains or mainland China IPs directly, create two separate rules instead of combining them in one rule object.
3. domainStrategy Controls When Routing Resolves Domains
routing.domainStrategy controls whether routing resolves a domain to an IP address. It doesn’t make all DNS requests go through the proxy, and it’s separate from the outbound’s own domain resolution behavior. This guide uses IPIfNonMatch: routing first checks the domain and other conditions, then resolves the target domain and tries IP rules if nothing matches.
AsIs: Match Using the Existing Target
- Field
domainStrategy- Value
AsIs- Routing behavior
- Doesn’t resolve domains to check IP rules
- Best for
- Configurations that rely mainly on domain rules or already have the destination IP on inbound
If a domain request doesn’t match, the presence of a geoip rule alone won’t trigger an address lookup.
IPIfNonMatch: Resolve Only After No Match
- Field
domainStrategy- Value
IPIfNonMatch- Routing behavior
- Triggered when no rule matches on the first pass
- Best for
- Domain rules first, with IP matching as a fallback
If a catch-all rule matches on the first pass, this fallback lookup never happens.
Another common value, IPOnDemand, triggers resolution when matching reaches a condition that requires an IP, so IP rules near the top may generate more DNS queries. Use it when you specifically need to compare addresses early; it doesn’t simply mean “stricter routing for mainland China.” Choose based on DNS availability and rule order, not just the name.
Configuration note: Don’t Pair IPIfNonMatch with an Unconditional Catch-All Rule
For this setup, remove any final rule that proxies all TCP/UDP traffic and make sure the default outbound is the proxy. Otherwise, the catch-all matches on the first pass, and mainland China domains missing from the database may never reach the geoip fallback.
4. Combine Direct Connections in Mainland China, Proxy Routing, and Ad Blocking
This is a routing snippet, not a complete, runnable client configuration. It assumes your existing configuration defines outbounds labeled proxy, direct, and block, with the proxy as the first entry in the outbounds array. When no routing rule matches, V2Ray/Xray uses the first outbound. That makes the default outbound handle proxy routing elsewhere; no catch-all rule at the end is needed.
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"domain": ["geosite:category-ads-all"],
"outboundTag": "block"
},
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
},
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
},
{
"type": "field",
"ip": ["geoip:cn"],
"outboundTag": "direct"
}
]
}
}
- Match ad domains first: Send matches for
category-ads-allto the reject outbound, before any later direct-connection rules are checked. - Connect directly to local IPs: Private addresses such as
192.168.1.1are already IP destinations, so they can match the private address rule directly. - Connect directly to mainland China domains: Domains included in
geosite:cngo straight to the direct outbound, without waiting for IP classification. - Use mainland China IPs as a fallback: If a domain doesn’t match on the first pass, use the core’s DNS resolution and then try
geoip:cn. - Send everything else through the default proxy: If neither the domain nor IP matches, the request uses the confirmed first proxy outbound.
The “first match wins” principle depends on when resolution happens. For a request with only a domain, IPIfNonMatch won’t immediately resolve it just to check an earlier private IP rule. If the domain matches another rule on the first pass, routing won’t reconsider it based on the resolved IP. Add an explicit direct rule for internal domains instead of relying only on geoip:private.
5. Create and Enable a Routing Profile in v2rayN
Back up your current routing profile first, then open “Settings” → “Routing Settings.” The editor layout varies between versions, so use the “Domain Strategy,” “Rule List,” and outbound options shown in your current window. Don’t paste the entire routing object into a field that accepts only a rule array, or edit a generated runtime configuration file that will be overwritten on restart.
- Create a separate test profile: In “Settings” → “Routing Settings,” add or copy a routing profile and give it a clear name, such as “Mainland China Direct Test.” Keep the original profile so you can restore it.
- Set the domain strategy: Set “Domain Strategy” to
IPIfNonMatch. If the editor shows English values, select the exact value as written; don’t enter it as a domain rule. - Add rules one at a time: Add them in this order: ad domains, private IPs, mainland China domains, then mainland China IPs. Put domain collections in the domain condition and IP collections in the IP condition; choose reject or direct for each outbound.
- Check the default proxy: Look for a final rule that matches all traffic. For this setup, confirm the generated configuration uses the proxy as its first outbound instead of adding a catch-all rule.
- Save and activate: Return to the main window and select the new profile under “Routing.” Make sure the core has reloaded it. If the logs show a configuration error, restore the original profile and check the rules one by one.
Standard v2rayN server profiles generate the outbounds needed by the core. The UI labels “Proxy,” “Direct,” and “Block” map to JSON labels, but don’t assume the generated labels are necessarily proxy, direct, and block. With a custom full configuration, make sure the labels and default outbound order are correct. In the visual rule editor, prefer the outbound options it already provides.
| UI action | What to check | If misconfigured |
|---|---|---|
| Choose a domain strategy | routing.domainStrategy is set to IPIfNonMatch | With AsIs, domains aren’t resolved automatically for IP fallback rules. |
| Add a domain category | domain includes geosite:cn | Putting it in the IP condition may prevent the configuration from loading. |
| Add an address category | ip includes geoip:private | Putting it in the domain condition won’t route by destination address. |
| Set the default proxy | The proxy is the first outbound, and no catch-all rule intercepts requests on the first pass | Destinations outside mainland China connect directly, or the mainland China IP fallback never runs. |
6. Verify Rule Matches with Consistent Requests and Logs
Don’t verify routing by comparing page load times alone. Caching, connection reuse, and server load can all affect timing, but they won’t tell you which outbound was selected. Use the same local entry point and test destinations, then check the destination and outbound label in the v2rayN log window. If the current log level doesn’t show connections, look for the log level option under “Settings” → “Parameter Settings,” temporarily set it to info, then restore the original value after testing.
The commands below use Windows curl.exe to connect explicitly to a local HTTP proxy, eliminating browser extensions and system proxy settings as variables. 10808 is only an example; replace it with a listening port that currently supports HTTP. --max-time 15 sets a 15-second timeout; it isn’t a speed test result.
curl.exe --proxy http://127.0.0.1:10808 --max-time 15 -I https://www.baidu.com/
curl.exe --proxy http://127.0.0.1:10808 --max-time 15 -I https://example.com/
- Check a mainland China domain: Confirm the test domain is included in the current
cncollection, then check whether it selects the direct outbound. A site’s use of Chinese alone doesn’t mean it should match. - Check the default outbound: Choose a destination absent from existing domain rules, with an IP address outside the mainland China and private address collections, and check whether it uses the proxy outbound.
- Check your local network: Open an active router address, such as
http://192.168.1.1/, and check the direct outbound label. If the device doesn’t respond to HTTP, the failed request alone doesn’t indicate a routing problem. - Check ad rules: Choose a known domain from the current ad collection and check the reject outbound log. Don’t draw conclusions from an ad URL of unknown origin that may no longer be active.
Troubleshooting order: Check the outbound first, then investigate connection failures
If the logs show the correct outbound, investigate DNS, connectivity, and the service response along that path. If they show the wrong outbound, revisit rule order and classification data. Change one rule at a time and start a new connection to avoid confusion from cached results or existing connections.
7. Common Issues: Rules Match, but the Results Aren’t What You Expected
Added geosite:cn, but domestic sites still use the proxy?
First, check in the main window under “Routing” that the profile you saved is selected. Then check whether an earlier proxy rule matched first. If the log shows an IP instead of a domain, domain collections can’t directly classify the connection, so check the IP rules. If it still shows a domain, confirm the current data file includes the site.
Added a proxy-all rule at the end, but geoip:cn still has no effect?
With IPIfNonMatch, a catch-all proxy rule catches the request on the first pass, so the core never performs the “resolve after no match” step. Remove that fallback rule, confirm the first outbound is the proxy, and test with a new connection. If you need to keep a catch-all rule, redesign the resolution strategy instead of just moving the geoip rule.
Only using geoip:private, but internal domains still won’t open?
Internal names must resolve through an appropriate DNS server, and they must not be routed through an earlier domain rule. Add an explicit direct rule for the internal suffixes you actually use, and check that the corresponding DNS server is reachable. A direct rule won’t make internal hostnames known to public DNS.
Does enabling traffic sniffing guarantee domain-based routing?
No. Sniffing can extract domain information from some protocol handshakes, but whether routing uses it also depends on inbound sniffing settings. Not every connection exposes a domain. First check whether the inbound received a domain or an IP, then decide whether to adjust sniffing. Don’t use it as a DNS fix.
Ad blocking broke a login or payment page. What should I do?
Temporarily disable the ad rule and test again to see if it’s blocking something needed. If the classification is the problem, add a narrowly scoped exception for the required domain and place it before the ad rule. Choose proxy or direct based on what the service needs; don’t allow every subdomain just to restore one resource.
Keep a rule set you can explain: necessary exceptions first, then ad blocking, direct connections for private addresses and mainland China domains, IP classification as a fallback, and the proxy as the default outbound. DNS-resolved addresses still affect IP matching; if DNS is interfered with, even correct rules can classify a destination incorrectly. Verify routing first, then check DNS separately so you can isolate changes to the entry point, resolution, and outbound.