Project history: from Clash configuration syntax to mihomo
Clash established a configuration approach that uses YAML to describe nodes, proxy groups, and rules. mihomo carries on that approach in rule-based proxying and continues to evolve its protocol support, rules, and network traffic capture. Older guides may refer to Clash, Clash Meta, or newer client names from different points in a project's history. Check the documentation for the core you're actually running, rather than judging compatibility by a file extension or window title. If a field isn't recognized, note the full error and field location, then check the core documentation.
Open-source ecosystem: core licenses don't cover client details
You can inspect mihomo's source code and GPL-3.0 license in its public repository. GUI clients build on the core with features such as configuration import, system proxy settings, tray menus, and permission services. Check each project's distribution method, license, and platform support separately. A client using a particular core doesn't automatically inherit every feature of other clients. This site separates software downloads from configuration references, so settings in one interface aren't mistaken for core fields available on every platform.
How it runs: the interface and the final configuration
A client typically reads a subscription, applies overrides and merges local settings, then passes the generated configuration to the core. What you see in the subscription view may not match what's running. The loaded configuration and connection logs are more useful for troubleshooting than an “import successful” message. Rule targets must refer to existing nodes or proxy groups, provider names must match their references, and DNS listening addresses need to fit the system's request path. Optional features such as sniffing, process rules, and TUN also depend on system permissions and client implementation.
Updates: check the app, subscriptions, and rule sets separately
Updating the client, updating the core, refreshing a subscription, and updating geolocation databases are separate operations. Software updates can change field or permission behavior; subscription refreshes can replace nodes and proxy groups; rule-set updates can change domain classifications. For easier troubleshooting, change one type of content at a time and keep a copy of the previous configuration. After an update, check startup logs, proxy group references, and rule matches for commonly used services. Don't consider verification complete just because the interface opens. Find package details on the download page; the homepage provides platform links and a suggested order for reading the configuration guides.
Troubleshooting scope: restore connectivity, then narrow down the cause
When something goes wrong, first turn off the system proxy or TUN and check whether your regular network connection comes back. If the underlying network is still down, troubleshoot it first. Once it's working, check the local listening port, DNS requests, node reachability, and matched rules in that order. When reporting an issue, include your operating system, client name, core in use, sanitized logs, and the most recent configuration change. Don't share passwords, subscription URLs, or controller credentials publicly. These details make issues easier to reproduce and help distinguish client integration problems from core configuration issues.