mihomo vs. Original Clash: Protocols, Rule Sets & Config Fields

Check the core first: a client’s name doesn’t define its capabilities

If importing a subscription triggers unsupport proxy type, or sniffer in your config doesn’t behave as expected, don’t start by changing node passwords. First, check which core the client is actually running. The client handles subscriptions, system proxy settings and controls; the core parses config, matches rules and establishes connections. Similar client names don’t mean they support the same fields.

“Original Clash” refers to two distinct products here: the original open-source core and Clash Premium, which was distributed separately. Premium features such as TUN and rule sets shouldn’t be attributed to the original open-source core. mihomo evolved from Clash Meta and retains many Clash config conventions, but it’s more than a renamed application.

• Desktop clients: Check the core version under “About” and review the startup logs. Menu names vary by client, so refer to the interface you’re using.
• Command-line deployments: Run mihomo -v on the binary that’s actually running. Don’t rely on the version of another copy in your downloads folder.
• Routers and containers: Check the core selected by the plugin, the container image and the process path. Updating the management interface doesn’t necessarily update the core.

Protocol support: VLESS, Hysteria2 and TUIC are key differences

If your subscription only includes traditional Shadowsocks, VMess or Trojan nodes, you may not notice much difference after migrating. Compatibility errors are more likely with newer protocols, encryption methods and protocol-specific transport settings. A node labeled “Hysteria2” proves nothing—the core reads the YAML type and related fields.

Where an error occurs determines what to check first

If a config test immediately reports an unsupported proxy type, the failure is at the local parsing stage; node connectivity hasn’t been tested yet. Conversely, a config that loads successfully but times out on connection doesn’t prove the protocol is unsupported. Check the server address, port, credentials and transport network next.

• VLESS: Check the UUID, TLS, servername, transport and flow. With REALITY, also verify the public key, short ID and other matching parameters.
• Hysteria2: It runs over QUIC and requires reachable UDP. Testing only the server’s TCP port doesn’t confirm that the node works. Don’t simply rename a first-generation Hysteria config and expect it to work.
• TUIC: UDP network conditions matter here too, and authentication fields must match the server protocol version. Client support for TUIC doesn’t prove the server parameters are correct.

Subscription conversion has its limits. A converter can rearrange fields, but it can’t add protocol support to an older core. If nodes disappear after conversion, first check that the output format targets mihomo and that the conversion service supports the protocol. Repeatedly updating the same incompatible subscription won’t help.

Rule sets: rule-providers aren’t exclusive to mihomo

rule-providers defines a rule set’s source, while RULE-SET references it in the rules list. The original open-source Clash core and Premium differ significantly here: Premium already supports rule sets, so it’s inaccurate to describe all rule-set features as new in mihomo. mihomo builds on that support with more formats and ways to use them.

Test the rule-set workflow with local YAML first

Here’s a rule example you can add to a mihomo config. It doesn’t rely on remote downloads, making it easier to tell a bad rule from a failed download. The config uses only the built-in DIRECT and REJECT policies, so it doesn’t depend on any undefined proxy groups.

rule-providers:
  local-block:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-block.yaml

rules:
  - RULE-SET,local-block,REJECT
  - MATCH,DIRECT

Create rules/local-block.yaml in the config working directory and add the following content. example.org is a reserved domain used here to demonstrate rule behavior; expect the domain and its subdomains to be rejected in testing.

payload:
  - '+.example.org'

Under behavior: domain, list domain matches only—don’t use DOMAIN-SUFFIX,example.org. For classical, use the appropriate rule syntax, such as DOMAIN-SUFFIX,example.org, and don’t include the final outbound policy in the rule set.

sniffer and DNS: domain detection isn’t traffic decryption

If some connections start matching domain rules instead of IP rules after migration, DNS mapping or sniffing may be the reason. mihomo’s sniffer can extract hostnames from some protocol handshakes, such as the HTTP Host header, TLS SNI and supported QUIC handshake data. It doesn’t decrypt HTTPS like a certificate-based man-in-the-middle, and it can’t identify the domain for every connection.

Observe first; then decide whether to enable destination override

sniffer:
  enable: true
  sniff:
    HTTP:
      ports: [80, 8080-8880]
      override-destination: false
    TLS:
      ports: [443, 8443]
      override-destination: false

This example covers HTTP and TLS only; it doesn’t mean every port needs sniffing. override-destination: false means the connection destination won’t be overridden based on sniffed data. That data may still inform domain detection and rule matching. Test with your DNS setup and apps before enabling destination override—it isn’t an optimization switch that should always be on.

• Domain not detected: The connection may not use a configured port, the handshake may not contain a usable domain, or the app may use a mechanism that hides this information.
• App connects directly to an IP: Sniffing may not recover the domain. Keep any necessary IP rules instead of relying on domain rules alone.
• Traffic routed incorrectly: Check rule order, DNS responses, fake-ip mappings and sniffer settings together. Don’t broaden sniffing coverage as your first step.

dns.enhanced-mode: fake-ip and redir-host are different modes, and fake-ip isn’t unique to mihomo. Keep your existing DNS mode during migration; if you need to change it, do so separately and clear the relevant DNS caches. The core’s DNS listener must also be connected to the system or traffic interception path. Setting dns.listen alone doesn’t route system requests through it.

TUN and ports: compatible config doesn’t mean the same traffic path

If your browser works but games, command-line tools or other apps bypass the proxy, check the traffic entry point before switching protocols. System proxy settings affect apps that respect them. TUN captures traffic through a virtual network interface and can cover more apps, but also requires permissions, routing and DNS interception.

Original Clash Premium includes TUN; don’t confuse it with the original open-source core. mihomo also supports TUN, but stack choices, interface parameters and routing settings from an older config may not work unchanged on every system. Permissions and service management differ across Windows, macOS and Linux.

Verify the migration in two passes

1. Turn off TUN first and use an explicit proxy to confirm that the node and rules work. For example, with mixed-port: 7897, the proxy endpoint is 127.0.0.1:7897. Here, 7897 is only an example—not a standard port for every client.
2. Run the command below in a terminal to confirm requests are actually going through this endpoint. The test URL checks basic HTTPS connectivity only; it doesn’t prove that every site is reachable.
3. Once the explicit proxy works, enable TUN in the client. Check elevation or service status, confirm the virtual interface and routes are in place, then test apps that don’t use the system proxy.

curl --proxy http://127.0.0.1:7897 --connect-timeout 10 -I https://example.com

If you see address already in use, first check whether two core processes are running at once. An old client left open during migration is a common cause of local port conflicts. If the whole device loses internet access, disable TUN and the system proxy in the new client, restore basic connectivity, then troubleshoot one setting at a time. Don’t stack multiple VPN or routing tools.

Config migration checklist: test parsing, loading, rules and connectivity separately

A config that “loads” has only passed parsing and initialization at the current stage. That doesn’t mean every field is being used—or that nodes and DNS work. Some unknown fields may not trigger an obvious error, so check the runtime logs and actual behavior as well.

1. Back up your current setup. Save the original subscription, the merged runtime config and any local override files. Never post subscription URLs or node credentials in public forums.
2. Choose a compatible subscription format. If the subscription service offers separate Clash and Clash Meta/mihomo outputs, choose the one for your actual core. Inspect the generated config rather than relying on the button label.
3. Run a config test first. Use the binary deployed on your system and specify the config file and working directory to avoid resolving relative paths from the wrong location.
4. Verify the proxy endpoint and node. Test with an explicit proxy first, then check the selected node or policy group in the connection log. If the connection fails, keep the full error chain.
5. Verify the rule set. Check that the provider loaded successfully, that its entries are present and which rule matches your test domain.
6. Enable enhanced features last. Change only one of DNS, sniffer or TUN at a time. If something breaks, you’ll be able to roll back to the last working config.

mihomo -v
mihomo -t -d /srv/mihomo -f /srv/mihomo/config.yaml

/srv/mihomo above is an example directory for Linux deployments; confirm the files are actually there before running the command. On Windows, test from the current config directory with mihomo.exe -t -d . -f .\config.yaml. When a client manages the core, the effective config may be generated by merging a subscription with overrides. Testing an unused original file isn’t enough.

Choosing a core: consider node protocols and maintenance needs

If you need VLESS, Hysteria2, TUIC, MRS rule sets or features such as sniffer, mihomo is a better fit. If you’re maintaining a config with traditional protocols, focus on testability, whether your client is still maintained and how easily you can isolate problems. Switching cores won’t automatically reduce latency.

• Current config is stable: Keep a backup and test the new core in a separate environment first. Don’t change nodes, rules and DNS all at once.
• Subscription reports an unsupported protocol: Check the generated format and the core actually in use before deciding whether to switch clients or cores.
• Router resources are limited: Monitor rule-set size, load time and available memory. Choosing a format doesn’t replace testing on the device.
• Moving back from mihomo: Remove protocols and fields unsupported by the target core one by one, then rerun config and connectivity tests.

Think of the differences in three layers: protocols determine whether a node can be parsed, rules and DNS determine how connections are routed, and the system proxy or TUN determines whether traffic reaches the core. Checking each layer in turn makes problems easier to isolate than changing several settings at once.