Rules are an ordered JSON array

Each object is a rule. enabled toggles it, remarks labels it and outboundTag selects an existing outbound. The client editor schema is not identical to a native core configuration; export client rules as a starting point.

After saving, activate the rule set and reapply the profile. Evaluation stops at the first matching rule.

Common matching fields

Multiple values within a condition generally provide alternatives; different conditions constrain one another. v2rayN splits domain, IP and process fields when combined, so use one of these per rule.

FieldSyntax and effect
domainArray: full:example.com exact; domain:example.com includes subdomains; regexp: regex; geosite: category
ipIP, CIDR or geoip: category; geoip:private matches private ranges
portDestination port or range, e.g. 443 or 1000-2000
sourcePort / sourceSource port / IP constraints, subject to core support
networktcp, udp or both
protocolSniffed application protocol such as http, tls or bittorrent; requires sniffing
inboundTagMatch the inbound that received the request
outboundTagdirect, proxy, block, or an existing custom tag
enabled / remarksClient enable flag / label

Start with a precise rule

This example sends example.com and its subdomains directly and everything else through proxy. The catch-all belongs last. In an existing rule set, add the specific rule before its existing catch-all.

JSON · client routing rulesCopy
[
  {
    "remarks": "Example domain direct",
    "domain": [
      "domain:example.com"
    ],
    "outboundTag": "direct",
    "enabled": true
  },
  {
    "remarks": "Fallback proxy",
    "port": "0-65535",
    "outboundTag": "proxy",
    "enabled": true
  }
]

Common rule combinations

Use direct rules for private IP ranges and private domains to keep local resources reachable, with matching GEO data installed. A rule with network=udp, port=443 and outboundTag=block blocks UDP 443 and can affect QUIC/HTTP/3; it is not a universal connection fix.

Domain rules need domain information. An app connecting directly to an IP may not match them. Sniffing, DNS mode and application-managed encrypted DNS affect what the core can see.

Domain resolution strategy

Xray AsIs keeps the domain during routing; IPIfNonMatch resolves after domain matching fails; IPOnDemand resolves when an IP-based rule needs it. This routing policy is separate from actual outbound DNS resolution.

Place domain rules deliberately and avoid broad IP rules taking precedence unintentionally.

DNS settings

Import, validate and revert

Import rules from a file, clipboard or subscription URL. Keep the old set, use valid JSON without comments/trailing commas, verify outbound tags and data categories, and avoid an overly broad first rule.

Test a specific destination with a new connection and inspect the selected outbound. Existing long-lived connections may retain their old path; restart the target app if needed. Revert to the previous rule set on failure.