Project history: similar names, different maintenance paths
Clash began as a rule-based proxy project and grew into an ecosystem of config formats, graphical interfaces, and different cores. After the original project and some early clients stopped being maintained, the community continued development along separate paths. Older tutorials in search results may describe a legacy interface, an outdated core, or an archived download. Don't assume a guide applies just because its title says Clash. Check the client name, the core it uses, and the features covered.
This site covers legacy clients separately from current options. Downloads, ratings, and unverified claims about community size aren't substitutes for choosing a client that fits your needs. Discontinued clients may help when understanding an older setup or migrating data; for everyday use, favor options that are actively maintained and meet your system requirements. Before migrating, back up your config and overrides, then check proxy protocols, proxy group references, rule-set paths, and startup settings. That way, you won't miss local customizations when moving a subscription URL.
Core and interface: separate roles for connections and controls
mihomo is an actively developed open-source proxy core in the Clash ecosystem, following the development path of Clash Meta. The core handles protocols, rule matching, DNS, and network connections. A GUI client provides controls for subscriptions, policy selection, logs, system proxies, and service management. Their release schedules may differ. To check whether a field is supported, consult the current core documentation and the client's integration details instead of assuming every client with Clash in its name supports it.
The same feature may also work differently across interfaces. For example, launch at startup might start only the interface or also launch a background service. Closing the main window may just hide it rather than stop the proxy. Check the actual running state, not just the toggle label. On mobile, distinguish the system VPN status from whether a node can connect: a connected VPN only confirms that the traffic tunnel is up; it doesn't prove the destination website is reachable.
Open-source basis: review code, licenses, and change history
mihomo's source code and license are available in its public repository. GPL-3.0 describes the open-source licensing terms for that project; it does not mean every GUI client or subscription service uses the same terms. Source code, release notes, and issue discussions can help clarify feature limits and known issues. When using software, follow applicable local laws, network policies, and service terms. Public source code and your active configuration are separate concerns, so check where your config comes from.
This site provides links to clients and documentation. It does not represent every listed project or provide proxy accounts or subscription services. Subscription URLs may contain credentials, so redact URL parameters, account details, server addresses, and other sensitive information before sharing logs or screenshots. When asking for help, include your operating system, client name, steps to reproduce, and relevant error messages. Keep useful diagnostic details, but never post your full subscription in a discussion forum.
Updates: clients, cores, and subscriptions are separate
Client updates usually affect the interface and integrated components; core updates may change protocol support or field behavior; subscription updates replace the nodes and rules published by the config provider. Treat these as separate operations. A successful subscription refresh doesn't mean the client is up to date, and installing a new client doesn't give an old subscription new features. Read release notes before upgrading, back up a working config, and note where local overrides are stored so you can compare changes if something behaves differently.
When troubleshooting an issue after an update, first check whether the config loaded, then verify rule targets and proxy group references, and finally compare DNS, ports, and traffic routing settings. Avoid changing everything at once, or you won't know what caused the result. The downloads page lists client options, the setup guide walks through the first connection, and the complete config reference explains fields. Following that order helps separate installation, config, and network issues.
First connection: troubleshooting checklist
On the config page, first confirm that the subscription has downloaded and is selected as the active config; simply seeing it in the list isn't enough. Next, check that the proxy groups referenced by your rules have an available target, choose rule mode, and enable a traffic routing method suitable for your device. Open a specific website and check the connection log for its domain, matched rule, and egress. If the connection doesn't appear in the log at all, first check whether the app is routing traffic through the client instead of assuming the node is down.
If some websites work and others don't, compare a failed request with a successful one. Did DNS resolution fail, or did the connection time out after it was established? Is the entire proxy group failing, or does only one rule point to the wrong target? A latency test is only a connectivity check under specific conditions; it can't replace a real request. After following the quick start guide for the basics, enable features like TUN, custom DNS, and launch at startup one at a time to keep troubleshooting straightforward.
Config Sidebar