macOS Client · Subscriptions & Routing Rules

Clash for MacDownload & Setup

Start by importing a subscription, then configure the system proxy and routing rules. Enable TUN mode if your apps require it.

  • Setup Guides
  • Open-Source Core Ecosystem
  • Apple Silicon / Intel

Choose the right architectureImport your configurationVerify traffic routing

Choose a Clash Client for Your Platform

Check your operating system first, then choose the right processor architecture. The download page lists clients, supported architectures, and installation links. Menus vary by client, but profiles, proxy groups, and traffic entry points follow the same basic principles.

Windows

Check your operating system and processor architecture before choosing an installer. System proxy works for apps such as browsers. Microsoft Store apps may also require checking UWP loopback restrictions.

Download Windows client

macOS

In About This Mac, check whether your Mac has Apple silicon or an Intel processor. After installation, import a profile and enable the system proxy. For TUN mode, follow the client's instructions to set up its service and permissions.

Download macOS client

Android

Choose an installer that matches your device's architecture. On first connection, you'll usually need to approve the VPN permission. If you already use another VPN app, check for conflicts before configuring per-app proxying or background permissions.

Download Android client

iOS

Use the download page to open Clash Plus in the App Store. After installation, import a compatible profile and approve the system VPN permission. Learn more about the client at clashplus.io.

Download iOS client

Linux

Desktop users should choose a package for their distribution; server users may prefer a standalone core. Desktop proxy settings, service permissions, and route management are separate, so check each one after installation.

Download Linux client

A client installer does not include a subscription service. Use a configuration source you are authorized to access, and make sure it includes usable proxy nodes, proxy groups, and rules. When moving to another device, use the original subscription or a configuration backup rather than recreating settings from screenshots.

View all clients →

Traffic Modes, Entry Points & Rules

The system proxy determines how apps send requests to the client; traffic mode determines how the client handles requests it receives. Understanding these as separate layers helps you identify the right setting to change, instead of turning on every option at once.

Traffic Mode

RuleGlobalDirect

Start with Rule mode for everyday use.

Rule mode selects an outbound based on the configured matching order, making it suitable for accessing local services and remote resources at the same time. Global mode generally sends requests that reach the core through the global proxy group, which can be useful for temporary comparisons. Direct mode lets you check what happens without a proxy. Switching modes does not create nodes or capture traffic from apps that never reached the client. First, make sure a usable option exists in the proxy group. Then send a new request and check its actual outbound on the Connections page. Existing long-lived connections may keep using their original route.

Install and Connect: Three Steps

Start with the fewest settings needed to make a connection you can reproduce, then add rules and expand traffic coverage. If something goes wrong, you can return to the last setting you verified instead of guessing from scratch.

  1. 01 / Profile Source

    Import a Subscription and Select the Profile

    Install a client that matches your device's architecture. On the Profiles page, choose URL import or import a local file. Once parsing completes, select the profile, open the Proxies page, and check that the expected proxy groups appear. If the import fails, check that the URL is reachable, the response contains a configuration file, and the current core supports its fields.

    A subscription URL may contain access credentials. When copying it, avoid extra spaces and never post the full URL in a public forum. If you already have a client profile, save a copy first. Change the subscription source separately from the traffic entry point so you can tell which change caused any issue.

  2. 02 / Traffic Entry Point

    Choose a Proxy Group and Rule Mode

    On the Proxies page, choose the outbound you plan to use and keep Rule mode selected. Then enable a traffic entry point supported by your system. On desktop, start with the system proxy; to cover other apps, configure TUN mode by following the guide. On mobile, approve the VPN permission when prompted and check whether another connection is already using the required capability.

    Node latency reflects a specific test request, not download speed or how every website will perform. First choose an outbound that connects successfully and test the services you actually need. Consider automatic selection afterward. A low latency number does not prove that your rules are working correctly.

  3. 03 / Verify the Result

    Check Connections, Rules, and Recovery

    Reload the target page or app, find its request on the Connections page, and check the destination, matched rule, and actual outbound. Also confirm that local services remain reachable. Seeing the client running does not prove that an app is using the proxy. To verify the setup, make sure the entry point, rule, and outbound all line up.

    If a connection fails, keep the error record and check the profile, entry point, DNS, and node one at a time. After turning off the proxy, confirm that the system network recovers. If you need remote work access or connections to local network devices, also check how your rules handle internal domain names and addresses to avoid route conflicts during everyday use.

How Open-Source Cores and Clients Fit Together

Clash is a proxy ecosystem built around profiles, rules, and outbounds; different clients are separate projects, not interchangeable versions of the same app. To determine whether a feature is available, check the client interface, the core it uses, and the active profile. Similar names alone aren't enough to draw conclusions.

Project History: The Original and Its Successors

The original Clash's rule-based configuration influenced many desktop and mobile clients. After the original project stopped being maintained, the community continued developing independent cores and interface projects. Over time, they diverged in protocol support, DNS behavior, configuration fields, and system integration. Older guides can help explain the basics, but their download links, permission steps, and screenshots may not apply to the client you're using today.

When choosing a client, check its maintenance status and OS support first, then confirm that it supports the protocols you need. Archived clients can be useful for compatibility research in existing setups, but familiar tutorial screenshots are not a good reason to choose one for a new installation. If an older profile won't load, keep the original file, read the error, and migrate fields using the current core's documentation rather than deleting everything it doesn't recognize.

What Each Component Does: The Interface Is Not the Core

A graphical client handles profile management, menu bar or system tray access, system proxy toggles, and permission integration. The core parses profiles, matches rules, and establishes outbound connections. mihomo is the name used by the project that followed Clash Meta; its source code and configuration documentation are publicly available. A client using this core may not expose all of its features in the graphical settings, and the relevant features may not be enabled in the default profile.

For example, process matching depends on the operating system and permissions; rule sets need valid resource URLs and policy references; and DNS behavior depends on the profile and traffic capture method. When you see a feature name, first determine whether it belongs to the client settings or a core configuration field, then consult the relevant documentation. This avoids mistaking a missing interface button for lack of core support, and prevents copying override formats intended for another client.

Configuration Sources: Subscriptions and Connectivity

Installing a client only prepares the local app. Node credentials, proxy groups, and rules come from the selected profile, while actual connectivity also depends on service status, your local network, the destination, and routing. This site provides client downloads and setup guidance; it does not manage subscription accounts or promise connection quality based on a single latency number in the interface. Before using a profile, understand its source, authorization scope, and expiration date.

When converting a Clash subscription, the original URL may be exposed to the conversion service. If your client can read the configuration directly, try importing it as is first. If conversion is necessary, check whether you trust the service and understand its supported fields and rule handling. When asking for help, share only the minimum redacted excerpts needed. Never post node passwords, subscription URLs, or complete logs containing personal browsing details.

Updates: Manage Three Types Separately

Client, core, and subscription updates are three different things. A client update mainly changes the interface and system integration; a core update may change protocol support and configuration parsing; a subscription update replaces nodes, proxy groups, or rules. When troubleshooting, note which layer changed most recently, keep a recoverable copy of your profile, and read the relevant project's release notes. Updating everything at once makes it harder to identify the cause.

Before moving to another device, check its OS architecture and permission requirements, then import a compatible profile. Save custom rules using an override method supported by the client to prevent remote subscription updates from replacing them. After the move, check the same connection path and local network access. Being able to preserve old settings does not guarantee they will behave the same in a new environment.

Browse the mihomo Core Source Code

The source repository is useful for exploring core implementation, configuration documentation, and public issue reports. The command below only downloads the source code; it does not install a graphical client or configure the system proxy. Most users can use the client download links above.

Visit the MetaCubeX / mihomo repository ↗
git clone https://github.com/MetaCubeX/mihomo.git

Linux penguin icon: Font Awesome, licensed under CC BY 4.0.

Notes on the Core, Networking & Configuration

After your first connection works, learn how traffic reaches the client, what latency tests actually measure, and how core configuration differs. Look up only what you need for the issue at hand; you don't need to change every advanced setting during your first install.

How Node Latency Is Measured: URL Tests vs. Real-World Speed

Break down what a url-test request measures and how handshakes, test URLs, concurrency, and network congestion can make the displayed figure differ from real-world performance. Includes practical tips for comparing nodes.

Download Clients