Open-source cores and the client ecosystem
Knowing the difference between a core, a graphical client, and a subscription service helps you identify who provides a feature and where to troubleshoot an issue. This site provides download links and guides; it does not replace upstream release notes or configuration documentation.
How Clash, Meta, and mihomo relate
Clash was an important starting point for this category of rule-based proxy tools, and its configuration format gave rise to a wider ecosystem of clients and rules. Clash Meta extended that foundation; the subsequent core is maintained under the name mihomo. Search results may use these names for different programs. A filename alone does not tell you which features are supported.
Fields, startup arguments, and protocol support from older guides may not apply to current clients. If a field isn't recognized, first identify the core actually in use and check its documentation before editing the configuration or switching clients. Keeping a working backup is safer than migrating every advanced option at once.
Graphical clients and cores are maintained separately
Graphical clients provide tray menus, subscription management, proxy selection, and system integration. The core parses configuration, matches rules, and handles network connections. Even two clients using the same core may differ in override order, permission setup, and configuration storage. Similar-looking switches in their interfaces don't guarantee identical generated configurations.
When migrating, check the configuration and system settings separately. Ports, auto-start, system proxy settings, and TUN permissions usually aren't transferred just by copying a subscription. The downloads page summarizes maintenance status and platform links. Archived labels help identify clients that are no longer maintained and may appear in older guides.
Understand behavior through public source code
The mihomo core is licensed under GPL-3.0. Its source code, issues, and release history can help explain configuration behavior and changes. Open-source licenses govern how code may be used and distributed; they don't guarantee the quality of any subscription service or replace checking the source of a configuration. Check each graphical client's project documentation for its own license.
To verify a feature, start with the field documentation, then check for related issues and reproduction steps. When reporting a problem, include a minimal configuration snippet and redacted logs, with enough context to understand the issue. Don't upload a complete subscription or account credentials. A screenshot without steps to reproduce is usually not enough to distinguish a configuration issue from a software bug.
Check compatibility and rollback options before updating
A client update may change the interface, core, or system helper components. Before updating, save custom rules, overrides, and the currently working configuration, then check the release notes for breaking changes. Afterward, test a connection that worked before, then enable new features gradually. Don't change DNS, switch TUN, and replace the configuration in the same test.
Treat subscription updates and client updates separately. The former changes remote configuration; the latter changes program behavior. If a problem starts after a subscription refresh, check group names, rule references, and service status. If it starts after a client update, check the release notes and permissions. Establishing the order of events usually narrows down the cause.