Traffic Routing · Client and Configuration Guides
Choose a client for your operating system, import a subscription or local configuration, then use rules to control traffic paths. This site brings together multi-platform clients, YAML configuration, and troubleshooting guides, so you can move from installation to ports, DNS, policy groups, and rule order.
Platform entrance
The homepage provides platform links only; the download page lists specific clients, supported architectures, maintenance status, and package types. Check your device’s operating system and processor first, then choose a graphical client or command-line core to avoid mismatched packages and confusing configuration directories.
TRACK 01
For Windows desktop environments. The download page lists Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu, and archived clients in order, with recommended picks and supported architectures. After installation, open the main interface from the system tray, then import a subscription or YAML file.
TRACK 02
For Intel and Apple Silicon Macs. Distinguish x64 from ARM packages when downloading; the first launch may also require security confirmation, network-extension approval, or system proxy permission. Separate architecture links make it easy to choose based on the information shown in About This Mac.
TRACK 03
For phones, tablets, and some Android TV devices. Clients usually take over traffic through the system VPN interface, so confirm the VPN request on first connection. If the device architecture is unclear, start with the universal package; choose ARM64 or ARM when a smaller package is needed.
TRACK 04
iPhone and iPad users can open the Clash Plus page in the App Store. After installation, import a subscription through the client interface and approve the system VPN configuration when connecting for the first time. The download page also lists the app-store link and clashplus.io for product verification.
TRACK 05
Desktop users can choose a graphical client, while servers, soft routers, and container environments usually work better with the mihomo core. Check the distribution, CPU architecture, and package format before downloading; after launch, confirm the configuration directory, log location, and service-management method.
If the client differences are unclear, start with each platform’s recommended option, then choose based on whether you need TUN, a system proxy, tray management, or command-line operation.
View all clients →Rule switchyard
Clash matches requests against configuration rules in order. Once a rule matches, traffic is sent to a direct, proxy, or blocking policy; unmatched requests continue down the list until they reach the fallback rule. Understanding this processing chain is more useful for troubleshooting than memorizing an individual client button.
RULE ENTRY
Rule order directly determines the result. Specific domain and process rules usually come first, regional and general rules later, with MATCH pointing to the fallback policy at the end.
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXYDIRECT
A direct policy bypasses proxy nodes and accesses the target through the device’s current network. It suits LAN addresses, local services, sites sensitive to the apparent source region, and domains confirmed not to need a proxy. Common configurations match private addresses first, followed by local-region IP or domain sets. Direct access does not skip rules: the request still passes through Clash matching, but the final egress is the local network. If a site behaves oddly under proxy mode, downloads become slower, or a LAN device cannot be reached, check whether it belongs under DIRECT. After changing the rule, use connection logs to confirm the rule name and policy result rather than checking only whether the page opens.
PROXY
A proxy policy is usually a policy group rather than a single node name. After a rule matches PROXY, the client uses the group’s type to select a result through manual choice, health checks, failover, or load balancing. This separates “which requests need a proxy” from “which node handles them,” so changing nodes does not require rewriting the entire rule set. If a webpage opens but an application cannot connect, check in order whether the rule matched, the policy group exists, its nodes are available, and the system proxy or TUN covers the application. Rule names, policy names, and target addresses in connection logs are the main evidence for tracing the path; repeatedly switching global mode often hides the original issue.
REJECT
A blocking policy explicitly terminates a class of connections, such as known tracking domains, abnormal requests, or unwanted targets. It returns a failure locally at the rule layer instead of selecting a direct or proxy egress. Keep blocking rules specific and place them before broad rules that could override them; oversized domain sets or incorrect wildcards can affect sign-in, verification codes, push notifications, and app updates. If the page body loads but images, buttons, or sign-in steps are missing, check REJECT matches in the logs temporarily, then adjust the rule for the specific domain. Compared with browser extensions, Clash rules can cover more applications that follow the system proxy or TUN interception, but they also require tighter control of the match scope.
A / Principles
Rules determine what category a request belongs to; policies determine its actual egress. Treating them as one makes node changes unnecessarily force rule edits. Maintain them separately and you only need to adjust policy-group members or the selected result.
B / Scenarios
When troubleshooting, first confirm that the client has taken over the request, then identify the matching rule, and finally inspect the corresponding policy and node. Following the chain helps distinguish port, DNS, rule, and upstream connection issues.
C / Configuration
The end of the rule list should have a clear fallback destination. Missing fallbacks, references to nonexistent policy groups, or broad rules placed too early can all nullify carefully written domain rules above them.
Quick start
The workflow below quickly establishes a functional baseline. Button locations vary slightly between clients, but the order is broadly consistent: confirm the package matches the system, import a valid configuration, then verify the interception scope through logs and real requests.
Windows users generally choose an x64 desktop package; Apple Silicon Macs need the ARM version, while Intel Macs need x64; Android devices can select a package for the relevant processor architecture. After installation, launch the client and confirm that the main interface, configuration directory, and log area open normally. If the system requests network-extension, VPN, or firewall permissions, authorize them according to the client’s features; otherwise the system proxy or TUN may not be able to take over traffic.
Subscriptions suit setups where a service continuously maintains nodes and rules; local YAML is better for authoring and version control. After importing, check for syntax errors, then confirm that policy groups, nodes, ports, and DNS fields are recognized. If an update fails, do not immediately delete the existing configuration. First verify that the URL is complete, the network can reach the subscription source, and the response is actually configuration text; use logs to distinguish a network error from a YAML parsing error.
For desktop browsers, start by verifying with the system proxy; consider TUN for applications that cannot read system proxy settings. After connecting, open the client log or connection list and check whether the target domain reaches the expected DIRECT, PROXY, or REJECT policy. If the browser works but other apps do not, focus on the interception method; if no applications connect, check the listening port, configuration load status, and policy groups first; if only certain domains fail, return to rule order and DNS resolution results.
Open source context
Clash-related names can refer to the original core, later core implementations, graphical clients, or a shared configuration format. Understanding these layers helps identify which component supports a field and whether an issue belongs to the interface or the core.
01 / Project history
Clash established a usage model centered on YAML configuration, policy groups, and ordered rules. After the original project stopped being maintained, clients and configurations across the ecosystem did not follow one unified update path. Many current desktop and mobile clients use the mihomo core, extending capabilities related to DNS, TUN, rule providers, proxy protocols, and network stacks. When consulting a guide, check its target core and client versions: older fields may remain compatible, while newer fields may not be recognized by earlier cores. If the same configuration behaves differently on two devices, first record both client names, core names, and configuration-load logs instead of assuming the configuration itself is invalid.
02 / Open-source ecosystem
Graphical clients mainly manage configurations, subscription updates, system-proxy switching, TUN permissions, logs, and the core lifecycle; the core listens on ports, parses configuration, establishes connections, handles DNS, and matches rules. They may be maintained by different projects, so a client update does not necessarily bring core-field changes, and core support for a feature does not mean every client exposes a corresponding switch. This site groups clients by platform, while configuration guides explain underlying behavior using field names where possible. To confirm advanced capabilities, check the client’s core information and configuration-load result rather than relying only on whether an option appears in the interface.
03 / Core relationships
Basic fields such as listening ports, operating modes, proxy nodes, policy groups, and rules are generally recognizable across implementations; DNS policies, TUN network stacks, rule-set formats, and protocol-specific fields are more affected by core versions. Server environments are also influenced by file permissions, service users, working directories, and system routes, while desktop environments commonly encounter disabled system proxies, unconfirmed TUN permissions, or ports occupied by other network tools. Before migrating a configuration, start with a minimal working file, confirm that ports and basic rules work, then add DNS, rule providers, and overrides section by section. This is easier to troubleshoot than loading a complex configuration all at once.
04 / Update mechanics
The client, core, subscription content, and user overrides may update independently. If a problem appears after a client upgrade, first determine whether the core changed as well; if policy groups disappear after a subscription update, inspect the remote configuration and local override order; if access paths change after a rule-set update, check the rule that actually matched. Keep a known-good baseline configuration, modify complex fields by module, and reload the configuration, inspect error line numbers, and run a target request after every change. A stable rollback point limits the issue to the most recent change instead of forcing you to guess after several updates occur together.
SOURCE REFERENCE
The commands below clone a public source repository for users who need to inspect the implementation, build the core, or verify configuration-field behavior. Most desktop users can choose a graphical client directly from the download page.
git clone https://github.com/MetaCubeX/mihomo.git
Configuration notes
The article section focuses on practical configuration tasks, with an emphasis on multi-device synchronization, Linux Deployment, and the relationship between different core names. For Fake-IP, regional routing, and rule-order work, continue to the blog for complete examples.
Compare subscriptions, override files, and private repositories as three synchronization paths, covering credential isolation, conflict handling, and update order. The article distinguishes rules suitable for sharing from local ports, paths, and authentication details that should remain on one device.
Read the full article →From desktop environments to headless servers, this guide covers configuration directories, startup commands, systemd services, and terminal proxy variables, plus how to use logs, listening ports, and service status to diagnose startup failures or incorrect configuration paths.
Read the full article →Explains how the original Clash, Clash Meta, and mihomo names evolved by comparing maintenance status, configuration fields, rule capabilities, and client support, with the field ranges to check first when migrating a configuration.
Read the full article →