V2Ray Custom Routing Rules: Domain, IP, geosite Syntax and Rule Priority

1. Routing rules apply to connections, not subscription nodes

Importing a subscription provides server addresses, authentication, and transport settings. Routing determines which outbound handles each connection. VMess and VLESS are proxy protocols; routing.rules selects traffic. They serve different purposes. A successful subscription update does not mean custom routing is enabled in the active configuration.

Routing may see a domain name or only an IP address. If an application passes the domain through the proxy protocol, domain rules can match it directly. If the application resolves the name first and passes only an IP, domain rules may have nothing to match. Sniffing may recover domain information for supported traffic, but it cannot turn arbitrary encrypted traffic back into a website name.

• type: "field": the field-matching rule type used in this guide.
• domain, ip, port: conditions for matching the target connection.
• outboundTag: references an existing outbound tag; it is not a server address.
• Rules do not change a node’s TLS, transport, or authentication settings. If a connection fails, check those settings separately.

2. Domain syntax: exact matches, subdomains, keywords, and regular expressions

domain is an array of strings. Entries in the same array are joined with “OR,” so any matching entry satisfies the field. Prefer precise patterns: use full: to match one host, domain: to include a root domain and its subdomains, and an unprefixed string only when you specifically need substring matching.

keyword: is not a native prefix here

Some rule editors label their keyword option as keyword, but in the native V2Ray/Xray domain array, keyword matching uses a plain string. Don’t copy keyword:example as a universal pattern; it does not automatically mean “a domain containing example.” The editor’s type selector and the core’s JSON are separate layers, so check the rule that is actually generated.

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

This is a rule object, not a complete client configuration. The three entries match a login host, a documentation domain and its subdomains, and API hosts with numbered names. In the regular expression, \\. is the JSON string representation; the regex engine receives \. after decoding. If you enter a regex in a plain-text field in the client, follow that field’s format—don’t mechanically add another layer of backslashes.

3. ip, geoip, and geosite: keep address ranges and domain sets separate

ip accepts IP addresses, CIDR ranges, and geoip: data references. domain accepts domain patterns and geosite: references. These represent different kinds of data: domain categories classify names, while IP categories classify address ranges. Neither tells you for certain what a website contains, who owns it, or where its servers are physically located.

The example uses two separate rules for direct connections to domain and private IP targets, meaning “direct if either set matches.” Putting domain and ip in the same rule would require both fields to match, not either one.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private", "192.0.2.10/32"],
        "outboundTag": "direct"
      }
    ]
  }
}

• 192.0.2.10/32 is a single IPv4 address reserved for documentation examples, not a real service. Replace it with your own target when testing.
• For IPv4, /32 matches a single address. A single IPv6 address can use /128; enter the appropriate prefix length for a network range.
• geoip:cn is not the same as geosite:cn. The same domain may resolve to addresses in different IP categories.
• If a category fails to load, first make sure the running core can find the required data file, then check the category name. Don’t just keep moving the rule around.

4. Priority: top to bottom, stop at the first match

Routing does not automatically put “more specific” rules first. Each scan follows the order of the rules array, and the first match selects its outbound. Even if an exact domain is more specific than a geosite category, it won’t get a chance to run if it sits below a category rule that has already matched.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["full:login.example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

This snippet shows only the routing section and assumes the full configuration already has outbounds tagged proxy and direct. These are example tags, not names every client uses. In particular, writing direct as a tag does not create a direct outbound.

1. Put specific exceptions first, such as a login host that must use the proxy.
2. Next, add basic network rules, such as explicit local network targets.
3. Then add broader domain or IP categories.
4. Finally, decide what should happen by default. If no rule matches, V2Ray/Xray typically uses the first outbound in the list.

Fields in a rule are generally combined with “AND,” while values within a field’s array are generally combined with “OR.” For example, a rule with both domain: ["domain:example.com"] and port: "443" matches connections to port 443 on that domain and its subdomains. This is the target port, not the client’s local listening port.

5. domainStrategy: whether and when to resolve domains

routing.domainStrategy controls how routing uses DNS results. It is not the browser’s DNS setting, nor a replacement for an option with the same name in an outbound module. Changing it can affect matches and when resolution occurs, but it does not change the basic priority of the rules array.

For example, place geoip:cn before a domain rule that routes traffic through a proxy. With IPOnDemand, the earlier IP condition may trigger a lookup and select direct if the address belongs to that category. With AsIs, a domain-only request won’t be resolved just for this IP rule and may match the later domain rule instead. Different results don’t mean rule order stopped working; the available match data changed.

Now consider IPIfNonMatch: the core resolves and scans the rules again only if the first pass finds no matching domain rule and no other rule catches the request. If the target was already an IP when it entered the inbound, there is no need for an initial domain-based pass. When troubleshooting, record the input target type instead of assuming every connection starts with a domain.

• If you only need straightforward domain-based routing, start with AsIs for a minimal, easy-to-understand setup.
• For “try domain rules first, then check IP if none match,” check IPIfNonMatch and make sure there is no earlier catch-all rule.
• Use IPOnDemand if routing needs resolved IPs during the scan, and review any broad IP categories near the top of the rules.
• Resolution during routing uses the core’s DNS mechanism. Incorrect results, lookup failures, or differences from the application’s own DNS results can all affect category matching.

6. Verify custom rules in v2rayN

The routing scheme in the GUI, the configuration used by the running core, and an edited file on disk may not contain the same settings. Save the current routing scheme first. In v2rayN’s main window, open the routing configuration entry and confirm which scheme is active, then check routing.domainStrategy and routing.rules in the generated configuration. Menu names may vary between interface layouts; rely on the fields and active configuration, and don’t expect edits to a temporary generated file to persist.

1. Create a single test rule. Choose a fully qualified host you can access, use full: at the top of the rules, and point it to an existing outbound tag. Leave regular expressions and category data out for now.
2. Save and apply the configuration again. Reload through the client or restart the core so the changes take effect in the active configuration. Check the startup output for errors such as unknown fields, missing outbounds, or failed category loads.
3. Start a new connection. Close the relevant page and visit it again; restart the test application if needed. Persistent HTTP/2 connections and connection reuse may keep using the old outbound, so refreshing a page may not create a new connection.
4. Check the actual logs. If access logging is enabled, verify the target and outbound tag; temporarily increase the log level if needed. Log formats vary by core, so whether a page opens is not enough to tell which rule matched.
5. Restore complex conditions one at a time. After the exact-domain test works, add domain categories, IP conditions, and DNS strategies. Change only one variable at a time and compare the logs before and after.

A browser session may also connect to the main site, static assets, login APIs, and media domains. A page loading successfully does not mean all its connections use the same outbound. Check logs by target host; don’t treat every request from a page as one connection.