Clash cores: a compatibility comparison

First, distinguish the client, core, and config

“The subscription imports, but nodes won’t connect” and “The client has no TUN toggle” are problems at different layers. The GUI client manages subscriptions, tray menus, the system proxy, and config merging. The core reads the final config, listens on ports, resolves DNS, matches rules, and establishes proxy connections. The config describes how these behaviors work. To understand the differences between original Clash, Clash Meta, and mihomo, first identify the core that is actually running—not just the app’s name in the window.

• Client version: Determines the interface, service installation method, and config override behavior. Updating the GUI does not necessarily update the core.
• Core version: Determines protocol implementations, supported fields, and routing capabilities. Check the version in the client’s runtime logs or the core’s version command output.
• Subscription format: It may be a complete Clash YAML config, a list of nodes, or a collection of encoded share links. These formats are not interchangeable.

How original Clash, Meta, and mihomo are related

Original Clash: distinguish the open-source core from Premium

“Original Clash” usually refers to Dreamacro/Clash. Historically, the project offered both an open-source core and closed-source Premium builds with additional features. The original project is no longer maintained. When discussing support for TUN, scripts, or a particular rule type, specify which build you mean. Premium features should not be attributed wholesale to the open-source version, and the two builds should not be assumed to use identical configs.

For example, the open-source original core’s mixed-port and Premium’s TUN support are different kinds of features. The former provides a local HTTP/SOCKS proxy endpoint; the latter involves routing traffic through a virtual network interface. Seeing tun: in a config does not mean that any binary called Clash can use it.

Clash Meta: extending the original core

Clash Meta is a fork that evolved from Clash, adding support for more protocols, DNS options, rules, and TUN. A “Meta config” usually means a config that uses extension fields supported by this fork, not a completely different file format. It still uses YAML and familiar top-level structures such as proxies, proxy-groups, and rules.

mihomo: the Meta project’s later name

Clash Meta was later renamed mihomo. They are part of the same project lineage, not unrelated cores. Some clients still label the core entry “Meta” even though the executable is mihomo. Conversely, an older Meta binary will not support newer fields just because its name is similar. Compatibility depends on the specific version.

# Check the version of a manually installed core
mihomo -v

# Check the version of a legacy Clash binary
clash -v

These commands require the executable to be available in your system PATH. In Windows PowerShell, run .\mihomo.exe -v from the current directory. If the client bundles its own core, check the version in its startup logs first to avoid inspecting a different, globally installed copy.

Protocol support: check node types and transport settings

The protocol name is the first thing to check, but it is not the whole story. A VMess or Trojan node may also use transport or encryption settings such as WebSocket, gRPC, or TLS. A connection can work only if the node type, transport, and required fields are all supported.

“Supports Shadowsocks” does not mean “supports every cipher”

Newer ciphers may require a newer core. When troubleshooting, note fields such as type, cipher, and network rather than just saying “SS node.” An “unsupported proxy type” error points to a core capability issue. A connection timeout also calls for checking the server, network route, UDP connectivity, and authentication parameters. These problems need different fixes.

REALITY is not a standalone proxy type

A typical config declares the node with type: vless, then specifies the relevant settings with fields such as reality-opts. Changing the node type to reality or simply deleting unfamiliar fields does not convert the protocol. Likewise, changing type: hysteria2 to ss will not create a working Shadowsocks node; the server must also support the corresponding protocol.

Config compatibility: similar foundations, different extension support

When migrating an original Clash config to mihomo, the basic structure can often be kept. Going the other way—from mihomo to original Clash—can expose unsupported protocols, rules, or differences in field behavior. Compatibility is directional; using YAML does not make configs interchangeable. Even if the parser reports no errors, verify that the fields actually take effect.

Start with a minimal config to check ports and rule handling

The mihomo config below checks the basic structure and contains no remote nodes. The PROXY group contains only DIRECT, so all requests ultimately connect directly. It can verify local listeners and rule structure, but not the quality of a proxy route.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,PROXY
  - MATCH,DIRECT

• mixed-port: 7890: Accepts HTTP and SOCKS proxy requests on the same local port. It does not automatically enable the system proxy.
• allow-lan: false: Does not expose the proxy listener to your LAN. Preserve the original access scope when migrating; do not open the listener just to troubleshoot connection problems.
• mode: rule: Uses rule-based routing. In global mode, you cannot test routing by checking whether a domain rule matches.
• MATCH,DIRECT: Acts as the final fallback. For actual proxy use, change the fallback outbound to suit your policy.

Check fields that commonly break across versions first

Check rules, rule sets, and subscriptions separately

For basic rules, check their order and target names

DOMAIN, DOMAIN-SUFFIX, IP-CIDR, and MATCH are common rule types. Rules are generally evaluated in order, so a broad rule near the top can shadow more specific rules below it. If all traffic goes through the same group after migration, check whether MATCH appears too early, then verify that the group names referenced by the rules exactly match those in proxy-groups.

Do not assume original Clash supports mihomo’s logical rules, process-based rules, or extended matching features. Process detection also depends on the platform, permissions, and how traffic is captured. A config passing validation only confirms that its syntax and references meet the current core’s requirements; it does not guarantee that every app can be identified by process on every platform.

RULE-SET also depends on the rule file format

When using RULE-SET, also check the name, behavior, format, and file contents under rule-providers. The domain, ipcidr, and classical behaviors expect different rule formats. For example, do not put a complete DOMAIN-SUFFIX,example.org rule into a data source that accepts domain entries only.

mihomo’s MRS rule sets use a specific format, with support also limited by core version and behavior type. Renaming a file from .mrs to .yaml does not change its encoding. When reverting to an older core, get a rule source that the target core supports instead of just changing the extension.

A successful subscription import does not prove compatibility

1. Check whether the subscription returns a complete config or a node list intended for proxy-providers.
2. Check whether the subscription service provides a generic Clash config or an extended config specifically for Meta/mihomo.
3. Check whether the client uses overrides, merging, or scripts to change ports, DNS, rules, or policy groups.
4. Use the final config passed to the running core as your reference, not just the original downloaded file.

Configs and logs may contain subscription URLs, node passwords, UUIDs, or controller API secrets. When reporting an issue, include only the relevant field structure and error messages, and remove credentials first. Never post a full subscription link in a screenshot or public forum.

Migration steps: validate the config, then test traffic

Keep the old setup available as a fallback, and change one variable at a time. Do not switch clients, change subscriptions, enable TUN, and rewrite DNS all at once. Otherwise, even if the problem goes away, you will not know what fixed it.

1. Record the current setup: Save the core and client versions, a copy of the current config, listening ports, and selected policy groups. Confirm how the old config behaves on your current network.
2. Check the candidate config: Test it with the mihomo binary you plan to run. Fix the first parse error before moving on to the next check.
3. Start the new core on its own: Stop the old core or assign the new one different ports. Do not let two processes compete for 7890 or the controller port.
4. Test the explicit proxy first: Keep TUN off and test a known-working node through its specified HTTP/SOCKS port.
5. Then test rules and DNS: Visit destinations that should connect directly and through the proxy. Check the connection logs for the matched rule, policy group, and final node.
6. Enable TUN last: Install the service required by the client or grant the necessary permissions, then check the virtual interface, routes, and DNS capture.

# Check the candidate config; this does not start a persistent proxy service
mihomo -t -f ./candidate.yaml

# Send a request through the HTTP proxy endpoint
curl -I --proxy http://127.0.0.1:7890 https://example.org/

# Send a request through the SOCKS endpoint, resolving the target domain via the proxy
curl -I --proxy socks5h://127.0.0.1:7890 https://example.org/

On Windows, use curl.exe to call curl explicitly and avoid interference from the same-name alias in older PowerShell versions. Replace the target URL with the site you want to test, then check the egress in the connection log. The minimal config above connects directly, so it cannot prove that a remote node works.

A successful -t check is not a complete connectivity test. External rules, node providers, local database files, and relative paths still need to be checked separately. The working directory may also differ between command-line and client runs. If a manual test cannot find a file, that does not necessarily mean the YAML is wrong.

Common questions and core selection

Choose a core based on your config requirements: list the node protocols first, then your rules, DNS, and traffic-capture needs. Finally, choose a client that provides a suitable mihomo version and permission management. For field definitions, see the technical reference. For your first setup, follow the guide to import a subscription and test the explicit proxy before adding rules and TUN step by step.