V2Ray Custom Routing Rules: Domain, IP, GeoSite Syntax and Match Priority

1. Routing rules match conditions, then select an outbound

Routing is separate from node connection settings. Protocols such as VMess and VLESS connect to a server; routing decides which outbound handles a request that has reached the core. v2rayN provides the configuration interface, but the active core applies the rules. The JSON syntax below is for V2Ray/Xray and cannot be pasted unchanged into editors for other configuration formats.

A typical rule includes type: "field", match fields, and outboundTag. The tag must match an existing outbound's tag. Setting the tag to proxy does not create a proxy node, and direct does not create a direct outbound. Clients may generate different tags, so check the actual configuration before editing.

These are destination ports, not the client's local listening ports. For example, the rule below sends only requests to port 443 for hosts under example.com through the proxy outbound; it does not cover every connection to that domain.

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

• Multiple values in one field are usually ORed: any matching entry in the domain array satisfies the domain condition.
• Different fields are ANDed: if both domain and port are set, both conditions must match.
• Rules are checked in order: the first rule that fully matches selects the outbound, and later, more specific rules are not considered.

2. Domain, full, and regexp: where domain matching applies

Use domain: to match a base domain and all its subdomains; use full: to match one exact hostname. Don't treat them as interchangeable just because both refer to domains. The domain field takes a hostname, not a URL: leave out the scheme, path, and query string.

Use regular expressions only when you need pattern matching. In the example below, the backslash is doubled in the JSON string so the core receives \. to match a literal period. If the interface accepts raw rule text rather than a JSON string, this extra JSON escaping is unnecessary.

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

3. IP, GeoIP, and GeoSite: keep address and domain sets separate

ip is a JSON field; geoip: is a set reference that goes in its array. Put geosite: in the domain array instead. Both types of set require the corresponding data files to be available to the core. The data files define the set names and contents; the core does not generate results dynamically from a name.

{
  "type": "field",
  "domain": ["geosite:cn"],
  "outboundTag": "direct"
}

{
  "type": "field",
  "ip": [
    "192.0.2.15/32",
    "2001:db8::15/128",
    "geoip:private",
    "geoip:cn"
  ],
  "outboundTag": "direct"
}

The 192.0.2.15 and 2001:db8::15 addresses above are reserved for documentation; replace them with the target service's address when applying the example. IPv4 /32 and IPv6 /128 prefixes each represent a single address. Shorter prefixes generally cover larger ranges. Don't add a large network range just to fix access to one address.

• geosite:cn: Matches domain categories in the data set; it does not guarantee that every IP address a domain resolves to is in the same region.
• geoip:cn: Matches against the set containing the destination IP; it does not guarantee that the site hosted at that address belongs to a particular domain category.
• geoip:private: Matches private and reserved address ranges defined in the data set. A common use is to send local resources directly.
• Missing data sets: If startup logs report that GeoSite or GeoIP could not be loaded, check the data files and entry names first; this is not a node connection issue.

4. Match priority: put exceptions before broad rules

The core does not automatically rank an exact hostname above a domain set. Rules are evaluated from top to bottom in the rules array. If the first rule sends domain:example.com direct, a later proxy rule for full:api.example.com cannot override it. Put exceptions first, broader sets next, and the fallback last.

This is a routing snippet to merge into an existing configuration, not a complete client configuration. It assumes that outbounds already contains tags named proxy and direct, and that the referenced data sets are available. If your tags differ, update them to match; copying only the rules is not enough.

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

This table shows how the configuration evaluates; it is not a network speed test. The example domains may not host real services, so use a known working target to verify a website. If you remove the final fallback rule, unmatched requests usually use the first outbound in the configuration. You can't generally say that unmatched traffic will always use the proxy or always go direct without seeing the full configuration.

5. domainStrategy: why IP rules may not match

When a request reaches the core, its destination may be a domain or an IP address. If only the IP is available, adding a domain rule will not restore the original hostname. Conversely, a request with only a domain usually needs the routing resolution strategy to provide an address before it can match an ip condition. That's why domainStrategy needs to be checked separately.

The previous section uses IPOnDemand so the third address-set rule can be checked before the final fallback. If you switch directly to IPIfNonMatch, a domain request may match the broad fourth rule first, preventing the intended address-based routing. This is not a GeoIP syntax error; the difference is when resolution is triggered.

• When an app explicitly connects through an HTTP or SOCKS proxy and sends the hostname, the core can usually match it directly against domain rules.
• If an app resolves the hostname itself and sends only the IP, the domain information may be lost. Sniffing can try to identify the hostname in supported traffic, but it cannot recover every request.
• Routing's domainStrategy and similar resolution options for outbound connections have different roles. Check the configuration level before changing either one.

6. Configure and verify rules in v2rayN

For everyday use, manage rules in the routing settings interface. v2rayN generates the runtime configuration, so direct edits to temporary JSON files may be overwritten when you restart the service or switch nodes. The steps below use a desktop interface with a 「Settings」→「Routing Settings」 menu; button locations may vary across versions, but you still need to check rule order and outbound mappings.

1. Keep a copy of the existing configuration

   Open 「Settings」→「Routing Settings」 and note the active rule set and domain resolution strategy. Back up the current configuration before making changes; don't clear the default rule set.

2. Add one rule

   In the target rule set, add an exact hostname condition such as full:api.example.com, then select the proxy outbound. Enter only the rule in the domain field; don't paste the entire routing object.

3. Reorder the rules

   Move this exception above the relevant domain:, geosite:, or other broad rules. After saving, confirm that the main window has the edited rule set selected.

4. Reconnect

   Restart the service or reload the configuration, then close the target page's existing connections and visit it again. Existing connections generally won't switch to a different outbound just because you changed a rule.

5. Check the runtime logs

   In the core logs, check the destination hostname, destination port, and outbound tag. Start with a known working website before broadening the rule. If the log level doesn't show enough detail, temporarily set it to info or debug, then restore the previous level when you're done.

Test at least three types of requests: the exception hostname, a regular hostname under the same base domain, and a local network resource. The first two test the boundaries of the domain rule; the third checks whether a broad proxy rule is overriding direct access to private addresses. If no request appears in the logs, first check whether the app is using the current proxy entry point instead of changing the routing expression again.

7. Quick answers to common rule conflicts

Follow the same troubleshooting order each time: confirm the request reaches the core, confirm the hostname or address is available, find the first matching rule, then check whether the outbound can connect. Change one type of condition at a time to tell whether the result comes from rule boundaries, DNS policy, or the node's network.