Clash vs. Clash Meta vs. mihomo: Protocol Support and Maintenance

Choosing a Core: Check the Engine, Not Just the Client Name

For a new config that requires VLESS, Hysteria2, TUIC, or newer rule features, first check that the client uses a mihomo build with the required support. Existing Clash Premium configs can be a starting point for migration, but an unmaintained legacy core is a poor default for a new deployment. Clash Meta and mihomo are successive names for the same project's development—not two unrelated protocol ecosystems.

For Clash for Apple users, the app name on a download page identifies the interface, not the protocols supported by its underlying core. A client may let you switch cores or bundle a fixed version, and app updates may ship separately from core updates. When troubleshooting, note the client version, core name and version, and macOS or iOS version.

How Clash, Premium, Meta, and mihomo Relate

Original Clash: Open-Source Core and Foundational Config Format

Original Clash established the familiar YAML config structure: proxy nodes, proxy groups, rules, and local proxy ports. Many clients adopted this format, so you may see proxies, proxy-groups, and rules across different apps. After the original project stopped active public maintenance in 2023, legacy builds may still run, but should not be expected to keep up with new protocols or system changes.

Clash Premium: A Legacy Closed-Source Fork, Not a Paid Subscription

Clash Premium was a closed-source core fork offered by the original project, with features such as TUN and rule sets. Premium refers to the core fork—not a paid plan from a proxy provider, and not a way to add protocols to the original core by purchasing a subscription. It belongs to a legacy maintenance track; a client that still launches does not mean its underlying core is actively maintained.

From Clash Meta to mihomo: Continuity and New Features

Clash Meta was a fork developed from Clash and was later renamed mihomo. Older guides, subscription converter options, and client settings may still use the name Meta. When you see “Meta core,” check the exact version rather than treating the name as a compatibility guarantee. Newer mihomo configs are not necessarily compatible with early Meta builds.

• Project name: Identify the maintenance source and the right documentation.
• Core version: Check which fields, protocol options, and fixes are included.
• Client version: Check the interface, helper services, and config merge behavior.
• System version: Check limits on network permissions, sandboxing, and extensions.

Protocol Support: Node Names Don’t Identify Protocols

Node names can be anything; the YAML type and its related fields determine how a node is parsed. A node called “High-Speed Line,” for example, could use Trojan or Hysteria2. Check the actual subscription contents to assess compatibility. Before sharing a config snippet, remove passwords, UUIDs, server addresses, and subscription tokens.

The same protocol may still have different parameters

Support for a protocol does not guarantee support for every transport, encryption method, or extension option. VLESS nodes may use flow, TLS, REALITY, and transport-layer settings; different TUIC protocol versions are not interchangeable either. If the log reports unsupported proxy type, check the core first. If the config loads but the handshake fails, check credentials, system time, TLS parameters, and network reachability.

A subscription converter can map input to a target format, but it cannot add protocol support to a core. Converting a Hysteria2 node into a YAML file labeled “Clash” does not give original Clash Hysteria2 support. When choosing a conversion target, specify whether you need a legacy Clash-compatible format or an extended format for mihomo.

Rules and DNS: Similar Syntax, Different Results

Common rules such as DOMAIN, DOMAIN-SUFFIX, IP-CIDR, and a final MATCH are usually the easiest to preserve during migration. Rules are evaluated in order, and the first match typically determines the route. A broad rule placed too early can prevent more specific rules from taking effect. Proxy group names must also match rule references exactly—migrating nodes alone is not enough.

Verify Rule Sets and Extended Rules Individually

• Remote rule sets: Check the format, source, and update method for rule-providers, and make sure every RULE-SET reference is valid. Don’t assume every original Clash build supports the full rule-set feature set of Premium or mihomo.
• Geodata: Rules such as GEOSITE depend on core support and the required data files. Copying rule text alone does not download or load those resources.
• Process rules: These depend on whether the system can provide process information. Behavior on macOS does not automatically carry over to iOS network extensions.
• Script policies: Legacy Clash Premium scripts are not a general compatibility interface for mihomo. For migration, prefer explicit rules and proxy groups.

DNS Settings Determine What Rules Can Match

fake-ip and redir-host are different DNS modes. fake-ip maps addresses to help the core associate domains with connections, while redir-host returns the resolved address. They are not interchangeable in every network environment. If nodes pass latency tests but websites won’t load after migration, check DNS upstream reachability, domain routing, and whether the system is actually using the core's DNS.

TUN Differences Between macOS and iOS

System proxy and TUN capture traffic at different points. The system proxy is mainly used by apps that honor the system's proxy settings. TUN captures traffic through a virtual network interface and routing, covering more apps that ignore system proxy settings—but it does not guarantee that all traffic goes through a proxy node. The route, exclusions, rules, and direct-connection policies determine the actual exit path.

macOS: Helper Services Aren’t the Same as Network Extensions

A macOS client may create a TUN interface through a privileged helper service or use Apple's Network Extension framework. Authorization steps vary by implementation, so enabling TUN does not always mean approving a system extension. On macOS 13 or later, start by checking VPN and network service status in System Settings → Network. If the client explicitly says system software was blocked, follow its instructions and check authorization under System Settings → Privacy & Security.

Common mihomo TUN settings include auto-route, auto-detect-interface, and dns-hijack. Automatic egress detection works well in typical single-uplink setups, but check the results on systems with multiple interfaces, another VPN, or custom routes. Seeing a utun interface on macOS does not by itself prove that the client has taken over traffic; macOS and other VPNs can create similar interfaces.

iOS: Network Extensions and App Capabilities Both Matter

iPhone and iPad apps typically provide network features through a Network Extension tunnel. You cannot copy a macOS executable over and run it on iOS. The first tunnel connection usually prompts you to add a VPN configuration; later, check the entry under Settings → General → VPN & Device Management. Even if the app imports a Clash-style config, supported protocols and fields depend on its core and documentation.

So, being able to import the same YAML on a Mac only confirms that the Mac client can parse it. It does not mean process rules, file paths, or background update behavior work identically on iOS. When sharing a subscription across devices, keep nodes and core routing rules consistent, but manage platform permissions, file locations, and traffic capture settings on each device separately.

Migrating to mihomo: Start Small, Then Restore Features

The minimal config below checks parsing, port binding, and basic rules. It includes only a DIRECT policy and no proxy nodes, so it cannot verify whether a remote node works. The example sets the mixed HTTP/SOCKS port to 7890 and binds it to the local loopback interface only. This port is an example, not a universal client default.

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
ipv6: false

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

rules:
  - MATCH,DIRECT-TEST

Check the Syntax First, Then the Network

When running a core on its own, use these commands to record its version and test the config. File paths are relative to the current directory. In a GUI client, use its config check to validate the final merged config, and avoid running a second core that could compete for the same ports.

./mihomo -v
./mihomo -t -f ./config.yaml
lsof -nP -iTCP:7890 -sTCP:LISTEN

Passing -t only means the config check passed; it does not verify nodes, DNS, or rules. Some checks also read local resources or fetch external data, so distinguish syntax errors from missing resources and failed network requests. If the log reports address already in use, first check whether a client is already using 7890. Don’t expose the service to your local network just to work around the error.

1. Back up: Save the old config, core version, client overrides, and current proxy group selections, with a copy you can restore directly.
2. Verify the basics: Turn off TUN, confirm parsing and local ports with a minimal config, then import a known-working node.
3. Restore routing: Add proxy groups, rules, rule sets, and DNS one category at a time. Check which rule each connection actually matches.
4. Enable TUN last: Check permissions, the default route, and DNS capture, then test apps beyond the browser.
5. Test rollback: After quitting the new client, confirm that the system proxy and tunnel are off before restoring the old version. Avoid letting two tools change routes at the same time.

Troubleshooting: Find the Compatibility Layer in the Error

Base your choice on three questions: Can the core parse the subscription's protocols? Can it apply the required rules correctly? Is traffic capture reliable on your Apple device? The core name points you toward a technical path; compatibility depends on the exact version and reproducible test results.