On this page
Different project names in guides can make an interface app, a proxy core, and an older name seem like interchangeable tools. To judge whether a configuration suits your device, check the core and version actually running. Understanding the names helps with older documentation, but compatibility still needs configuration checks and real connections.
Clash Meta and Mihomo Are Names from Different Stages of the Same Project
Mihomo is the name later adopted by Clash Meta. Original Clash usually refers to the early Clash core started by Dreamacro; Meta in older guides and Mihomo in current logs do not represent two cores you must choose between.
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 |
Check the Running Client and Core Versions
If the same subscription behaves differently on two computers, check the configuration, core, and version actually loaded. Record the full name and version under “Settings → About,” “Core,” or “Runtime Logs.” For a command-line deployment, check the running binary rather than another program with the same name elsewhere on the path.
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.
Moving an old configuration to a new core may also require changes. If the behaviors, scripting capabilities, or client-generated fields it uses have changed, recheck them in Mihomo. Compatibility means more than being able to open YAML: configuration checks must pass, group references must be complete, and rule matches and DNS results must meet expectations.
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 | Rebuild for the original purpose; do not copy entire client-specific configuration blocks |
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.
- 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.
Moving an old configuration to Mihomo: backups, config checks, and real connection tests
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
Use the Mihomo binary you have actually selected to check the candidate configuration in a separate test directory; see the command example below. Address the first parsing, type or reference error actually reported instead of deleting an entire section at once.
Pin the same node
Compare everyday sites and internal domains first. Test apps that ignore the system proxy in the next step, after enabling TUN.
Then enable DNS and TUN extensions
Change only one layer at a time, observing connection records, rule matches, and network recovery after exit.
The command below uses the parameters supported by Mihomo v1.19.32. Replace the binary and both absolute paths with their actual locations. The test directory must contain trusted copies of the Provider and data files needed by the candidate configuration; do not point it at the active working directory.
-t checks the configuration and exits, -d sets the working directory, and -f selects the configuration. Initialization may write to the test directory or obtain required resources, so this is not wholly read-only. A success message confirms only that the configuration check passed; connections, rules and network recovery after exit still need separate verification. Passing the check does not establish support for unknown or old client-specific fields; consult the documentation for that version.
mihomo -t -d '/absolute/path/to/test-data' -f '/absolute/path/to/candidate.yaml'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.