Organized by platform, Clash client installation links and archived releases are paired with guidance on configuration fields, traffic routing, system proxies, TUN, and DNS troubleshooting—so you can confirm platform differences before installation and diagnose configuration issues after connecting.
Free foreverOpen sourceChinese documentation
Early archive
Archived installers
Compatibility archive
Recent archive
Latest
macOS · Current installer
platform: macOS
architecture: arm64 / x64
document: quickstart
Choose a platform and CPU architecture
Platform · Installation
Choose a Clash client by operating system
The same Clash configuration can be read by different graphical clients or core programs, but installer formats, system-proxy handling, and permission models vary. Confirm the operating system and CPU architecture first, then compare clients on the download page to avoid installing the wrong package, launching failures after import, or a system proxy that does not take effect.
DESKTOP / WINDOWS
Windows
Designed for everyday desktop use. The download page lists popular graphical clients and distinguishes actively maintained projects from historical archives. After installation, you will usually need to import a configuration, choose a proxy group, and enable the system proxy; configure TUN only when broader application coverage is needed and permissions allow it.
Before downloading, determine whether the device uses Apple Silicon or an Intel processor. Packages for different architectures are not interchangeable; first launch may also require security confirmation, network-extension approval, and proxy permissions. The download page brings together links for Clash Plus, Clash Verge Rev, FlClash, and ClashX Meta.
Android clients typically take over traffic through the local VPN interface, and the status bar displays a VPN indicator when enabled. The page provides packages for different CPU architectures as well as universal installers. Verify that a subscription source is trustworthy before importing it, and check Android settings for background operation, battery optimization, and always-on VPN.
iPhone and iPad use the system network-extension capability to handle connections. The download section links directly to the Clash Plus App Store page and official website information. After installation, follow the usage documentation to import a subscription, allow the VPN configuration, and choose the node or automatic test group you want to use.
Desktop environments can use graphical clients, while servers, software routers, and containers are generally better suited to running the Mihomo core directly. Before downloading, confirm the distribution, CPU architecture, and package format. Service deployments should also plan the configuration directory, log path, listening address, and startup permissions separately.
Clash’s processing path can be divided into listening ports, rule matching, proxy-group selection, DNS resolution, and the final connection. The scale on the left represents commonly used configuration areas; switch between them to see what each field does, how it is used, and what to check when troubleshooting.
rules.yaml
Choose the egress by domain, address, or process
In rule mode, requests are matched one by one in the order defined by the configuration file. Common conditions include domain suffixes, domain keywords, IP ranges, GeoIP, rule providers, and process names; once matched, a request is handed to the specified proxy group. Put more specific rules first and leave the catch-all rule at the end, confirming that every referenced proxy-group name actually exists. Unlike simple proxy tools with only a global toggle, Clash can handle work sites, direct-access services, LAN addresses, and other traffic separately. When routing behaves unexpectedly, follow the rule order to identify the first match.
Proxy groups sit between rules and the actual proxy nodes. Manual selection suits a fixed egress; URL-test groups periodically check candidates at a configured address, while fallback groups try subsequent members in order when the current choice is unavailable. Define the group type, member sources, and nesting relationships clearly to avoid circular references. Switching a node in the client usually changes only the group’s current selection—it does not rewrite the rules. This explains why a node can pass a test while a webpage still uses a direct connection, and lets multiple business rules point to one maintainable egress group.
proxy-groups:
- name: Proxy
type: select
proxies:
- Auto
- DIRECT
dns.yaml
Unify the resolution path while preserving domain mappings
Clash’s DNS module can receive client queries centrally and select upstream resolvers according to the configuration. Fake-IP mode returns reserved addresses and maintains domain mappings, allowing connections that carry only a destination address to recover the original domain and continue matching domain rules. This is more than simply changing the system DNS: the listening port, upstream resolver, filter lists, and traffic-capture method must work together. If some domains fail, LAN device discovery breaks, or browser results differ from command-line results, check in order whether DNS is enabled, whether requests enter Clash, whether the upstream is reachable, and whether the domain belongs in the filter range.
Separate application proxy settings from system-wide traffic capture
The system proxy mainly affects applications that follow the operating system’s proxy settings; browsers and most desktop programs generally work directly with it. Apps that ignore system proxies, some games, and independent network stacks may bypass it. TUN mode broadens coverage through a virtual network interface, but also involves administrator permissions, routing tables, DNS interception, and interactions with other VPN software. When getting started, validate the node and configuration with the system proxy first, then enable TUN as needed. If the entire network stops working, disable traffic capture to restore connectivity, then check port conflicts, virtual-interface permissions, route conflicts, and DNS settings instead of repeatedly swapping configuration files.
mixed-port: 7890
tun:
enable: true
stack: system
profile-management.md
Separate upstream subscriptions, local overrides, and recoverable backups
A Profile is more than a node list: it may also contain ports, DNS, proxy groups, rule providers, scripts, and other configuration. When a remote subscription updates, the client usually fetches the upstream content again, so direct edits to the generated file may be overwritten next time. A safer approach is to keep the original subscription and place local port settings, DNS exceptions, and rule changes in the client’s supported override or merge layer, while keeping an independent backup of every known-good configuration. Name multiple configurations by purpose and record their import source and modification scope; when troubleshooting, switch back to a known-good configuration first, then compare field differences.
profile:
store-selected: true
store-fake-ip: true
Open Source · Project Relationships
The boundaries of origin for installers, cores, and configuration
The Clash ecosystem combines cores, graphical clients, rule data, and user configurations. To decide whether a download link suits the current device, do not rely on similar names alone; verify the project’s maintenance status, core relationship, platform architecture, and configuration compatibility range.
HISTORY
From the original Clash to continuously evolving core forks
Clash first gained broad adoption as a rule-driven proxy core. Its YAML configuration organizes proxy nodes, proxy groups, rules, and DNS in one structure. After the original project stopped receiving updates, the community continued maintaining related forks around compatibility, new protocols, rule capabilities, and platform support. Many current desktop and mobile clients use Mihomo as their runtime core, but each client project still determines its interface naming, configuration-override method, and system integration. Therefore, “supports Clash configuration” does not mean every client has identical menu locations, field extensions, or migration behavior.
ECOSYSTEM
Graphical clients handle system integration; cores handle connection logic
The core reads configuration, establishes connections, applies rules, and exposes control interfaces. The graphical client builds on it to handle installation, subscription updates, proxy-group switching, logs, system proxies, TUN permissions, and startup behavior. Permission models differ across Windows, macOS, Android, and iOS, so the implementation of a feature can vary even when its name is the same. Choose a client by checking platform support first, then maintenance status, core type, and required features. For server forwarding or router deployment, running the Mihomo core directly is often more suitable; for menu-bar controls, system notifications, and configuration management, a graphical client is easier to maintain.
ARCHIVE
Historical archives support legacy environments; they do not replace platform checks
Older systems, older processors, or fixed deployment environments may require archived installers, but archive files should not be installed casually just because they are sorted by release date. First confirm the operating system requirements and CPU architecture, then check whether the client is still maintained, and finally verify configuration-field compatibility. Discontinued clients are marked separately on the download page so their archived status is clear. For new devices, prefer clients that are maintained and have clear platform support. For stable existing environments, back up the configuration and record the current system-proxy, TUN, and DNS states before upgrading so you can roll back if behavior changes.
UPDATE
Check upstream changes and page availability when reviewing updates
This site organizes download links by client project and platform, while version information and file details are presented on the installer pages; the homepage focuses on explaining project relationships and selection paths. Curation checks upstream project status, link availability, platform-key matching, and whether documentation still reflects current client behavior. Configuration guides avoid treating a temporary interface layout as a universal rule, instead focusing on stable concepts such as system proxies, rules, proxy groups, and DNS; platform-specific interface differences are covered separately where needed.
Checklist · Common Questions
The right order of checks before and after installation
Should macOS users download the Apple Silicon or Intel installer?
Check the chip information in “About This Mac.” If an Apple chip name is shown, choose the Apple Silicon or ARM package; if an Intel processor is shown, choose the x64 or Intel package. Choosing the wrong architecture can prevent the app from opening or require an additional compatibility layer. See the complete platform details in the macOS download section.
Why can’t I open websites after importing a subscription?
First confirm that the configuration is active. Then check whether the proxy group has selected a working node, the system proxy is enabled, and the proxy port is not occupied by another program. Test both direct-access and proxied websites to distinguish node, rule, and DNS problems. Do not enable multiple traffic-capture tools at once, as their routing and proxy settings can override one another. Continue in the order described in Troubleshooting.
Should the system proxy and TUN mode be enabled together?
The exact behavior depends on the client implementation. When configuring for the first time, start with the system proxy to confirm that the configuration, node, and rules work, then enable TUN if apps that ignore the system proxy need to be covered. If network problems appear after enabling TUN, check virtual-interface permissions, DNS interception, route conflicts, and other VPN programs. See the related steps in the usage guide.
Will a subscription update overwrite manually modified rules?
If you edit a configuration generated from a remote subscription directly, an update will usually replace it with new content. Prefer the client’s override, merge, or scripting features to manage local rules separately from the upstream subscription. Keep a known-good copy before editing and record the configuration layer containing each new field. See Configuration Field Reference for field structure and merge strategies.
Notes · Latest Articles
Configuration and troubleshooting notes
Articles break problems down along the real operating workflow: first the conditions to assess, then the verification method and corrective action. Where configuration is involved, they distinguish system proxies, core fields, client interfaces, and upstream subscriptions so issues from different layers are not conflated.
From the system-proxy toggle and port conflicts to node availability, DNS pollution, and rule matches, identify the real cause of being “connected but offline” in order. Each step provides observable symptoms, a verification method, and the corresponding fix—useful when repeatedly switching nodes produces no result.
Latency tests usually reflect a single request path to a specific test URL, not page loading, video transfer, or long-lived connection quality. This article explains how URL Test statistics are measured and how to assess node quality alongside packet loss, bandwidth, exit location, and peak-hour stability.
Explains how Profiles relate to subscription links, local YAML files, and client overrides; covers the basics of updating, switching, and backing up configurations; and provides naming conventions, editing boundaries, and recovery steps for managing multiple subscriptions.