How Clash, Meta, and mihomo are related
Clash originally provided a proxy core and configuration system, around which graphical clients emerged for different platforms. After the original Clash project was discontinued, follow-on projects in the ecosystem continued to evolve. Clash Meta is a name often found in older guides and configuration notes; mihomo continues the technical path of that fork. When reading documentation, match historical project names to the core you're using today. Not every installer with Clash in its name belongs to the same project.
The core handles protocols, DNS, rule matching, and connection forwarding. The graphical client provides settings, profile management, system integration, and logs. Clients such as Clash Verge Rev call on a core to handle traffic, but updating the interface and updating the core are separate maintenance tasks. A feature is available only if the client exposes the relevant controls and its bundled core supports the setting. Replacing the interface alone won't resolve every configuration compatibility issue.
How to assess a project through its public code
Public repositories let you review source code, commit history, issue discussions, and release notes. If a setting changes or a protocol isn't supported, check the project's documentation and release history before trying configuration snippets from unknown sources. The mihomo core uses GPL-3.0. For other clients, check their own project files for code licenses, distribution terms, and third-party dependencies; the core's license does not automatically apply to every graphical client.
The command on the right clones mihomo's source code for users who want to inspect its implementation or contribute to development. Cloning the repository does not install a desktop client or create a system proxy service. Most users can choose a graphical client from the downloads page. To understand configuration behavior, consult the official documentation for syntax and defaults. This site provides download links and usage guides in Chinese; it is not part of the upstream projects' development teams.
What to check before and after updates
Clients, cores, remote subscriptions, and rule sets each have their own update sources. A client update may move settings; a core update may add protocol support or change fields; a subscription update may replace proxies and groups; and a rule set update may change which traffic is routed. These are separate updates, and you shouldn't change them all at once when troubleshooting. Identify which layer is causing the error before deciding whether to update, roll back, or revise the configuration.
Before updating, save local overrides, frequently used proxy group selections, and any important settings notes. Afterward, confirm the profile loads, then check DNS, LAN access, and your usual apps. If a site that worked before is now unreachable, compare the old and new configuration and release notes, focusing on fields that changed. Keep reproducible steps and sanitized logs to help the project community diagnose the issue—instead of reporting only that the connection failed.