V2Ray Custom Routing Rules: domain, ip, and geosite Matching Order

Routing flow and first-match behavior

The V2Ray and Xray routing modules do not establish node connections. Once a request enters the core, they choose an outbound based on the target domain, target IP, port, network type, inbound tag, and other details. The final choice is usually selected by outboundTag, which points to a defined outbound such as proxy, direct, or block.

Rules are stored in the routing.rules array, and the core checks them from the first entry downward. Once a rule satisfies all conditions, scanning stops immediately and later rules do not participate in that request. Therefore, placing more specific rules first and broader rules later is the foundation of a stable configuration.

Different fields in the same rule generally use an “AND” relationship. For example, if a rule contains both domain and port, the target must satisfy both the domain and port conditions. Multiple items within one field generally use an “OR” relationship: if a domain array lists three domains, matching any one of them satisfies that field.

domain: exact domains, subdomains, and keyword matching

The domain field handles the target hostname. Common prefixes include full:, domain:, keyword:, regexp:, and geosite:. The prefix determines the matching scope, so choosing the wrong one can make a rule too broad or prevent it from matching at all.

full:example.com matches only the complete hostname example.com; it does not treat www.example.com as the same target. domain:example.com matches that domain and its subdomains, making it suitable for sending an entire site family through the same outbound.

{
  "type": "field",
  "domain": [
    "full:api.example.com",
    "domain:static.example.net",
    "keyword:media",
    "regexp:^cdn-[0-9]+\\.example\\.org$"
  ],
  "outboundTag": "proxy"
}

• full: Suitable for clearly defined hostnames such as login and update endpoints; it has the narrowest scope.
• domain: Suitable for a root domain and all subdomains; it is the more common form for everyday rules.
• keyword: Matches when the target domain contains the specified string; short keywords can easily match unrelated domains.
• regexp: Suitable for domains with a fixed structure and changing numbers, but complex expressions increase maintenance costs.
• geosite: References a prepared domain category set, which is useful for routing by service type or region.

If an exact domain needs to be an exception to a category rule, place the exact rule first. For example, send full:download.example.com directly, then send domain:example.com through the proxy. If the order is reversed, the download domain will be caught by the whole-site rule first.

ip and geoip: address ranges and domain-resolution conditions

The ip field can contain a single address, a CIDR range, or a geoip: category. A single IPv4 address can be written as 198.51.100.20, while a network can use 198.51.100.0/24. IPv6 ranges also use CIDR notation, such as 2001:db8:1200::/48.

geoip:private is commonly used to match LAN, loopback, and other non-public addresses. Placing these addresses near the start of the direct rule set prevents local router pages, LAN file services, or local interfaces from being sent to a remote proxy.

{
  "type": "field",
  "ip": [
    "geoip:private",
    "192.0.2.0/24",
    "2001:db8:1200::/48"
  ],
  "outboundTag": "direct"
}

Whether an IP rule can handle a request that originally used a domain also depends on domainStrategy. When a target has a domain but no target IP, the core must decide whether to resolve that domain before comparing the result against ip rules.

geosite and geoip: different boundaries

geosite is a domain collection, while geoip is an IP address collection. They classify information at different stages and cannot replace one another. For sites using dynamic addresses, shared cloud services, or frequently changing DNS results, a domain collection usually expresses service ownership better than a fixed IP range.

A geosite:cn rule checks whether the target domain belongs to the corresponding category; a geoip:cn rule checks whether the target IP falls within the corresponding address set. A domain and its server location are not necessarily the same, so the two rules can classify the same connection differently.

Data files must match the core version and the capabilities supported by the configuration. If you see “failed to load geosite” or a category name is not recognized, first confirm that the data file is in the directory actually read by the core, then confirm that the category exists. Changing rule order alone cannot fix a missing data file.

outboundTag and complete rule composition

The value of outboundTag must exactly match the tag of an outbound in the outbounds array. Differences in letter case also count as different names. When a rule contains "outboundTag": "direct", the configuration must define an outbound tagged direct.

A typical order can be divided into four layers: direct access for private addresses, exact exceptions, category routing, and fallback handling. If a blocking rule targets a specific domain or port, place it before any broad proxy rule that could capture it.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "domainMatcher": "hybrid",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["full:updates.example.com"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

1. The first rule handles LAN and local addresses, keeping internal services out of the proxy chain.
2. The second defines a clear exception so the specified update domain always uses a direct connection.
3. The third handles categorized sites by domain without waiting for IP classification.
4. The fourth supplements the decision with resolved address categories when domain rules do not cover the target.
5. Unmatched requests continue along the default path, with the actual exit determined by the complete outbound structure.

If the configuration uses a load balancer, a rule may point to it through balancerTag instead of selecting one outbound directly. For ordinary custom traffic splitting, prefer outboundTag. Introduce balancerTag only when selectors and a load balancer are actually configured, avoiding an unnecessary troubleshooting layer.

Configuration paths and verification in v2rayN

In v2rayN 7.x, open “Settings” → “Routing Settings” to review the current routing configuration and preset rules. Button locations may change between minor versions, but the verification goal is the same: confirm that the active routing configuration, rule order, and generated core configuration agree.

After making changes, do not rely only on whether a browser can open a page. Browser caches, DNS caches, and reused connections can hide the result. Restart the core, connect to a new target, temporarily set the log level to info or debug, and inspect the routing records.

1. Open “Settings” → “Routing Settings”, confirm the selected rule set, and note the expected matching rule.
2. Check each rule’s outboundTag and compare it character by character with outbounds[].tag in the generated configuration.
3. Open “Settings” → “Parameter Settings” and confirm local listening and logging options. Common SOCKS and HTTP ports are 10808 and 10809.
4. Save the configuration and restart the core. Close existing browser connections or use a new test domain.
5. Inspect the target domain, target address, and outbound tag in the logs to determine where rule scanning stopped.
6. Move or change only one rule at a time, test again, and then handle the next change to avoid interference between multiple changes.

Checklist
1. Is the target a domain or an IP
2. Does domainStrategy trigger resolution
3. Is the exact rule before the category rule
4. Does outboundTag exist with matching letter case
5. Did geosite and geoip data load successfully
6. Is the test connection new after the change

Common questions when rules do not work

Routing issues are usually not caused by one syntax error. The target form, resolution strategy, ordering, and outbound tags all contribute. Confirm the target that actually appears in the logs, then compare it with the rule conditions instead of simply widening the match scope.

The final configuration should make each rule’s purpose readable: one clear intent per rule, tag names that describe the exit, and exception rules placed next to the objects they cover. As the rule set grows, clear ordering and minimal conditions are easier to maintain than layers of keywords.