V2Ray Routing Rules: Split Traffic with geosite and geoip

1. What geosite and geoip Match

geosite contains domain categories, while geoip contains IP address ranges. Neither is a service that automatically identifies website ownership or checks it in real time. Routing depends on the local data files, the destination information available to the core, and the order of the rules.

Websites may use CDNs across multiple regions. The same domain can resolve to different addresses on different networks, so a domain matching cn and an IP matching cn are two separate checks. If the browser resolves a domain first and sends only the IP to the proxy, domain rules may not get a chance to match. Sniffing can recover domain information for some protocols, but it can't identify every request's domain.

2. Routing Example and Default Outbound

This is a complete routing object snippet, not a full configuration that can connect to a server on its own. Before merging it into an existing V2Ray or Xray configuration, check the outbound tags. Here, direct refers to a direct outbound using the freedom protocol, and proxy refers to a tested, working proxy outbound. Tags are just names; they don't create outbounds.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": [
          "full:localhost",
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private",
          "geoip:cn"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

This snippet assumes the first entry in your existing outbounds array is a proxy outbound. In a standard routing setup like this one, traffic with no matching rule uses the first outbound—it isn't selected automatically by a tag named proxy. If the first outbound is actually direct, unmatched traffic to sites outside mainland China will also go direct. Don't copy a proxy outbound without server details just to satisfy the ordering requirement.

• For a destination domain in the cn category, the first domain rule matches and selects direct.
• For a private address such as 192.168.1.1, the IP rule matches and selects direct.
• If the destination domain doesn't match any rule, IPIfNonMatch attempts to resolve it and match the resulting IP against IP rules, provided no other rule has already matched.
• If the resolved address still doesn't match a direct route, traffic uses the first outbound—the proxy outbound you verified earlier.

Here, “traffic to sites outside mainland China goes through the proxy” means that traffic not covered by the direct rules above uses the proxy by default. It is not a complete, real-time check of where a site is located. To force a specific domain through a particular outbound, add an explicit domain rule instead of relying on IP geolocation to always meet your needs.

3. Choosing domainStrategy and Avoiding Fallback Pitfalls

routing.domainStrategy controls whether the routing stage resolves a domain to match IP rules. It is not the same as choosing a DNS server or selecting an address for an outbound connection. If the same setting appears at different levels of a configuration, first confirm which object it belongs to.

A common mistake is to add a proxy rule with network: "tcp,udp" at the end when using IPIfNonMatch. That rule can match a request in the first pass, so the “no rule matched” condition is no longer met. As a result, a domain outside geosite:cn may go straight to the proxy without a chance to match geoip:cn after resolution.

Routing-stage resolution also has privacy and connectivity trade-offs. Which DNS server receives a domain depends on the full dns configuration, the path DNS queries take, and how the browser resolves names. Changing domainStrategy alone doesn't guarantee that DNS queries use the proxy or prevent DNS poisoning.

4. Rule Order: Exceptions First, Categories Next

Rules are checked from top to bottom, and the first match determines the outbound. When a rule object includes multiple conditions, such as domain and ip, all of them must match. Multiple entries in the same domain array are alternatives. To route directly when either the domain or IP matches, split them into two rules as shown here.

For example, if a site is in the cn category but your tests require it to always use the proxy, insert the following object at the start of the rules array. example.com is a reserved example domain used to demonstrate the syntax; replace it with the domain you need to test.

{
  "type": "field",
  "domain": [
    "domain:example.com"
  ],
  "outboundTag": "proxy"
}

• Put manual exceptions first: Override only the domains that genuinely need a different outbound, making the change easy to roll back.
• Next, add domain categories: Apply explicit domain-based routing to known sites.
• Then add IP categories: Match requests made directly to IP addresses, as well as requests that are resolved first when the strategy allows it.
• Check the fallback last: This example uses the first outbound and does not add an all-match rule.

“Private IPs must always be matched first” isn't true for every setup. If a domain exception should take priority over its resolved IP address, preserve that order. If all private addresses must go direct, account for domain exceptions, DNS responses, and the resolution strategy. For corporate networks, confirm your address plan first; don't apply a public-network example over your existing policy without review.

5. Apply the Rules and Check the Active Configuration

v2rayN is a desktop client. v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. The client interface generates or loads the configuration, but the selected core executes the rules. Full custom configurations and standard node-mode settings have different entry points and scopes. Don't change both and then guess which one took effect.

1. Back up your current configuration

   Note the active server, routing profile, and local listening port, and save your current custom configuration. Confirm the server connects before changing routes.

2. Open the routing settings

   In v2rayN, the usual path is Settings → Routing Settings; in v2rayNG, open the side menu and select Routing Settings. Names may vary between versions, so follow the current interface. Review the existing rules before making changes; don't delete the whole profile.

3. Choose a configuration method

   In the visual rule editor, enter the domains, IPs, and target outbounds separately, then check the order. Merge the routing object in this guide only when using a full custom configuration. Don't paste an entire JSON object into a field that accepts only a list of domains.

4. Check the actual tags

   Review the generated or loaded configuration. Confirm that both direct and proxy exist, and check the first outbound. The interface options “Direct” and “Proxy” may map to different tags, so use the names in the actual configuration.

5. Restart and check the logs

   Save and activate the routing profile, then stop and restart the connection. Check the runtime logs for rule parsing errors, missing resource files, or unknown outbound tags. Saving the editor doesn't necessarily reload the running core.

When comparing core behavior, record the core and its version—not just the client version. v2rayNG and v2flyNG use different cores, not just different interfaces to the same core. Check extension fields and resource-loading behavior separately for each custom configuration. For details on basic fields, see the site's JSON Reference.

6. Verify Routing with Requests and Logs

First confirm that requests reach the core, then check that they use the expected outbound. Browser extensions, system proxy bypass lists, and terminal environment variables can all change the request path. The examples assume a SOCKS listener is active at 127.0.0.1:10808. Port 10808 is for demonstration; it isn't the default on every installation. Replace it with your active listening port before running the commands.

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://www.baidu.com/
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

socks5h tells curl to send the domain to the proxy, which is useful for testing domain rules. It doesn't guarantee that DNS lookups go through the remote proxy. The first request tests the cn domain category; the second tests the fallback for a domain outside the direct-route categories. A successful HTTP response confirms that a connection was made, but check the access log's destination address and outbound tag to verify the actual route.

To test a LAN address, use a device that actually exists on your network, such as a router at 192.168.1.1. That's just an example address. If the device doesn't serve web pages, a failed connection doesn't mean the routing rule is wrong. Logs show which outbound was selected; whether the destination service responds is a separate check.