Clash Rule-Based Routing Explained:
Smart Traffic Splitting Configuration Guide

What Is Split Tunneling?

Split tunneling (rule-based routing) is one of Clash's most powerful features. In simple terms, it automatically decides for each network request whether it should connect directly or be forwarded through a proxy node, based on a set of predefined rules.

A typical example: you want certain services (like local intranet, streaming with regional content, or latency-sensitive gaming servers) to connect directly for maximum speed, while other traffic goes through your proxy. All of this happens seamlessly in the background — no need to manually toggle the proxy on and off. Users running both domestic and international services benefit enormously from proper split tunneling: domestic sites get native speeds, while restricted international services remain accessible at all times.

The foundation for rule-based routing is the rules field in your Clash configuration file. Understanding how it works lets you customize traffic routing to fit your exact use case — from simple "China Direct / Others Proxy" setups to fine-grained per-app routing.

Rule File Structure

Clash uses YAML-format config files, and all rules are written under the rules: field. Each rule follows this format:

- TYPE,VALUE,POLICY

The three parts mean:

• TYPE: The matching method — determines how traffic is identified.
• VALUE: The specific match target, such as a domain name, IP range, or country code.
• POLICY: The action to take when the rule matches. Common policies: PROXY (route through proxy), DIRECT (connect directly), REJECT (block the request, useful for ad filtering).

Rules are evaluated top-to-bottom. Once a match is found, its policy is applied immediately and evaluation stops. This makes rule order critically important: ad-blocking rules should come first, followed by proxy rules, then direct rules, and finally a catch-all MATCH rule at the very end.

Common Rule Types

Domain Rules (Most Common)

Domain rules are the most widely used rule type, with three levels of matching precision:

• DOMAIN,www.example.com,PROXY — Exact match: only applies to www.example.com, not subdomains.
• DOMAIN-SUFFIX,example.com,PROXY — Suffix match: matches example.com and all its subdomains (mail.example.com, api.example.com, etc.). The most commonly used domain rule type — one rule covers an entire domain family.
• DOMAIN-KEYWORD,googleapis,PROXY — Keyword match: matches any domain containing googleapis. Flexible but may produce false positives — use carefully and prefer suffix matching when possible.

IP Address Rules

When domain rules aren't sufficient, you can route traffic by IP range. This is useful for services that don't resolve through predictable domains, or for keeping local network traffic direct:

• IP-CIDR,192.168.0.0/16,DIRECT — Matches the given IP range. Commonly used to keep local/private network traffic direct and prevent your router from seeing traffic routed back through a proxy.
• IP-CIDR6,::1/128,DIRECT — Same as above, for IPv6 addresses. Always include an IPv6 rule alongside your IPv4 rules for comprehensive coverage.
• GEOIP,US,DIRECT — Matches traffic by country/region using a GeoIP database. Useful as a catch-all for traffic from a specific country. Note: GeoIP lookups require a DNS resolution step, which can affect performance if overused.

Process Rules (Mihomo Extension)

The Mihomo core supports rules based on process names, letting you control the routing of an entire application regardless of what domains or IPs it connects to:

• PROCESS-NAME,curl,DIRECT — Route all curl requests directly, useful for local development and API testing.
• PROCESS-NAME,steam.exe,PROXY — Route all Steam traffic through the proxy for accessing international game servers.
• Process rules are supported on Windows and macOS only and require a Mihomo-based core.

Catch-All Rule (Required)

The last rule in the list must be a MATCH rule — it catches all requests not matched by any earlier rule and acts as the default policy:

- MATCH,PROXY

Most users set this to MATCH,PROXY so unrecognized traffic defaults to the proxy. Some advanced users prefer MATCH,DIRECT and manually add proxy rules for specific services — choose based on your setup.

Using Rule Sets (Recommended)

Manually maintaining thousands of domain rules is inefficient and hard to keep up to date. Clash supports referencing external rule set files via the rule-providers field. The community maintains high-quality rule sets covering ad blocking, domain categorization, streaming unlocking, and more — automatically updated daily.

Here's a typical rule set configuration example:

rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/reject.txt"
    path: ./ruleset/reject.yaml
    interval: 86400
  proxy:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/proxy.txt"
    path: ./ruleset/proxy.yaml
    interval: 86400
  direct:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/direct.txt"
    path: ./ruleset/direct.yaml
    interval: 86400

rules:
  - RULE-SET,reject,REJECT
  - RULE-SET,proxy,PROXY
  - RULE-SET,direct,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

interval: 86400 means the rule set file is refreshed every 86,400 seconds (24 hours), keeping rules up to date automatically without any manual effort on your part.

Rule Matching Order & Priority

Clash evaluates rules top to bottom. As soon as a rule matches, its policy is applied immediately and rule evaluation stops. This means rule order is critical:

• Ad-blocking (REJECT) rules should be first, to intercept ad requests early before any processing or DNS lookups occur.
• More specific rules (exact domain match) should come before broader ones (suffix match) to prevent premature coverage.
• Proxy rules should precede direct rules to prevent foreign traffic from being mistakenly routed directly.
• The MATCH rule is always last — it handles all traffic that didn't match any earlier rule.

A well-structured rule order follows this pattern: Reject set → Proxy set → Direct set → GeoIP direct → MATCH,PROXY. This ordering ensures correct routing for the vast majority of use cases and minimizes performance overhead from unnecessary rule checks.

Debugging & Troubleshooting

If traffic isn't routing as expected after setting up rules, work through these checks:

• Check the Connections tab: Clash Verge Rev's "Connections" page shows each request in real time, including the matched rule and applied policy. Search for a specific domain to see exactly which rule is catching it — this is the fastest way to diagnose routing issues.
• Verify rule order: If a domain is hitting the wrong rule, it's usually because a broader rule is positioned above a more specific one. Move the specific rule higher in the list to fix it.
• Refresh rule sets: Outdated rule sets may not include newly created domains. Manually click "Update" on the subscription page or reduce the interval value for more frequent automatic refreshes.
• DNS pollution issues: Some foreign domains return poisoned (incorrect) IP addresses when resolved over the system DNS, causing them to match IP-based direct rules instead of proxy rules. Enable TUN mode with a clean DNS resolver (e.g., 8.8.8.8 or 1.1.1.1 over DoH) to prevent DNS pollution from affecting routing accuracy.

For more advanced Clash configuration tips, visit our Help Center or the detailed tutorials. To understand when to use TUN mode vs System Proxy, see the TUN Mode guide.