DOWNCLASH.COM · ADVANCED

Advanced Clash Configuration — TUN Mode, Proxy Groups, and Performance Tuning

For users who've already finished basic installation and setup — a deep dive into advanced proxy group usage, a complete TUN mode walkthrough, advanced Fake-IP and DNS configuration, advanced rule provider usage, and common performance and stability tuning tips.

Difficulty: Advanced Reading Time: ~12 minutes Recommended First Read: Basic Tutorial

01 Advanced Proxy Group Usage

A proxy group determines how a set of nodes gets selected, whether automatically or manually — picking the right type can noticeably improve day-to-day stability.

TypeBehaviorBest For
selectFully manual selection, no automatic switching.When you want to stick with a specific node long-term, or control routing manually.
url-testRuns periodic latency tests and automatically switches to the lowest-latency node.The go-to choice for everyday use — get a good route with no manual effort.
fallbackTries nodes in order, only switching to the next one if the current node fails.When you want to prioritize a main node and only switch on failure.
load-balanceSpreads connections across multiple nodes instead of using just one.When multiple nodes have limited bandwidth and you want to combine capacity or spread the load.
relayChains multiple nodes together in sequence, with traffic passing through each hop one after another.For scenarios that need multiple hops to boost anonymity or bypass specific restrictions — speed will drop.
# Combo example: outer group uses select to switch regions manually, inner group uses url-test to auto-pick the best node
proxy-groups:
  - name: "PROXY"
    type: select
    proxies: ["HK-AUTO", "SG-AUTO", "JP-AUTO"]
  - name: "HK-AUTO"
    type: url-test
    proxies: ["HK-01", "HK-02"]
    url: "http://www.gstatic.com/generate_204"
    interval: 300
Tip:Proxy groups can reference each other in a nested structure (as in the example above) — a common pattern for building a two-layer setup of "manually pick a region + auto-select the best node." See the proxy-groups field reference for all fields.

02 TUN Mode Explained

TUN mode creates a virtual network adapter at the system network layer that handles almost all network traffic on the device, offering better compatibility than system proxy mode — especially for games and certain client software that ignore system proxy settings.

# Minimal config to enable TUN mode
tun:
  enable: true
  stack: gvisor
  auto-route: true
  auto-detect-interface: true

# TUN mode is best paired with Fake-IP
dns:
  enable: true
  enhanced-mode: fake-ip

Authorization by Operating System

OSAuthorization Method
WindowsRun the client as administrator — the TUN/TAP driver installs automatically the first time you enable it.
macOSThe first time you enable it, you'll be asked to install a network extension or VPN configuration — confirm in System Settings.
Android / iOSThe system will show a VPN connection authorization prompt that needs manual approval.
LinuxNeeds to run with root privileges, or the binary needs CAP_NET_ADMIN capability configured.
Tip:If you can't get online after enabling TUN mode, first confirm that both auto-route and auto-detect-interface are enabled. If the problem persists, try switching stack from gvisor to system to rule out a network stack compatibility issue.

03 Advanced Fake-IP & DNS Configuration

Fake-IP has the core return a fictitious local address during DNS resolution, deferring the actual connection target decision until traffic passes through the core — this lets domain-matching rules (like DOMAIN-SUFFIX) apply more accurately, and it's the recommended pairing for TUN mode.

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - tls://1.1.1.1:853
    - tls://8.8.8.8:853

Field Reference

FieldDescription
fake-ip-rangeThe virtual address range used by Fake-IP — typically a private range to avoid conflicting with real LAN addresses.
fake-ip-filterA domain whitelist excluded from Fake-IP — often needed for LAN devices and login/auth services that require direct LAN access.
nameserverThe upstream DNS used for normal resolution — for mainland China addresses, we recommend using a mainland China-based resolver.
fallbackThe backup encrypted DNS used when a nameserver's result is judged to be polluted (e.g. the returned IP isn't in the expected region).
Tip:For router admin pages on your LAN, and login/auth services that require a direct LAN connection, we recommend adding them to fake-ip-filter to avoid access issues caused by being routed incorrectly.

04 Advanced Rule Provider Usage

A rule provider keeps a large batch of rules centrally maintained in a remote file, which clients periodically fetch and update, avoiding manual line-by-line upkeep. Combining rule sets with different behavior values lets you build a complete, continuously updated routing setup.

rule-providers:
  direct-domain:
    type: http
    behavior: domain
    url: "https://example.com/direct-domain.txt"
    path: ./ruleset/direct-domain.yaml
    interval: 86400
  private-ip:
    type: http
    behavior: ipcidr
    url: "https://example.com/private-ip.txt"
    path: ./ruleset/private-ip.yaml
    interval: 86400

rules:
  - RULE-SET,private-ip,DIRECT
  - RULE-SET,direct-domain,DIRECT
  - MATCH,PROXY
Tip:We don't recommend setting the update interval (interval) too short — rule sets don't usually change often, and overly frequent fetching just adds unnecessary network requests. For detailed advice on choosing rule sets, see the blog post The Complete Guide to Rule Providers.

05 Performance & Stability Tuning Tips

1
Trim Your Rule ListThe more rules you have, the more overhead each match incurs. Merge rarely used rules into a rule set, and keep only a small number of high-frequency custom rules in your local list.
2
Set a Sensible Test IntervalSetting url-test's interval too short adds extra traffic and CPU usage; too long delays switching away from a bad node. 300–600 seconds is a good middle ground.
3
Avoid Unnecessary Multi-Hop ChainsChaining multiple nodes with the relay type significantly increases latency — only use it when truly necessary, such as when multiple hops are required.
4
Set the Log Level as NeededFor everyday use, we recommend setting log-level to warning or error, switching to debug only temporarily when troubleshooting, to avoid generating large log files over time.
5
Keep the Core and Client Up to DateNew versions usually include performance improvements and protocol compatibility fixes — check the download page regularly for updates.
Want to learn more? The config docs center has the full field reference, the FAQ covers the most common issues, and the glossary helps you understand the terminology.