Start by checking operating-system and core compatibility, then import your subscription and verify the rules. This site brings together multi-platform download links, Chinese configuration documentation, and protocol selection guidance for first-time installs, migrations from older clients, and maintaining existing configurations.
Confirm your operating system and processor architecture first, then choose a graphical client or the Mihomo core. Graphical clients are usually the best choice for everyday desktop use; deploy the core directly for servers, routers, and automated environments.
Clash is not mainly about toggling switches repeatedly. The goal is a verifiable chain connecting subscriptions, the core, proxy groups, and the system proxy. The four key modules below are mapped by PCB reference designators, with the practical takeaway first and configuration boundaries afterward.
In rule mode, the client checks connection targets from the top of the configuration file's rule list. Once it finds the first matching rule, it applies that rule's strategy and stops checking. Custom rules should therefore come before broad rules; the fallback MATCH is usually last. Writing rules into the file is not enough: confirm that the target proxy group exists, the configuration has been reloaded, and the current mode is actually rule mode.
Domain rules work well for sites that can be identified reliably. IP rules depend on resolution results and database state, while process rules are affected by system permissions and client implementation. When a connection matches incorrectly, first inspect the target domain, matched rule, and final strategy in the connection log before changing rule order or adding rules. Avoid using global mode to hide configuration problems.
A node is not a direct substitute for a rule. A rule first sends the connection to a proxy group, which then selects a specific node, another group, or a direct connection. Manual-selection groups suit fixed exits; automatic-test groups choose available members using the detection methods supported by the client and configuration; fallback groups try members in list order. Subscription providers may use different group names and structures, so migrating a configuration means more than copying the node list.
When a webpage opens but a specific app cannot connect, first confirm which proxy group handled the connection and whether its current selection still exists. Node-name changes after subscription updates, empty group membership, or references to deleted groups can make a rule appear to match while leaving no usable exit.
The graphical client manages configurations, the system proxy, updates, and visual controls; the core actually parses the configuration and handles connections. The original Clash, Clash Meta, and later mihomo family differ in protocol support, rule capabilities, and configuration fields. A valid YAML file does not mean every field will be recognized by the current core, and different branches of clients with the same name may use different cores.
When choosing a client, identify the core family it currently uses, then check whether the subscription includes the required protocols and extension fields. If loading fails, do not repeatedly reinstall the interface first. Read the parser error and fix the specific field, indentation issue, or incompatible option.
Subscriptions typically fetch nodes, proxy groups, and rules remotely. Before importing, confirm that the link format is supported by the client. Afterward, check the configuration name, update time, and load status before enabling it. An update can fail because the link expired, the request failed, the response was not YAML, or the current core cannot recognize its fields; a download-complete message alone does not prove that the configuration is active.
When adding local rules, prefer the client's override, mixin, or extension mechanisms instead of editing a remote configuration copy that the next subscription update will overwrite. Keep a rollback version before making changes, then validate parsing before testing rule matches and DNS results.
The same subscription may not load completely in every client. Start with a maintained client whose core supports your configuration, then verify the processor architecture and package type. The links below take you to the relevant platform download page; they do not start a file download directly.
Suitable for everyday desktop use. Before installing, confirm the x64 architecture, system version, and administrator permissions. When migrating from an older Clash for Windows setup, back up the configuration and override rules before testing the system proxy.
Go to DownloadsApple Silicon and Intel Macs require different builds. First launch may also require system security approval, a network extension, or proxy permissions, so complete the client's basic authorization before importing a configuration.
Go to DownloadsMobile clients require permission to establish a VPN connection and the correct package for the device's processor. Background restrictions, battery-saving policies, and Private DNS can all affect persistent connections; check system settings as well when connections drop.
Go to DownloadsGet Clash Plus from the App Store and allow it to add a VPN configuration when prompted. After switching between mobile and Wi-Fi networks, check the VPN status first, then review the subscription and proxy-group selection.
Go to DownloadsUse a graphical client on desktop systems; servers and routers are better suited to running the Mihomo core directly. Deployment requires clear decisions about the configuration path, service permissions, listening address, and firewall boundaries.
Go to DownloadsIf the client differences are unclear, start with the client comparison page. When you need to deploy the core directly, the download page also includes a dedicated Mihomo core section.
During first use, avoid changing DNS, rules, ports, and the system proxy all at once. Follow the shortest path in order, confirming each result before moving on. This makes it easier to tell whether a problem is in the configuration, client, or operating system.
Open the client's configuration or subscription page, paste the subscription URL provided by your service provider, and import it. Afterward, check the configuration name, update time, and load status. If the client reports a parsing error, record the specific field and line number instead of importing repeatedly. Once nodes and proxy groups appear, set the configuration as active.
A local YAML file can also be imported, but indentation must use consistent spaces, and every proxy-group name referenced by a rule must actually exist. If a configuration exported by an older client contains core-specific extension fields, check core compatibility when moving it to a newer client.
For initial testing, start with rule mode and select a confirmed working node in the main proxy group. Rule mode routes traffic by destination, with direct and proxied behavior determined by the rule table. Global mode sends most connections through one strategy and is useful for short comparison tests, but not as a long-term way to hide rule errors.
After making your selection, enable the system proxy or allow the mobile system to establish a VPN connection. LAN sharing, TUN mode, and custom DNS are later-stage settings; keeping the defaults until the basic path is verified makes troubleshooting easier.
Use a browser to visit a regular site and confirm that the local network itself works, then inspect the client's connection log. A useful log entry should show the destination, matched rule, proxy group, and final exit. If only some apps fail, check whether they follow the system proxy, require loopback permission, and receive DNS results consistent with the rules.
If every connection fails, check configuration loading, node availability, the system proxy, port conflicts, and the firewall in that order. Change only one variable at a time and retest to avoid interactions between multiple changes.
To determine whether a client suits your configuration, understand the separate roles of the graphical interface, proxy core, subscription format, and rule database. Open-source code provides an auditable implementation foundation, but real-world use still requires checking the client's maintenance status and its relationship with the core version.
The Clash ecosystem widely uses YAML configuration, proxy groups, rule lists, and external rule sets. The original project's approach influenced many desktop and mobile clients. As the original project and some early graphical clients stopped receiving maintenance, client selection has shifted toward actively updated branches and the core families they integrate.
Older configurations can often serve as a migration base, but should not be assumed fully compatible. Before migrating, back up the subscription URL, local overrides, rule snippets, and client-specific settings. Afterward, recheck configuration parsing, the system proxy, DNS, and proxy-group options.
A working Clash client often combines several components: the graphical interface handles interaction and system integration, cores such as mihomo handle connections and configuration, and projects providing GeoIP, GeoSite, or rule sets supply classification data. Their release schedules do not always align, so a client update may not include the newest rule database, and a subscription update does not automatically upgrade the local core.
When functionality differs, first identify which layer owns the issue. A missing interface entry is a client implementation difference; an unparseable configuration field usually indicates core compatibility; inaccurate classification for a type of domain may require checking rule data and its update time.
mihomo continues the Clash Meta direction, expanding protocol support, rule providers, DNS, and traffic-processing capabilities. These features may introduce fields that the original Clash does not recognize. When choosing a client, do not rely only on whether its name contains Clash; confirm the integrated core, update method, and supported configuration scope.
Server users can deploy the core directly, but must manage process supervision, permissions, logs, configuration updates, and port security themselves. Desktop users usually find a graphical client with an integrated core easier to maintain. The core concepts are similar, but the operational responsibilities differ.
Client upgrades mainly change interface features, system compatibility, and bundled components. Core upgrades may add protocols or configuration fields. Subscription updates usually refresh nodes, proxy groups, and provider rules. GeoIP, GeoSite, and remote rule sets classify addresses. When troubleshooting an issue after an update, record which layer changed instead of replacing every component at once.
A safer update order is to keep the current working configuration, update one component, and run load and connection tests. Roll back immediately if parsing fails; inspect match logs when rule behavior changes, and check permissions and port status when the system proxy behaves unexpectedly.
These blog posts focus on practical configuration tasks, recording why changes are made, where they apply, and how to verify them. When working with database updates, first-time imports, or Windows application proxy issues, start with the relevant article.
Covers the purpose, update methods, and configuration references of two rule databases, along with the checks to perform when an update fails or rules do not take effect. For users already running rule mode who need to maintain regional and site classification data.
Read Article →Answers ten common questions new users encounter, covering client selection, subscription updates, proxy modes, and basic troubleshooting. After installation, work through the questions in order once.
Read Article →Explains how UWP loopback restrictions affect proxy connections and provides a complete checklist covering system settings, app selection, and recovery testing. Useful when browsers work but some Store apps cannot access the network.
Read Article →More articles cover migration from older clients, mixed ports, and LAN proxy sharing. Before reading, identify the relevant platform and configuration layer to reduce unnecessary changes.
View All Articles →