From Clash configuration format to the mihomo ecosystem
The Clash ecosystem has long centered on YAML configuration, proxy groups, and rule-based routing. As the original projects changed status, community development gradually shifted toward successor kernels and clients that remain compatible with Clash configurations. mihomo preserves familiar configuration concepts while expanding protocol, rule-set, DNS, and TUN capabilities. Many desktop and mobile clients today are essentially graphical interfaces that package these kernel features for easier use.
“Clash client” therefore does not refer to just one app. Projects may use different interface technologies, update channels, and permission models, while subscriptions, proxy groups, Rule mode, and YAML configuration still share many concepts. This site organizes these projects by platform and clearly archives clients that are no longer maintained, keeping familiar legacy names separate from current maintenance status.
What open-source code makes verifiable
Open-source project code, commit history, issue discussions, and release notes can be reviewed collectively by the community. For everyday users, there is no need to read every line of code: maintenance frequency, issue responses, build instructions, and community discussion can help reveal a project’s health. Developers can trace rule behavior, protocol implementations, and platform compatibility issues, then submit fixes or reproduction materials when needed.
Open source does not mean every third-party build comes from the same maintainer. Before downloading, confirm the project name, target platform, and architecture, then read the installation instructions. Windows, macOS, and Linux often offer files for multiple architectures, while Android may distinguish universal packages from processor-specific builds. The download pages explain these differences separately, reducing guesswork based on filenames alone.
What the kernel and graphical client each do
The kernel reads the configuration and handles network connections, determining DNS resolution, rule matches, proxy-group selection, and the final outbound route. The graphical client manages subscriptions, the system-proxy switch, kernel startup, connection logs, and platform permissions. When something goes wrong, first identify the layer involved: settings that cannot be saved usually point to the client; unexpected rule matches require checking the configuration; kernel startup failures call for reviewing ports, permissions, and configuration syntax.
This layered approach is more effective than repeatedly reinstalling everything. When a subscription update fails, test the subscription URL first; when a usable node takes the wrong route, inspect the rules; when the browser works but command-line tools do not, compare the system proxy with TUN; when domain access fails but direct IP access works, investigate DNS. Validate one layer at a time—the process becomes like opening folders one by one instead of overturning the entire desktop.
Treat each update mechanism separately
Client updates, kernel updates, subscription updates, and geographic database updates are four different things. Client updates mainly affect the interface, platform compatibility, and integration; kernel updates may change protocols, rules, or the network stack; subscription updates determine nodes and groups through the service provider; GeoIP and GeoSite databases affect the matching results of some geographic rules.
Routine maintenance does not require changing everything at once. Keep the current configuration working first, then update only for a clear reason. Before updating, export local overrides and important settings; afterward, verify kernel startup, subscription loading, proxy-group selection, rule matches, and DNS in order. If something breaks, review the most recently changed item—it is easier to recover than replacing the client, kernel, and configuration simultaneously.