v2rayN routing rules: domains, processes and rule order

Define the intended result first

A maintainable routing setup gives each traffic class a clear destination and produces evidence that the decision was applied. Start with one verifiable exception, then expand the ruleset gradually.

1. Write a traffic-intent table

Suppose you want internal services to stay direct, a work website to use a stable node and everything else to retain the existing policy. Begin with the target, intended outbound and verification method. That description remains useful even when the UI or core changes.

Traffic class	Intended handling	Evidence to collect
A known local device	Direct	Reachability and the expected connection record
A work domain requiring a fixed exit	A validated node or group	A new connection uses the specified outbound
One selected application	Proxy or direct according to the task	The actual process and its new requests match
Everything else	Preserve the existing default	A non-matching sample is unaffected

This is a design example, not a universal configuration. An internal service may require a particular corporate VPN. A private IP address alone does not establish that the physical interface is the correct path.

2. Order determines which rule takes effect

The official v2rayN UI guide describes ordered matching: once an earlier rule matches, a later one does not choose the outbound for that request.^[1] Xray documents the corresponding routing behavior.^[2] A precise exception placed below a broad matching rule can therefore remain ineffective.

Review rules as narrow exceptions, necessary general rules and a final default. The relative priority of local services, work domains and blocked destinations depends on your intent. Do not assume an advertising rule must always be first.

Duplicate the working ruleset before editing and give the copy a recognizable name such as routing-before-test. Add one rule at a time and explain its purpose in the remark. Keeping the original makes both diagnosis and rollback much easier.

3. Verify one exception with two destinations

This example illustrates a single direct-domain exception followed by a proxy default. It uses v2rayN's custom-routing export form, not a complete configuration that can be passed to any core. Replace the demonstration domain example.com with an intentional target and test in a ruleset copy.^[3]

[
  {
    "remarks": "example-domain-direct",
    "domain": ["domain:example.com"],
    "outboundTag": "direct",
    "enabled": true
  },
  {
    "remarks": "remaining-traffic-proxy",
    "port": "0-65535",
    "outboundTag": "proxy",
    "enabled": true
  }
]

In Xray domain syntax, domain:example.com covers the domain and its subdomains. Check the full: match type when only one exact hostname should match.^[2] A broad keyword match is a poor substitute for a precise business-domain exception.

Request the target domain and confirm the direct outbound. Then request another test destination outside that domain and confirm that the proxy still applies. These positive and negative controls distinguish a correct exception from an accidental change that sends everything directly.

4. Processes and strategy groups solve different problems

A process rule identifies which application's requests should match. A strategy group selects a proxy member after routing has chosen the group. Before relying on process matching, verify what process information the core actually sees. Browser helpers, launchers, updaters and the main executable may have different names. OS permissions, core version and capture method also affect availability.

The v2rayN rule editor documentation recommends filling only one of Domain, IP or process name in each rule. Other fields, such as port and network type, further constrain matching.^[1] This editor behavior is not interchangeable with writing a core's native rules directly. Identify the configuration layer before importing anything.

If a rule selects a group, validate at least one compatible member independently. For a work service that values a stable session, a small predictable group is easier to reason about than random exits across regions. A successful rule match does not prove the selected member can complete the request.

5. Maintain DNS and rules together

Domain matching depends on the core obtaining the relevant hostname. IP matching may involve resolution, depending on the core and resolution strategy. Browser encrypted DNS, direct IP access, sniffing and FakeIP can change the available evidence. When a domain rule does not match, first establish what the core observed instead of adding more domain entries blindly.

Rulesets also have sources and versions. Record the import URL, update time and purpose. Rerun representative tests after a remote ruleset changes. New fields or formats may not work with an older core. Xray JSON, sing-box rule sets and other clients' formats are not interchangeable files.

Some videos block UDP port 443 to change QUIC behavior. This is not a universal speed improvement: an application might fall back to TCP, or its behavior and performance might worsen. If the experiment is relevant, isolate it, document it and compare before and after. Do not turn it into a blanket block on all UDP traffic.

6. Finish with five acceptance checks

Positive sample: The intended domain or process matches the new rule.
Negative sample: An unrelated destination retains the previous policy.
Internal access: Local devices and required internal services still work.
Persistence: The rules and groups remain usable after a core restart and subscription update.
Rollback: Selecting the original ruleset restores the previously working behavior.

Keep a compact set of acceptance samples for later changes. A single fast video load, exit-IP result or speed screenshot cannot validate the whole policy.

Are more rules better? Not necessarily. Overlapping, redundant or stale rules make the setup harder to understand. Keep rules with a clear purpose and a reproducible check.

Does a successful import prove compatibility? No. Check core startup, generated rules, actual matching and outbound reachability as separate steps.

YouTube research references

The public titles, descriptions and chapter indexes informed topic selection and UI context. These articles are original guides, not video transcripts. Technical details are checked against the official sources below.

科技分享 · v2rayN tutorial 2025-09-2809:15 · 13:30
阿尔忒弥斯实验室 · v2rayN tutorial 2026-09-1009:40 · 10:29

Official sources and scope

Reviewed on 2026-10-26. Menu names and capabilities vary with client, core and operating-system versions. The checklists are suggested procedures, not published performance benchmarks.