Platform access

Choose a Clash client by device

Each system uses different installation formats and traffic-routing interfaces. This section provides platform links and selection guidance; client lists, maintenance status, system requirements, and packages are collected on the download page. Existing profiles can usually be reused across devices, but system proxy settings, TUN permissions, and startup behavior must be configured separately.

Windows

Desktop clients provide tray controls, system proxy management, profile switching, and log viewing.

Go to downloads

macOS

Choose the build for your Intel or Apple Silicon Mac. Clients manage menu bar status, proxies, and profiles.

Go to downloads

Android

Import a profile, choose policies, then route app traffic through the system VPN or TUN mode.

Go to downloads

iOS

Get Clash Plus from the App Store, then configure subscriptions, policy groups, and routing rules.

Go to downloads

Linux

Choose a graphical client for desktops or run mihomo directly on servers and routers.

Go to downloads

View all clients →

Configuration capabilities

From subscription import to traffic routing

Clash configuration involves more than choosing a proxy node. The complete path includes the configuration source, policy-group decisions, rule matching, DNS resolution, and the system traffic entry point. Use these four tabs to review each module, then follow the practical configuration order.

Policy selection layer

Organize proxy selection with policy groups

select is suited to manual selection, url-test automatically tests candidate proxies, fallback switches through available items in order, and load-balance distributes connections among candidates. Rules reference the policy-group name rather than a specific node, so changing a subscription or selection does not require rewriting the entire rule set.

Request matching layer

Let domains, addresses, and the final rule determine routing

Rules are matched from top to bottom in their configured order. Common rules include DOMAIN-SUFFIX, DOMAIN, IP-CIDR, GEOIP, and the final fallback MATCH. Put exact rules before broad rules so requests do not enter an unsuitable policy group too early.

Policy groups

Separate node selection from rule references

Policy groups form the decision layer in a configuration file. Rules only need to pass traffic to a stable group name; the group then determines which proxy to use, whether to test candidates automatically, or whether to fall back when a preferred option fails. This separates “which requests go here” from “which option is selected now.”

For daily use, confirm the policy groups on the proxy page, then choose a proxy or child policy inside the relevant group. Use select for a fixed choice, url-test for automatic candidate selection, and fallback when availability order matters. Avoid deeply nested groups, and keep names stable and descriptive.

proxy-groups config.yaml

selectManually choose a proxy or child policy
url-testChoose candidates by test results
fallbackFall back in configured order
load-balanceDistribute connections among candidates

Rule configuration

Route requests in the right order

The rule engine starts at the first line and stops after a match. Domain-suffix rules cover multiple subdomains of a site, exact domain rules handle an individual host, and IP and GEOIP rules process connections whose addresses are already known. Finally, MATCH receives traffic that matched nothing earlier.

When maintaining custom rules, write narrower, higher-priority entries first, followed by regional and fallback entries. The right side of each rule must reference an existing policy-group name. If a subscription imports successfully but a specific site routes incorrectly, check rule order and group names before repeatedly switching nodes.

rules Match from top to bottom

DOMAIN,example.org,Manual selection
DOMAIN-SUFFIX,example.net,Automatic selection
GEOIP,CN,DIRECT
MATCH,Manual selection

Put exact matches before broad matches and keep one final fallback rule.

TUN and DNS

Handle traffic beyond system proxy coverage

Some Android apps do not read traditional system proxy settings, and UDP requests may need a more complete traffic entry point. TUN uses the system VPN interface to create a virtual network adapter, sending app connections to the client before mihomo processes them according to the rules. Android's VPN permission prompt is the standard system flow for granting network-routing access.

Check DNS and TUN together. Fake-IP preserves domain information through mapped addresses; DNS hijacking sends resolution requests on specified ports to the core; auto route adds required routes; and strict route reduces traffic bypasses. If only some apps fail after connection, check the logs to confirm that requests entered TUN and look for other VPN services running on the device.

Traffic routing Android VPN API

TUN mode

Auto route

Strict route

DNS hijacking

Fake-IP

Subscription updates

Give remote profiles and local overrides separate roles

Subscriptions distribute remote configuration, while local overrides handle device-specific adjustments. After importing a subscription, check remote content at a fixed interval and keep device-related DNS, TUN, port, or rule changes in the override layer. Updates can then proceed without directly editing the remote profile's generated content.

Automatic updates do not remove the need for review. After a major subscription change, confirm that the active profile is still selected, common policy groups still exist, and fields referenced by local overrides remain valid. When an update fails, check the subscription URL, network access, configuration syntax, and storage permissions in that order.

Profile management Subscription settings

Automatic profile update Enabled

Update interval 1440 minutes

Override order Subscription → Local override

Update methods Automatic and manual

Quick start

Three steps after installation

You do not need to change every advanced parameter on the first run. Import a profile, check the policies, and start the service in that order. Once the connection works, decide whether TUN, DNS hijacking, or custom rules are needed for broader app coverage.

01

Import a subscription or local profile

Open the client’s “Profiles” entry and import a subscription from a URL, or read a YAML file stored on the device. After importing, select the entry in the profile list so it becomes active. If parsing fails, check the fields and line numbers in the error message instead of repeatedly starting the service before confirming the syntax.
02

Check policy groups and operating mode

Open the “Proxy” page, review the policy groups supplied by the profile, and choose a proxy or child policy for groups that require manual selection. Rule mode suits most daily configurations; global mode sends capturable traffic to one policy; direct mode is mainly useful for temporarily excluding the configuration.
03

Start the service and read the logs

Return to the home screen and tap “Start.” Confirm Android VPN permission on the first run, then test an app that needs network access. If only some requests fail, the log page shows the destination, matched rule, and policy group. Use that information to determine whether the issue is DNS, rules, policy selection, or the remote connection.

View the complete guide →

Open source ecosystem

Clash configuration and the mihomo core

The Clash ecosystem uses a widely adopted YAML configuration structure covering proxies, policy groups, rules, DNS, traffic sniffing, and external control. Interfaces vary between graphical clients, but the core workflow is similar: the client manages profiles and system integration, while the core parses configuration, receives connections, and applies routing.

mihomo continues and extends the core capabilities of Clash Meta. Clients on Android, Windows, macOS, and Linux can build graphical interfaces around this core. Learning the relationship between policy groups, rule order, DNS, and TUN is therefore more useful long term than memorizing one interface’s button layout.

Project code, issue records, and change discussions are publicly available on code-hosting platforms. When configuration fields change, check the current core documentation and client notes first. For interface issues, consult the maintenance information for the relevant client. The core and graphical client are separate projects with different release cycles, supported fields, and system integrations.

This site organizes content into download links, quick guides, concept references, advanced configuration, and troubleshooting. The download page identifies platforms and clients; the quick-start guide covers the first connection; the glossary explains terminology; and the advanced guide discusses policy groups, rule sets, DNS, TUN, Fake-IP, sniffing, and local overrides.

Selected common questions

Understand these concepts before setup

Most first-time configuration issues are not caused by the package itself. They usually come from an incomplete chain involving the active profile, policy selection, system routing, or DNS. These four questions cover the most common starting points.

What is the relationship between Clash and mihomo?

Clash generally refers to a configuration system and client ecosystem, while mihomo is one actively maintained core project. Graphical clients call the core to handle connections and provide subscription management, policy selection, logs, and system-permission controls.

View core concepts →

Why is there no connection after importing a subscription?

Importing only saves the profile. You must also make it active, check that policy groups have usable choices, and return to the home screen to start the service. Android also requires system VPN permission on the first run.

View import steps →

How should system proxy and TUN mode be chosen?

System proxy mainly covers apps that actively read proxy settings; TUN receives broader traffic through a virtual network adapter. Android clients generally use the system VPN interface, so stop other services using that interface before enabling it.

View traffic-routing terms →

Why do rules stop working after a profile update?

A remote profile may change policy-group names, rule-set references, or DNS fields. If a local override still uses an old name, the update can succeed while behavior changes. Compare the logs and new profile to check each reference.

View advanced configuration →

Configuration articles

Recent Clash for Android guides

These articles cover troubleshooting, client migration, and interface operations separately. Start with the troubleshooting sequence when a connection fails; read client and core guides when you need to understand the architecture, rather than changing several parameters without log evidence.

Troubleshooting August 27, 2026