Advanced Usage When the default config isn't enough

Get the most
out of your config.

Once you've finished the beginner's tutorial, here are six directions for anyone ready to dig into the config file: proxy group speed testing and failover, subscription-based rule set management, DNS and domain sniffing optimization, LAN sharing gateways, multi-subscription local overrides, and taking over your config with an external panel. Every section comes with a ready-to-copy YAML snippet.

Advanced Proxy Group Techniques

Proxy groups decide exactly which node a matched rule uses — combining them well enables auto speed testing, failover, and load balancing.

TypeBehaviorBest For
select Manually pick a node from the list — no automatic switching When you need to stick with a specific node long-term
url-test Runs speed tests on a fixed interval and automatically picks the lowest-latency node When you want consistently low latency without switching manually
fallback Uses the first available node in the list, moving to the next one automatically on failure When your primary node is unstable and you need automatic failover
load-balance Distributes connections across multiple nodes by strategy (round-robin / consistent hashing) When you have plenty of nodes and want to spread bandwidth load
proxy-groups.yaml
proxy-groups:
  # Auto speed test — picks the lowest-latency node
  - name: Auto
    type: url-test
    proxies: [HK-01, HK-02, SG-01]
    url: http://www.gstatic.com/generate_204
    interval: 300      # Speed test every 300 seconds
    tolerance: 50      # Skip switching if the latency gap is under 50ms, avoids flapping
  # Auto-switches to the next backup in order if the primary group fails
  - name: Fallback
    type: fallback
    proxies: [Auto, HK-01, SG-01]
    url: http://www.gstatic.com/generate_204
    interval: 180
  # Final entry point exposed to rules; can be switched manually anytime
  - name: PROXY
    type: select
    proxies: [Auto, Fallback, HK-01, SG-01, DIRECT]

Tip: Rules typically only reference the outermost select group (like PROXY in the example above), which wraps the speed-testing and failover logic in its candidate list — the rule itself doesn't need to care which node is actually used.

Manage Rules with Subscription-Based Rule Sets

A Rule Provider hosts hundreds or thousands of rules as a separate file that updates automatically on a schedule, so you don't have to maintain every rule by hand.

behavior determines the type of data stored in the rule set: domain (a list of domains), ipcidr (a list of IP ranges), or classical (full rule syntax lines). type determines the source: http is a remote subscription that auto-updates per the interval; file is a local file you maintain yourself.

rule-providers.yaml
rule-providers:
  reject:
    type: http
    behavior: domain
    url: https://example.com/reject.txt
    path: ./ruleset/reject.yaml
    interval: 86400   # Auto-updates every 24 hours
  direct:
    type: http
    behavior: classical
    url: https://example.com/direct.txt
    path: ./ruleset/direct.yaml
    interval: 86400

rules:
  # References a rule set — syntax is RULE-SET,name,policy
  - RULE-SET,reject,REJECT
  - RULE-SET,direct,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

Tip: Popular public rule sets (like ACL4SSR and the blackmatrix7 series) already maintain ready-made lists for ad blocking, direct routing for local networks, common app routing, and more — just reference them directly. There's no need to reinvent the wheel unless you have a special requirement.

DNS Configuration Optimization

How DNS resolution is handled directly affects rule-matching accuracy and access speed — it's one of the most worthwhile things to tune in an advanced setup.

We recommend fake-ip for enhanced-mode: the client returns a virtual IP first, then resolves the real domain when the connection is established for rule matching — balancing speed and accuracy. fallback-filter lets you discard DNS results that fall within your local ISP's IP range, which helps detect and avoid DNS pollution or hijacking.

dns.yaml
dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver: [223.5.5.5, 119.29.29.29]   # Base DNS used to resolve the DoH/DoT hostname itself
  nameserver: ['https://doh.pub/dns-query', 'tls://dot.pub:853']
  fallback: ['https://1.1.1.1/dns-query', 'https://dns.google/dns-query']
  fallback-filter:
    geoip: true
    geoip-code: CN   # Only uses the fallback result if the IP falls outside the specified region (CN is just an example — swap for your own)

Tip: If enabling fake-ip causes issues with certain LAN devices (like smart speakers or NAS discovery), add the relevant domains to fake-ip-filter as an exception so they always get a real IP.

Enable Domain Sniffing

In TUN mode, some connections only carry a destination IP with no domain info. Sniffing recovers the real domain from the traffic itself, so domain-based rules still work.

Without decrypting traffic content, Sniffer reads plaintext fields like the SNI in a TLS handshake or the Host header in an HTTP request to determine the target domain, then passes it to the rule engine for matching — commonly used in TUN mode or other forwarding scenarios where domain info isn't passed along.

sniffer.yaml
sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true
  sniff:
    TLS:
      ports: [443, 8443]
    HTTP:
      ports: [80, 8080]
    QUIC:
      ports: [443]

Share the Proxy with Other Devices on Your LAN

Turn the device running Clash into a proxy gateway for your local network, so phones, tablets, smart TVs, and other devices that can't easily run a client can share the proxy too.

  1. Enable allow-lan and change the listen address to 0.0.0.0 or a specific LAN IP.
  2. In the Wi-Fi settings of your other device, point the HTTP / SOCKS proxy to the LAN IP of the device running Clash and its mixed-port.
  3. If you need to cover all traffic on a device (not just the browser), consider setting that device as a router, or configuring policy-based routing on your router.
lan.yaml
mixed-port: 7890
allow-lan: true
bind-address: '*'
authentication:
  # When sharing over LAN, add a username/password to stop other devices on the network from freeloading
  - user1:strong-password

Tip: After enabling LAN sharing, make sure your system firewall allows inbound connections on the relevant port, and set up an authentication username/password first to prevent unknown devices from connecting on public Wi-Fi.

Merging Multiple Subscriptions & Local Overrides

Directly editing the config file pulled from a subscription will get overwritten by the provider's new content on the next update — use the override mechanism to keep your custom parts separate.

Most GUI clients (Clash Verge, the Clash for Windows family) offer an "Override" or "Merge Config" feature: it loads the base config generated from your subscription, then layers a local YAML snippet you maintain on top — the two merge together to take effect. When the subscription updates, only the base part is replaced, leaving your override untouched.

  1. Find the Override option in the client's subscription settings and create a new local override file.
  2. In the override file, only write the fields you want to add or change — for example custom rules, dns, or proxy-groups.
  3. Once saved, the client automatically layers this override on top every time it loads the subscription, so updating the subscription will never wipe out your customizations again.

If you have subscriptions from multiple providers, you can also use the merge feature to combine nodes from all of them under a single set of rules and proxy groups for unified management.

Take Over Configuration with an External Control Panel

With the RESTful API enabled, you can use a browser-based panel (like yacd or metacubexd) to view connections in real time, switch nodes, and hot-reload the config — no need to restart the client every time.

Most GUI clients already have a panel like this built in. If you're running the bare core (Mihomo core), you can manually enable external control and pair it with an open-source panel project.

external-controller.yaml
external-controller: 127.0.0.1:9090
secret: 'replace-with-a-strong-secret'   # Dashboard access secret — be sure to change this yourself

Tip: Keep the listen address set to 127.0.0.1 and use a sufficiently complex secret. Don't expose this port to the public internet — this effectively prevents unauthorized access to or tampering with your config.

FAQ

Advanced Configuration FAQ

A few frequently asked questions about overrides, DNS, and the external panel

Why do my local config changes disappear after a subscription update?

A subscription update overwrites the entire config file with the new content from your provider, reverting any fields you changed directly. We recommend using the client's Override feature to maintain your custom snippets separately — when the subscription updates, only the provider's content is replaced, and your overrides are automatically reapplied afterward.

Should I use fake-ip or redir-host?

fake-ip performs better and resolves the real target domain earlier for rule matching, making it the recommended default. A few scenarios that depend on real IP responses (like some LAN device discovery protocols) may need redir-host, or a fake-ip exception for specific domains.

Is it unsafe to enable the external control panel?

As long as you keep the listen address set to 127.0.0.1 and use a sufficiently complex secret, the risk is very low. We don't recommend binding the external control port to 0.0.0.0 and exposing it to the public internet or an untrusted LAN.

Not familiar with the basics yet?

Check out the tutorial first: installation, importing subscriptions, proxy modes, and the main interface explained.

Go to the Download Page →

Windows / macOS / Android / iOS / Linux — all platforms supported, all free.