On this page
Mihomo, Clash Meta, and the original Clash: first determine whether they are even the same layer
Original Clash usually means the early Clash core started by Dreamacro. Clash Meta was a later fork that extended its configuration model, and Mihomo is the project name that Clash Meta subsequently adopted.
Clash Meta and Mihomo refer to different stages of the same project, not two new cores you must choose between. Many older tutorials say “Meta,” while the current project and logs more often say “Mihomo.”
Client names create more confusion. Clash Verge Rev, FlClash, and Clash Party are graphical clients that manage subscriptions, the system proxy, and the interface; the core actually running inside may be Mihomo. A filename containing Clash does not prove that it uses the original Clash.
Which layer each name represents
| Name | What it usually means | Why it matters now |
|---|---|---|
| Original Clash | The original Clash core and foundational configuration model | Understanding historical configurations and older client behavior |
| Clash Meta | A later core name that extended the original model | Reading older documentation, logs, and subscription notes |
| Mihomo | The current project name for Clash Meta | New deployments, current fields, and a maintained core |
| Clash graphical client | A desktop or mobile app that manages the core | Evaluate its interface, platform support, and the version of the core it actually includes |
Do not judge by the icon; inspect the version under “About” and in startup logs
If the same subscription behaves differently on two computers, the subscription usually did not change at random. The clients may bundle different cores or versions. Open “Settings → About,” “Core,” or “Runtime Logs” and record the full name and version. For command-line deployments, inspect the binary's version output directly.
mihomo -v
# 如果机器上运行的是旧名称的二进制，也应先看它自己的版本
clash -vDo not record only “latest version”
- Client name and version
- Whether the core is identified as Mihomo, Clash Meta, or Clash
- Exact core version
- Operating system and CPU architecture
- The configuration file actually loaded when the error occurred
Similar configuration formats still cannot be moved freely among different cores
Mihomo retains core structures such as proxies, proxy-groups, and rules, so basic configurations look familiar. It has since added or expanded protocols, DNS, TUN, rule sets, sniffing, and runtime fields.
When an old core encounters content it does not recognize, it may report unknown field or unsupported proxy type, or silently ignore fields and create harder-to-detect behavioral differences.
The reverse direction is not entirely painless either. If an old configuration relies on changed behavior, scripting capabilities, or client-generated fields, it may require fresh validation in Mihomo. Compatibility does not mean “the YAML opens.” It means validation passes, every policy-group reference resolves, and rule matches and DNS results behave as expected.
Where the same subscription most often differs
| Area | Original Clash environment | Mihomo environment | Migration approach |
|---|---|---|---|
| Node protocols and transports | Depends on the old core and version; it recognizes only the fields supported at that time | Continues to add and maintain more protocol and transport options | If unsupported proxy type appears, verify the core instead of deleting node fields until it loads |
| DNS | Capabilities and fields differ among older open-source/Premium versions | Current documentation includes complete DNS, Fake-IP, and nameserver options | Start with minimal DNS, then migrate Fake-IP filters and upstream servers one item at a time |
| TUN | Availability depends on the older fork, version, and client integration | Current Mihomo and mainstream clients generally provide TUN | Verify the system proxy first, then enable TUN and service permissions separately |
| Rules and Provider | Older cores accept only rule types and structures they recognize | Supports the rules, rule sets, and extension fields in current documentation | Check rule-provider behavior, policy-group names, and the final merged result |
| Client-specific fields | May be generated by an older GUI's Mixin, Parsers, or scripts | Generated by the new client's Merge, Script, or overrides | Migrate the intent only; do not copy entire blocks of client-private configuration |
unknown field
Common cause:The current core does not recognize the field, or the field is at the wrong level
Resolution:Verify against the official documentation for the actual core version; do not troubleshoot by deleting colons.
unsupported proxy type
Common cause:The protocol or transport exceeds the current core's capabilities
Resolution:Upgrade to the maintained core required by the provider, or use a compatible node.
proxy/group not found
Common cause:A policy group, rule, or override references a name that does not exist
Resolution:Inspect the final merged configuration, not just the raw subscription.
It loads, but rules behave differently
Common cause:DNS, rule order, or client overrides changed the runtime result
Resolution:Use connection records to compare the matched rule and outbound route for the same domain.
For new installations, prefer the maintained Mihomo; keep older cores only for specific legacy requirements
If you are reinstalling a desktop client, router plugin, or server service today, prefer a project that explicitly uses Mihomo and still has official releases and issue tracking. The main benefits are compatibility with current systems, security fixes, and consistent documentation—not automatic speed from a newer name.
Reasonable use cases for retaining Original Clash are usually narrow: a frozen offline environment, a configuration that uses only known capabilities, and upgrade risk greater than the benefit. Even then, record the binary source, version, and rollback method; do not keep exposing the old core as an internet-facing control service.
- Typical desktop users
- Choose an actively maintained client with Mihomo built in, starting from a clean subscription.
- OpenWrt users
- Verify the plugin version, Mihomo core architecture, and available storage together; do not upgrade only the LuCI page.
- Server or container deployment
- Pin an explicit version, run the configuration check in a test directory, then replace the running instance.
- Legacy original environment
- Keep it isolated and rollback-ready; do not send subscriptions with new protocols directly to the old core.
During migration, reproduce the old behavior first, then enable new capabilities one at a time
Safe migration order for one configuration
Preserve the old configuration
Back up the old configuration, core version, and a set of repeatable test addresses.
Remove client-private items
Do not copy the old GUI's window, cache, or service settings as Mihomo configuration.
Run configuration validation first
Resolve the first unknown field, type, or reference error instead of deleting an entire block at once.
Pin the same node
Compare frequently used websites, internal domains, and one app that ignores the system proxy.
Then enable DNS and TUN extensions
Change only one layer at a time, observing connection records, rule matches, and network recovery after exit.
Migration is not complete when the client says “connected.” Critical traffic from the old environment must match the expected rules under the new core, local-network and internal domains must still connect directly, and networking must recover after the system proxy or TUN is disabled. Delete the old binary and service only after achieving those results.