Download a Client and Import Your Subscription
Just getting started? Visit the Clash client download page and choose a client for your operating system and processor architecture. After installing it, open the client’s “Config” or “Profiles” section and import the subscription URL from your provider. Select the imported profile, then choose a node from a proxy group. Subscription URLs often contain account credentials, so never share the full URL in public comments or screenshots.
To identify the right core, distinguish three components: the client provides the interface, system tray, subscription management, and system settings; the core parses configs, establishes proxy connections, and applies rules; the subscription supplies nodes and may also include proxy groups, rules, and DNS settings. A client downloading a subscription successfully does not mean its core supports every protocol in it.
First Checks After Importing
- Make sure the subscription downloaded successfully and that its profile is active—not the sample profile bundled with the installation.
- Check the startup logs for config parsing errors, unsupported node types, and port conflicts.
- On desktop, test a browser with the system proxy. On Android, you’ll usually need to grant VPN connection permission.
- If you need to route traffic from apps that ignore the system proxy, configure TUN separately. Avoid changing too many settings at once.
How the Original Clash, Meta, and mihomo Evolved
Original Clash and the Premium Branch
The original Clash generally refers to the Dreamacro project and its core. It established the widely used YAML config structure, including proxies, proxy-groups, and rules. The Clash ecosystem also includes a Premium core. Don’t conflate its capabilities with those of the open-source original: Premium offered additional features such as TUN, rule sets, and scripts, with support varying by build.
The original project stopped being maintained in November 2023. Older clients and cores may still run, but they won’t gain support for new node protocols, operating system changes, or config fields simply by downloading the same old software again. Existing configs can be useful as migration references; for a new deployment, choose a maintained core that meets your subscription’s requirements.
From Clash Meta to mihomo
Clash Meta branched from the Clash ecosystem, adding support for more proxy protocols, DNS, rule matching, and transparent proxying. The project was later renamed mihomo. That’s why providers’ “Meta format” subscriptions, tutorials mentioning “Clash.Meta,” and clients labeling their core “mihomo” often refer to the same project lineage.
The name change doesn’t mean every version is equivalent. Older Meta builds may lack protocols or config options added later, and newer mihomo versions may handle fields differently. Check the actual version and startup results when assessing a migration; don’t rely on whether the name includes “Meta.”
| Name | Role | What to Check |
|---|---|---|
| Original Clash | The core behind the early Clash config ecosystem | Whether your nodes are supported and whether the old config relies on a specific build |
| Clash Premium | An extended core in the original Clash ecosystem | Don’t assume TUN, rule sets, or scripts are supported by the open-source original |
| Clash Meta | The former name of the mihomo project | The client’s release date and core version, especially for newer protocol fields |
| mihomo | The project name adopted after the Meta era | Protocols, rules, and platform permissions supported by the current build |
Node Protocol and Subscription Compatibility
To check whether your subscription needs mihomo, start by looking at each node’s type. Don’t share your full config publicly; inspect only the fields you need on your own device. Common types such as Shadowsocks, VMess, and Trojan have long been part of the Clash ecosystem, but each protocol can still involve different encryption methods, transports, and options.
| Config indicators | Compatibility | What to check next |
|---|---|---|
type: ss | Common Shadowsocks nodes are a good starting point for migration | cipher, plugins, and whether it uses an SS2022 cipher |
type: vmess or type: trojan | The protocol name alone doesn’t guarantee the config will work | Check that WebSocket, gRPC, TLS, and server requirements match |
type: vless | Not generally supported by the original Clash; mihomo is usually the right choice | flow, reality-opts, and transport settings |
type: hysteria2 | Use a build with Hysteria 2 support | Server password, TLS settings, and whether the network allows UDP |
type: tuic | Use a build that supports the specific TUIC implementation | Protocol version, authentication fields, and UDP connectivity |
Subscription URLs and node share links
A full Clash YAML config usually includes proxy groups and rules. A proxy provider file generally contains only a list of nodes. A Base64-encoded node list or a single ss:// or vmess:// share link is a different input format. Whether a client can recognize or convert these formats is a client feature; don’t assume every core can read any link as a complete config.
When choosing a subscription format in your provider’s dashboard, use the “Clash Meta” or “mihomo” option if available, especially if your subscription includes VLESS, Reality, or Hysteria 2. Selecting an older Clash format may cause the converter to drop unsupported nodes. If the imported node count is much lower than expected, check the output format before assuming your account has run out of data.
Differences in Rules, DNS, and TUN Settings
Rule Order and Policy Names
Common rule types include DOMAIN, DOMAIN-SUFFIX, IP-CIDR, GEOIP, and MATCH. Rules are checked from top to bottom, and the first match determines where traffic goes. A final MATCH rule provides a clear fallback. During migration, make sure every proxy group referenced by a rule exists; group names must also match, including spaces and capitalization.
mihomo supports more advanced matching, including GEOSITE, logical rules, and process matching that depends on the platform, runtime permissions, and feature settings. Giving a legacy core a subscription with these rules may cause parsing errors. Even if it recognizes a rule type, missing geographic data or failed remote rule downloads can still affect the outcome.
Rule Providers and Legacy Scripts
rule-providers loads rule sets, and RULE-SET references them. When checking compatibility, look at each provider’s behavior, file format, and path—not just whether the top-level field exists. Legacy Premium script configs aren’t directly equivalent to mihomo features. To migrate them, rework the logic using supported rules and proxy groups.
DNS Is More Than a Server Address
DNS settings include the listen address, upstream servers, enhanced-mode, and fake-ip-filter. mihomo also offers DNS policies and traffic sniffing. A legacy core accepting a field doesn’t mean its default behavior is identical. After migrating, test DNS resolution, rule matching, and actual connections separately.
For example, with fake-ip enabled, an app may receive a virtual address in the 198.18.0.0/16 range—not the server’s real IP. The same core must also receive the app’s traffic to map that address later. Copying DNS settings without setting up a traffic routing path can leave you with domains that resolve but websites that won’t load.
TUN and System Proxy
The system proxy is mainly for apps that follow the operating system’s proxy settings. TUN routes traffic through a virtual network interface and usually requires administrator permissions, service mode, or relevant system capabilities. Windows, macOS, and Linux configure routing differently; Android clients generally use VpnService to create a VPN interface. A TUN toggle in the client doesn’t mean the feature works the same way on every platform.
Check fields such as tun.stack, auto-route, and dns-hijack against your target version and platform. For your first migration, leave TUN off and use the system proxy to confirm that nodes connect. Then enable routing and DNS interception one setting at a time. This makes it easier to distinguish protocol issues from permission problems and routing conflicts.
Check the Core Version and Test Your Config
In a graphical client, first check the core details on the About page and look for the version in the startup logs; the exact menu names vary by client. Don’t use the client’s version number in a core bug report. For a command-line setup, run these two commands: the first prints the version, and the second checks the specified config. Make sure both commands use the binary you intend to run.
mihomo -v
mihomo -t -f ./config.yamlIf mihomo isn’t on your system’s search path, run ./mihomo from the current directory on Linux or macOS, or use .\mihomo.exe in Windows PowerShell. If you have multiple copies, also check the path used by the client. Otherwise, your terminal may test the new core while the graphical client still runs the old one.
Minimal Config and Port Checks
The YAML below checks config structure and a local listener only. It contains no subscription nodes and does not provide a remote proxy connection. The mixed port is set to 7890 to accept both HTTP and SOCKS5 proxy requests; allow-lan: false limits access to this device. Save it as a separate test file rather than overwriting your active subscription.
mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
proxy-groups:
- name: Test proxy
type: select
proxies:
- DIRECT
- REJECT
rules:
- DOMAIN-SUFFIX,example.com,Test proxy
- MATCH,DIRECTAfter the config passes validation, start the core and use the command below to check the HTTP proxy listener. The example uses DIRECT, so success only confirms that the local proxy entry point and direct connection work—not that your subscription nodes are usable. If the logs report that the port is already in use, close the other running client or change both the test port and request port to match.
curl --proxy http://127.0.0.1:7890 --head https://example.comA config passing validation doesn’t guarantee a network connection. It can’t verify your node password, remote certificate, remaining subscription data, or your ISP’s UDP restrictions. Test each node in your actual subscription and check the connection logs. The controller is commonly available at 127.0.0.1:9090; that’s not a proxy port. If you enable it, set an access key and don’t expose it directly to the public internet.
Migrating Legacy Configs and Troubleshooting
Migration Steps
- Keep a copy of your original config. Back up local overrides, rule files, and proxy group selections separately. Don’t edit your only copy.
- Get a subscription in the right format. Use the Meta or mihomo output from your provider if available, and compare the node count and protocol types in the old and new configs.
- Test a basic connection. Start with the system proxy, keep rule mode enabled, and confirm that at least one real node can reach your target website.
- Add your custom settings. Add rule providers, DNS, and sniffing settings one at a time, checking the startup logs after each change.
- Re-enable TUN and startup options. Once the basic connection is stable, enable the virtual network interface and background service. Restart the device to confirm that the settings persist.
Error Categories
| Symptom | Check first | What to do |
|---|---|---|
| Unsupported node type | Node type and the actual core version | Choose a compatible subscription format or a core that supports the protocol |
| YAML parsing failed | Indentation, colons, list nesting, and quotation marks | Indent with spaces and fix the structure at the line number shown in the logs |
| Proxy group not found | Rules, group members, and proxy group names | Keep referenced names consistent and restore any groups omitted during conversion |
| Rule provider failed to load | Resource URL, file path, and format | Make sure the resource is accessible and matches the declared format |
| Node timed out | Server status, authentication, TLS, and UDP | Test another node and use the logs to identify the connection stage that failed |
| No connection after enabling TUN | Permissions, routing, DNS, and other VPNs | Turn off TUN for now, restore the basic connection, then check each setting separately |
Choosing a Core: Recommendations and FAQs
For a new installation, prioritize a maintained client and core that support your existing subscription. If you need VLESS, Reality, Hysteria 2, or newer traffic routing features, a suitable version of mihomo is usually the right choice. If you can’t migrate an older setup yet, first check your feature needs and system limitations, then plan a replacement. There’s no need to keep reimporting the same config just because the project name changed.
Your hardware architecture matters too. Apple Silicon and Intel Macs need different installers; Linux x86_64 and arm64 binaries aren’t interchangeable. A graphical client also handles desktop integration and updates, while a headless server can run a core from the command line. For a platform-by-platform comparison, see the comparison guide. For installation and import steps, see Getting Started.
My provider only offers a Clash Meta subscription. Can I import it into mihomo?
Usually, yes: both belong to the same project lineage. Still, check that the subscription fields are supported by your actual core version. If parsing fails, use the logs to identify the unsupported field rather than simply renaming the subscription to mihomo.
Do I need to buy a new subscription after switching cores?
The core and subscription account are separate. Whether your existing account still works depends on your provider’s protocols, authentication, and device limits. Usually, you just need to get the subscription in a format suited to the new core; a format mismatch doesn’t mean your account is invalid.
Can I replace the core in any old client by dropping in the mihomo file?
There’s no guarantee. Clients also depend on startup arguments, the controller API, file paths, and service management. Use the client’s built-in core switching or update feature if available. If the client doesn’t explicitly support replacing the core, choosing one with mihomo integration is more likely to keep the config and background services working together.
What does higher node test latency after a core upgrade mean?
First, make sure the test address, timeout, node, and network are the same. Compare results with multiple tests on the same network, and check actual page loads and connection errors too. A single latency change doesn’t prove that the core is slower, and a low latency number is no substitute for checking protocol compatibility.