Clash clientsDownload & setup

Routing rules direct connections based on domains, destination IPs, or rule sets. A single config can route selected services through a proxy, send LAN traffic direct, and reject requests that match specific rules. Rules are checked from top to bottom, and the first match applies. Put specific rules before broader ones, then use MATCH at the end for any remaining connections. Unlike switching a single global outbound, this approach lets you handle each app's network needs separately. When making your first change, add just one domain rule and check the connection log to confirm it matches. This makes it easier to pinpoint issues than changing several things at once.

A proxy group gives nodes or other groups a name that rules can reference. Use select for manual choice, url-test to pick an outbound based on test results, fallback to find an available option in order, or load-balance to distribute connections. Define your node sources first, create proxy groups next, and then reference their names in rules. This makes the configuration easier to follow. Proxy groups also avoid repeating node names across rules when you change outbounds. Automated checks only show whether a test target is reachable; verify real-world behavior in your apps rather than choosing an outbound based on a single test.

TUN mode routes connections through a virtual network interface. It can help with apps that ignore system proxy settings or when you need to capture more network traffic. TUN and rule-based routing are not alternatives: TUN controls how connections enter the core, while rules determine where they go. Before enabling it, make sure the client has the required permissions and check for conflicts with other VPNs, routing settings, or security software. TUN operates at a lower network level than a standard system proxy. For troubleshooting, first verify that the basic proxy works, then enable routing and DNS interception one at a time. Keep a way to restore your original network settings.

DNS settings handle domain resolution. Fake-IP maps domains to virtual IP addresses so their domain names remain available for rule matching. It is not a proxy node and does not choose an outbound. When configuring DNS, consider whether the resolver is reachable, how DNS requests are routed, and whether LAN services are compatible. If a device or app cannot handle virtual IPs, add filters as needed. Built-in client DNS involves more than changing system DNS: check it alongside routing and TUN settings. After making changes, reconnect so stale cache entries do not affect your results.

A Profile is where a client stores and switches configurations. It can come from a local YAML file or be generated from a remote subscription. After importing, select the intended Profile and make sure the core has loaded it; seeing a file in the list does not mean it is active. Remote updates may replace the original subscription content, so manage persistent rules with the client's supported override or merge features. Keeping subscription sources separate from local changes makes rollbacks easier than repeatedly editing downloaded files. Give each Profile a purpose-specific name and note when it was last updated. Subscription URLs often contain access credentials, so keep them out of public screenshots and shared logs.