V2Ray Routing Rules: Domain, IP, Geosite Syntax and Rule Order

1. Routing Match Targets and Evaluation Order

V2Ray's routing selects an outbound based on details such as the connection's destination address and port, network type, and inbound tag. It is not a web content filter and does not route by URL path. Two pages on the same domain generally won't match different domain rules just because their paths differ.

routing.rules are evaluated from top to bottom in array order. Once a rule matches, its specified outbound handles the connection; later rules aren't checked to see whether they're “more specific.” Put exact-domain exceptions before suffix rules, and specific rules before catch-all rules.

• Between rules: The first matching rule wins. Rules aren't automatically sorted by domain length, prefix type, or network size.
• Within one field: For example, any matching entry in a domain array is enough.
• Across different condition fields: If you specify both domain and port, both must match. Putting domain and ip in the same rule does not mean “domain OR IP.”
• If no rules match: In a standard config without other routing mechanisms, V2Ray uses the first outbound in the outbounds array. That may not be a direct connection.

2. Syntax for domain, full, regexp, and geosite

domain is a rule field; domain: is a match prefix used inside that field. Don't confuse the two. The examples below all use the reserved example domain example.com to illustrate syntax, not to recommend routing for a real service.

To match a site and its subdomains, use domain:example.com rather than relying on a bare string. Use full: when you want to match only one hostname. Domain entries should not include https://, a port, a path, or query parameters; those aren't valid input for this field.

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

The three domain entries in this JSON are OR conditions. After JSON decoding, \\. becomes the \. required by the regular expression. A single backslash may cause the config to fail during JSON parsing. Use the Go regular expression syntax supported by the core; backreferences and lookarounds aren't supported.

3. Combining ip, geoip, and destination ports

The ip field accepts individual IP addresses, CIDR ranges, and geoip: dataset references. For IPv4, /32 denotes a single address; 192.0.2.0/24 is a documentation-only example range. Don't put CIDR ranges in the domain array or add https:// to entries in the ip array.

{
  "type": "field",
  "ip": [
    "192.0.2.0/24",
    "2001:db8::/32"
  ],
  "port": "443",
  "network": "tcp",
  "outboundTag": "direct"
}

This rule matches only connections whose destination falls within either of the two example ranges, whose destination port is 443, and whose network is TCP. It won't match TCP port 80 on the same address or UDP port 443. port means the destination port, not the client's local listening port. To distinguish local inbounds by tag, use inboundTag.

• geoip:private is commonly used to route private and local address ranges. Its exact coverage depends on the data file being loaded.
• geoip:cn references an IP category; geosite:cn references a domain category. They aren't interchangeable.
• Domain and IP categories don't always produce the same result. A domain may resolve to CDN addresses in different regions.
• An IPv4 range alone won't match IPv6 connections. In dual-stack environments, check which address family is actually in use.

4. How domainStrategy Controls DNS Resolution for Routing

routing.domainStrategy controls how routing handles domain-name destinations. It is not the same as system DNS settings or a similarly named setting on an outbound. Even if routing doesn't resolve the domain, a later outbound may still need to resolve an address to connect to its server.

One easy-to-miss case: using IPIfNonMatch while adding a final rule that matches all TCP and UDP traffic. A domain request will match that catch-all directly, so you can't expect the core to resolve it and try again after an earlier geoip rule fails. If domain rules should take precedence, followed by routing based on the resolved IP, review the resolution strategy and catch-all rules together.

If the application already gives the core an IP destination, routing doesn't need this setting to obtain that address. However, the domain name may no longer be available. Inbound sniffing can recover domain information for some protocols, but this depends on the traffic type and configuration; enabling it does not restore domain names for every connection.

5. A routing Example to Check Rule Order

This is a config snippet, not a standalone, complete config. It assumes you already have outbound tags proxy, direct, and block, pointing to proxy, direct, and blocking outbounds, respectively. These tags are user-defined, not reserved names created by the core. This example also requires a loaded data file that includes the private category.

{
  "routing": {
    "domainStrategy": "IPOnDemand",
    "rules": [
      {
        "type": "field",
        "domain": ["full:status.example.com"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "port": "6881-6889",
        "outboundTag": "block"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

1. Exact exception first: status.example.com matches rule 1 and goes direct; it won't fall through to rule 2's domain-suffix match.
2. Site rule next: www.example.com matches rule 2 and uses proxy.
3. Private addresses next: If neither of the first two rules matches, a private address can match rule 3. A domain destination may be resolved on demand here.
4. The port rule isn't a global block: Rule 4 handles only connections not matched earlier. Connections already matched by a site or private-address rule won't reach it.
5. Explicit catch-all last: Remaining TCP and UDP connections match rule 5. IPOnDemand gives the earlier IP checks a chance to run first.

You can add a domain rule using geosite:cn if it fits your needs, but don't route every match just because the category name looks familiar. First confirm that the data file loads, then decide whether this rule belongs after exact-domain exceptions, before IP rules, or elsewhere. Data updates can also change which domains match.

6. Checking the Effective Config in the Client

UI labels and routing import methods vary across versions of v2rayN, v2rayNG, and v2flyNG. When troubleshooting, note the client version, core name, and routing mode, then find the rule set currently in use. Don't mistake VMess or VLESS connection settings in a subscription node for routing rules: nodes define outbound connections; routing selects which one to use.

1. Back up your current rules: Save the routing config before editing. Subscription updates are generally for updating nodes, not a universal way to distribute custom local routing rules.
2. Confirm traffic reaches the core: Check whether the app uses the system proxy or a specified local proxy. Requests that don't enter an inbound aren't controlled by these rules.
3. Check the generated config: Verify the actual order of routing.rules and confirm that outboundTag exactly matches a value in outbounds[].tag.
4. Apply the changes and test again: After saving the rules, reload the config or restart the core as required by the client, then create a new connection. Browser connection reuse may keep existing connections on their original outbound.
5. Check the logs: Temporarily set the log level to info if needed, then inspect the inbound, destination, and selected outbound. Log formats vary by core and may not show the rule index.

Change one condition at a time. First use full: to test routing for a specific domain, then switch to domain: to expand the match, and finally add a geosite or geoip category. For context on config objects, use the configuration reference to check inbound, outbound, and DNS fields.

7. Common Questions About Routing Rules