Clash Advanced Configuration Guide

How the Rule Engine Matches Requests

Clash's rules form a "top-down, first match wins" list: every network request is compared against the rules list starting from the first line, and as soon as a rule matches, its action is executed immediately — none of the rules below it are ever checked.

This means the order of your rules is itself a form of priority design. A common approach is to write "must connect directly" rules first (like internal addresses or local sites), then "must proxy" rules for specific cases, and finish with a single MATCH catch-all rule to handle "what happens if nothing above matched."

rules:
  # 1. Route private network ranges directly to avoid detouring proxy traffic to LAN devices
  - PRIVATE,DIRECT
  # 2. Route Mainland China IPs directly (the GEOIP rule set updates automatically)
  - GEOIP,CN,DIRECT
  # 3. Force specific domains through a particular proxy group
  - DOMAIN-SUFFIX,openai.com,US-Node
  - DOMAIN-KEYWORD,googlevideo,Auto
  # 4. Catch-all: anything that didn't match above goes to Auto Select
  - MATCH,Auto

Rule Types Explained

Clash's rule types generally fall into three categories: by domain, by network address, and by other attributes. The table below lists the most commonly used ones:

The last segment of each rule is the "action," which can be DIRECT (connect directly), REJECT (block — commonly used for ad-blocking), or the name of a proxy group (hand the traffic to that group to pick a node based on its strategy).

Rule Provider: Subscribing to Rule Sets

Hand-writing hundreds of domain rules isn't practical. Clash offers a rule-providers mechanism: download a rule set file from a remote URL and refresh it on a schedule, referencing it just once in your config.

rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://example.com/rules/reject.txt"
    path: ./rules/reject.yaml
    interval: 86400

rules:
  - RULE-SET,reject,REJECT

behavior determines how the content of this rule set is parsed, with three possible values:

interval is in seconds — it's how often the rule set is automatically re-fetched, keeping things like "newly blocked ad domains" or "newly added direct-connect domains" up to date without any manual maintenance.

Proxy Groups: Four Scheduling Strategies

A proxy group (proxy-groups) wraps multiple individual nodes into a single "strategy unit." Rules reference the group name, not a specific node — this is what makes things like "automatically pick the fastest node" or "automatically switch when a node goes down" possible.

proxy-groups:
  - name: Auto
    type: url-test
    proxies: [HK01, HK02, JP01]
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50

  - name: US-Node
    type: fallback
    proxies: [US-West01, US-East01]
    url: "https://www.gstatic.com/generate_204"
    interval: 300

tolerance is the "tolerance," measured in milliseconds: as long as a new speed test result is within this range of the current node's latency, Clash won't switch nodes — avoiding constant flip-flopping between two nodes with similar latency.

DNS & Fake-IP

DNS resolution accuracy is the key to accurate rule-based routing — if a domain resolves to the wrong IP, or your ISP's DNS is tampered with, even perfect rules won't help. Clash's built-in DNS module exists to solve exactly this problem.

There are two core domain resolution modes:

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

The idea: put your ISP's plain DNS in nameserver for fast local resolution first. If fallback-filter decides the result looks off (the resolved IP doesn't match the expected region, suggesting tampering, or the domain is actually hosted elsewhere), it switches to the encrypted DNS in fallback to re-resolve — balancing speed and accuracy.

How TUN Mode Works Under the Hood

A system proxy can only take over apps that are "proxy-aware" (browsers and most desktop software), but many programs — games, command-line tools, some mobile apps — don't read the system proxy settings. That's when you need TUN mode.

TUN mode works by creating a virtual network adapter at the OS level and pointing the system's default route to it. That way, regardless of whether a program is "proxy-aware," its network packets pass through this virtual adapter first, where Clash intercepts and processes them according to your rules, then decides whether to connect directly or forward to a proxy node — essentially a network-layer hijack, rather than "convincing" apps to use a proxy at the application layer.

tun:
  enable: true
  stack: system
  dns-hijack:
    - any:53
  auto-route: true
  auto-detect-interface: true

stack is usually set to system or gvisor: system uses the OS's native network stack for better performance; gvisor is a pure userspace network stack implementation with stronger compatibility — worth trying if your system's TUN driver is unstable.

Scripting & Logic Rules

When regular rule types aren't enough, Clash's enhanced core (such as mihomo) supports two more flexible approaches:

• Logic Rules: combine multiple conditions with AND / OR / NOT — for example, only proxy if "the destination port is 443 and it belongs to a certain IP range," written as AND,((DST-PORT,443),(IP-CIDR,10.0.0.0/8)).
• Script Provider: lets you write a small script that dynamically returns which proxy group a request should use at runtime, for complex decisions that regular rules can't express — like "depending on the current network" or "depending on time of day." This is an advanced technique; we recommend mastering regular rules first.

Performance & Experience Tuning

• Shortening url-test's interval detects slowing nodes faster, but also increases the frequency of speed-test requests and battery usage — 300 seconds works well on desktop, 600+ seconds is recommended on mobile.
• Don't add too many rule sets — each additional rule-providers entry uses more memory and increases the computation needed for rule matching. Prefer a few actively maintained, broad-coverage rule sets over stacking a dozen heavily overlapping sources.
• Order your rules sensibly: put the highest-hit-rate rules (like GEOIP,CN,DIRECT) as early as possible so most requests finish matching faster, cutting down on unnecessary line-by-line comparisons.
• On mobile, prefer the system proxy over TUN unless you genuinely need to capture non-proxy-aware apps, since TUN mode can increase background battery drain on some phones.

After reading through these sections alongside a real configuration, we recommend continuing to the Full Configuration Reference to review every field's default value and valid range, building out a complete mental map.