How original Clash, Meta, and mihomo relate
Clash introduced a YAML-centered configuration model: listeners accept app requests, nodes define available outbounds, proxy groups organize nodes, and rules determine where connections go. Clash Meta expanded protocol and networking capabilities on that foundation, and its successors continued development under the mihomo name. Clash Meta and mihomo are therefore historically connected, but that doesn't mean every app with Clash in its name includes the same features. When you encounter an unfamiliar field, check which core is running and consult its documentation; this is more useful than repeatedly reimporting a subscription.
Common public implementations of the original Clash are no longer maintained, so defaults, supported protocols, and installation instructions in older guides may not apply to current clients. Before migrating, record the protocols, DNS mode, rule sets, and local overrides you use, then check each one against the new environment. Reading basic YAML structure is only the first step in compatibility; node transport parameters, provider behavior, and operating system integration may still differ. Keep a backup of historical configurations to make migration and troubleshooting easier to compare.
What the GUI and network core each handle
Desktop clients usually handle subscription imports, configuration switching, tray menus, auto-start, and system proxy toggles; the core parses the configuration and handles connections. A UI showing that the client is running doesn't guarantee that a target app is using the proxy, and a running core doesn't mean the system proxy and DNS are configured correctly. On Ubuntu, distinguish the GNOME desktop proxy, terminal environment variables, and TUN routing. Each covers different traffic, so choose the right path for each app to avoid duplicate capture and routing conflicts.
A command-line deployment suits standalone operation, service management, or remote maintenance, but tasks normally handled by a GUI become your responsibility. Decide in advance where the configuration lives, which account runs the service, how to view logs, and how to stop it if something goes wrong. A systemd working directory affects relative paths, and file permissions affect access to rule files. First confirm that the core can load the configuration in the foreground, then set up a background service. This helps separate configuration errors from service management issues.
Updates, subscriptions, and personal rules
Client updates, core updates, and subscription updates are three different operations. A client update may change the UI and system integration; a core update may change field behavior; a subscription update typically refreshes nodes and rules. Identify what you're updating and record the current settings first. In clients that support configuration merging, keeping personal rules in a dedicated override layer is usually easier to maintain than editing a downloaded subscription file. Still, check the merge order to ensure your DNS settings aren't overwritten by another source.
Open-source licenses set the terms for using and distributing code; they don't mean that all clients have the same license or release process. This site organizes configuration guides and download links; it doesn't replace each project's release notes. When reviewing issue discussions, compare the operating system, core type, and reproduction steps rather than relying on similar titles. Before sharing logs or configurations, remove subscription URLs, passwords, and personal network information. The field structure and error context are usually enough for a technical discussion.
Troubleshoot connections layer by layer
Start closest to the app: check whether it uses the system proxy, a manually configured proxy, or TUN. Then check the local port and core, followed by rule matches, the selected proxy group, node connectivity, DNS, and the destination service. A page opening in a browser only confirms that one path works; it doesn't verify other apps or protocols. Change one variable at a time and keep logs from before and after each change to make cause and effect clear.
For DNS issues, distinguish resolution failures from cases where resolution succeeds but the connection fails. For the first, check the request path, upstream availability, and resolution mode; for the second, continue with rules, the outbound, and the destination address. HTTPS certificate warnings shouldn't automatically be blamed on the proxy: system time, certificate chains, packet inspection tools, and the destination service can all be involved. Don't disable certificate validation just to make a page load; keep the error details and troubleshoot layer by layer. For protocol differences and core choices, see the protocol reference. To follow a step-by-step setup, start with the getting started guide.
