How Clash, Meta, and mihomo are related
Clash established a way of working centered on YAML configuration, proxy groups, and rule matching. Community forks and graphical clients followed. Clash.Meta was an extended branch in this ecosystem, and its core project later continued development under the name mihomo. Older guides may refer to Meta, Clash Meta, or mihomo; these names reflect the project’s evolution and don’t simply represent three entirely separate user interfaces.
The original project and extended cores don’t have the same feature set. Check the core actually running for support of new protocols, DNS fields, rule features, and platforms—not whether the client’s name includes Clash. This site provides downloads and English-language guides; it doesn’t replace announcements from client or core projects. For implementation details, consult the relevant project’s documentation, source code, and release notes.
Check GUI clients and protocol support separately
Different clients can package the same core, while clients with similar interfaces may use different cores. The GUI handles subscription management, proxy switching, system integration, and log display; the core determines configuration syntax, connection protocols, and rule execution. A setting missing from the interface doesn’t necessarily mean the core can’t configure it. Conversely, a subscription file being saved doesn’t mean all its fields are supported and active.
Start by listing your actual needs: Do you need rule overrides, a specific protocol, per-app traffic capture, or config migration across devices? Then check the client documentation and the core information in its logs. Compare protocol differences and mobile platform trade-offs in the technical reference rather than drawing conclusions from a single probe or a green status indicator.
Subscription updates and software updates are separate
Subscription updates fetch remote configurations; software updates replace the app or its bundled core. Neither replaces the other. A subscription change may affect node names, rule targets, and proxy group references. A software update may add fields, change defaults, or fix compatibility issues. Back up your config and local overrides before updating. Afterward, check the logs and test commonly used apps; there’s no need to reset every option.
If a remote subscription overwrites local changes, look for the client’s persistent override mechanism rather than disabling all updates. GeoIP, GeoSite, and rule sets also have their own data sources and update schedules. When routing changes, first check whether the configuration or data files changed, then investigate the software itself. This process turns “it worked yesterday, but not today” into a set of testable questions.
How to use open-source resources beyond checking a badge
The value of source code is traceability: you can review implementation, configuration examples, issue discussions, and change history. Before downloading, confirm the project name matches the client. For configuration questions, prefer the current core documentation, and verify whether fields in old screenshots still apply. Repository stars don’t mean a project suits every device, and active discussions don’t mean a fix has shipped. Base your judgment on the actual documentation and release contents.
When reporting an issue, include your operating system, client name, core details, reproduction steps, and redacted logs. Don’t publish full subscription URLs, node passwords, or control interface credentials, and don’t paste your entire config into a public discussion. Issues reproduced with a minimal config are easier to diagnose: remove unrelated rules and overrides first, check whether the error persists, then add back the necessary context.