Project Lineage and Maintenance
Choosing a client is about more than its interface. Knowing which component reads the configuration, manages desktop services, and provides updates helps when changing devices or migrating an existing setup. This site organizes download links and usage guides; each client and core is maintained by its own project.
From the Original Clash to mihomo
Clash popularized a configuration model built around configuration files, policy groups, and routing rules, leading to a range of graphical clients. After the original project stopped being maintained, the community continued development in different directions. Clash Meta later continued under the mihomo name. Many actively maintained clients use it as their core, though update schedules vary between clients.
A client with Clash in its name does not necessarily support the same features as another. Check the current core's capabilities for protocol support, and the GUI client's features for the tray, keyboard shortcuts, and overrides. Keeping these roles separate also explains why the same configuration can behave differently in two clients.
Open Source and Configuration Compatibility
mihomo source code and project documentation are publicly available. For desktop users, open source makes it possible to look up configuration fields, read issue discussions, and understand the limits of a feature; it does not mean everyone needs to build from source. After installing a GUI client, use its bundled core and service management options to avoid troubleshooting complications caused by mixing tools.
Before migrating, keep a copy of your existing configuration, then check protocol types, rule set references, and DNS settings. Client-specific scripts and overrides may not be included in the subscription file, so copying a link alone may not carry over all your settings. For details on core lineages and protocol trade-offs, see the core overview in the technical reference.
What to Check Before and After Updates
Client updates, core updates, and subscription updates are three separate maintenance paths. A client update may change the interface or desktop integration; a core update may change how configuration fields behave; a subscription update may replace nodes, policy groups, or rules. If something changes, first identify which layer was updated, then check the logs and configuration instead of assuming one setting caused it.
Keep a record of configurations and overrides that work well. After an update, test your usual services, then check local network access, wake-from-sleep behavior, and network switching. A restorable setup helps maintain stability better than frequently switching clients; archived clients are best treated as migration references.