Xray Routing Rules: Domain, IP and GeoSite Matching

Routing rules only apply after a connection reaches the core

System proxy settings, TUN capture, and Xray routing operate at different stages. The system proxy determines whether apps that support it send connections to the local inbound. Routing rules then handle connections that have reached the core and choose whether to send them direct, through a proxy, or block them. If a browser bypasses the system proxy, even perfectly configured routing rules won't affect its connections.

This guide uses Xray's native JSON fields. v2rayN and v2rayNG convert their settings into core configuration; v2flyNG uses the V2Fly core, so don't assume every Xray field can be copied over as-is. Before editing, check which core you're using and back up your current routing profile.

• domain is a rule field. Its array can contain matching expressions such as domain:, full:, regexp:, and geosite:.
• ip is a separate rule field that accepts IP addresses, CIDR ranges, and geoip: collections. Don't mistake it for an ip: prefix in a domain array.
• outboundTag references an outbound; it isn't a free-form note. Its value must match a tag defined for an outbound in the final configuration.

domain, full and regexp: narrow down what matches

Overly broad matching is a common cause of misrouted traffic. A bare string is treated as a substring match by Xray. To match a domain and all its subdomains, use domain: explicitly. Enter a hostname in the rule—not a full URL with a scheme, path, or query string.

Regular expressions also require JSON escaping. The raw expression in the routing editor can contain \.; in a JSON string, each backslash must be written as \\. The example below is a valid JSON rule object, not a complete configuration that can start the core on its own.

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

ip, geoip and geosite: different data sources

geosite matches domain collections; geoip matches IP address collections. A site may use multiple content delivery addresses, so its domain category and the geographic location of its actual connection address may differ. To always route a specific site through a proxy, add a domain exception rather than relying only on the IP's location.

{
  "type": "field",
  "ip": [
    "192.168.0.0/16",
    "10.0.0.0/8",
    "geoip:private",
    "geoip:cn"
  ],
  "outboundTag": "direct"
}

The first two entries above show CIDR notation and overlap partly with geoip:private; you can remove the duplicates in practice. IPv4 private ranges alone don't cover local IPv6 addresses, so check whether the private address collection you're using covers both in a dual-stack network.

• Check that the collection exists: Before using geosite:cn or geoip:cn, make sure the core can read the relevant data file and that the file contains the collection.
• Collection update timing: Updating the client configuration and updating geo data are separate operations. A successful subscription update doesn't mean the domain classifications have been updated.
• Extended collection syntax: geosite:collection@attribute is only useful when the data file defines that attribute. Adding a suffix to an arbitrary collection won't make it work.
• Symptoms: A missing data file or collection may prevent the configuration from loading. Check the startup log first instead of assuming every failure means the node can't connect.

Rule priority: top to bottom, first match wins

For each routing decision, Xray checks the rules array in order and uses the first rule that meets all its conditions. A more specific domain in a later rule won't make Xray choose that rule automatically. Put exact exceptions before broader categories, and leave catch-all rules until the end.

Arrays within the same field generally work as “OR”: a domain array matches if any expression matches. Different filter fields within one rule generally work as “AND”: setting domain, port, and network requires all those conditions to be met. Putting domain and IP conditions in the same rule does not mean “match either one to go direct.”

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

This routing snippet illustrates rule order. It assumes the configuration already has three outbounds—direct, proxy, and block—and that the data file includes the example collections. These tag names aren't reserved action names: a typical direct outbound uses freedom, a blocking outbound uses blackhole, and a proxy outbound references the protocol of the actual node.

domainStrategy: when domains are checked against IP rules

Whether an IP rule can match a domain target depends on the routing domainStrategy. This field controls whether the domain is resolved for routing matches; it is not the client's overall DNS setting, nor does it determine how the direct outbound ultimately resolves the target address.

So although the five rules in the previous section specify IPIfNonMatch, a domain target that reaches the final TCP/UDP catch-all has already matched in the first pass. Xray won't resolve it to check the earlier geoip:cn rule. A target that is already an IP can still match the fourth rule. This is a common reason a domain continues to use the proxy despite having a geoip rule.

• To allow a second IP-based check: Remove the explicit catch-all rule and make sure the first outbound used when no rule matches is the intended default.
• To resolve when an IP rule is checked: Consider IPOnDemand. It attempts resolution when a rule needs IP information, but may involve DNS in routing more often.
• To pin one site to an outbound: Add a full: or domain: rule near the top. This is usually easier to verify than changing the overall resolution strategy.

Also, if the inbound receives only the target IP, domain rules can't recover the original hostname on their own. Sniffing may supply domain information for recognizable traffic, but it isn't a universal way to recover domains for every protocol. When troubleshooting, check the inbound target, sniffing settings, and final outbound together.

Reorder rules and verify matches in v2rayN

In v2rayN, open “Settings” → “Routing Settings,” select the routing profile you want to use, and open the rule editor. The edit and move up/down controls may appear in different places across versions. Check the order of the generated routing.rules, not the profile name or rule notes.

1. Copy the profile: Keep the original as a fallback, then add a full: rule for a test domain to the copy. Don't change DNS, sniffing, or the core at the same time.
2. Enter fields separately: Put full:example.com in the domain condition and geoip:cn in the IP condition. If the editor accepts one entry per line, enter one match per line; don't paste a whole JSON object.
3. Check the outbound: Select the required outbound in the outbound options. For a native configuration, make sure outboundTag exactly matches the outbound tag, including capitalization.
4. Reorder the rules: Move the test rule above any rules that could match first. After saving, confirm that this routing profile is selected, then reload or restart the core as prompted.
5. Start a new connection: Close existing webpage connections and visit the site again. Existing long-lived connections usually won't switch outbounds automatically after a rule change; close and reopen the browser if needed.
6. Check the logs: Make sure the core starts successfully, then check the test target's access log and outbound tag. If needed, temporarily increase log verbosity in the logging settings, then restore it after testing to avoid recording large volumes of connection data.

To test “HTTPS only goes direct,” set a domain condition, port: "443", and network: "tcp" in the same test rule. HTTP/3 uses UDP, so it won't meet the TCP condition. A browser opening the same site doesn't prove the rule is failing. The protocol and port must match your test conditions.