Clash Meta vs Original Clash: A Comprehensive Comparison

2026-07-26 10 min read

When setting up Clash, one of the first decisions you face is choosing between the original Clash core and Clash Meta. While they share the same foundation, there are significant differences in protocol support, rule engine capabilities, DNS handling, and more. This guide breaks down every key difference to help you make the right choice.

History: From Original Clash to Meta Fork

The Rise and Fall of Original Clash

Clash was originally developed by Dreamacro as a multi-platform, rule-based proxy client written in Go. Thanks to its flexible rule engine and broad protocol support, it quickly became the most popular proxy tool in the community.

Key Timeline
  • 2019: Clash project born, supporting HTTP/Socks5 proxy entry points
  • 2020: Clash Premium released, introducing TUN mode, rule providers, and other advanced features
  • 2021: The Clash ecosystem thrives with numerous third-party clients (Clash for Windows, Clash for Android, etc.)
  • November 2022: Original Clash repository deleted by the author, all Premium source code becomes unavailable
  • Late 2022 - Present: Community forks emerge rapidly; Meta becomes the most actively maintained successor

The Birth of Meta

After the original repository was removed, community developers created multiple forks based on the last publicly available source code. Clash Meta (maintained by MetaCubeX) emerged as the most successful and active fork. It not only inherited all features from the original but also added new protocols and capabilities.

Current Status

As of 2026, Clash Meta is the de facto mainstream Clash core. Nearly all newly developed Clash clients use the Meta core by default. The original Clash has been completely discontinued and only exists in legacy clients.

Protocol Support: Meta Goes Further

Protocol support is the most critical difference between the two. Meta has significantly expanded the range of supported protocols:

Protocol Support Comparison
Protocol Original Clash Clash Meta
HTTPYesYes
SOCKS5YesYes
ShadowsocksYesYes
VmessYesYes
TrojanYesYes
SnellYesYes
VlessNoYes
RealityNoYes
TuicNoYes
Hysteria2NoYes
WireGuardNoYes
ShadowTLSNoYes

Meta-Exclusive Protocols Explained

Vless + Reality: Currently the most censorship-resistant protocol combination. Reality simulates real TLS fingerprints, making it extremely difficult to detect and block. For users who frequently face interference, this is the top choice.

Tuic: A QUIC-based UDP protocol with ultra-low latency, ideal for gaming and real-time communication.

Hysteria2: A high-performance QUIC protocol with excellent tolerance to packet loss, perfect for unstable network conditions.

WireGuard: A lightweight VPN protocol with exceptional performance, suited for scenarios requiring stable persistent connections.

Protocol Selection Note

If your proxy subscription includes Vless/Reality nodes, you must use the Clash Meta core. The original Clash cannot connect to these protocols. As more providers default to Vless+Reality, choosing Meta has become essential.

Rule Engine: Meta Is More Flexible

The rule engine determines how Clash routes different types of traffic. Meta adds numerous rule types beyond the original:

Original Clash Rule Types

Meta's Additional Rule Types

Meta-Exclusive Rule Types
  • PROCESS-PATH: Match by process path (e.g., only proxy traffic from Chrome)
  • PROCESS-NAME: Match by process name
  • PROCESS-PATH-REGEX: Regex-based process path matching
  • UID: Match by Linux user ID
  • NETWORK: Match by network type (TCP/UDP)
  • DSCP: Match by DSCP marks
  • RULE-SET: Reference external rule sets (supports optimized mrs binary format)
  • LOGICAL: Logical combination rules (AND/OR/NOT, nestable)

RULE-SET Rule Providers

RULE-SET is one of Meta's most important enhancements. It allows you to define rules in external files and reference them on demand, keeping your main configuration lean:

rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@release/lite/reject.yaml"
    path: ./ruleset/reject.yaml
    interval: 86400
  
  proxy:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@release/lite/proxy.yaml"
    path: ./ruleset/proxy.yaml
    interval: 86400
  
  direct:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@release/lite/direct.yaml"
    path: ./ruleset/direct.yaml
    interval: 86400

rules:
  - RULE-SET,reject,REJECT
  - RULE-SET,proxy,Proxy
  - RULE-SET,direct,DIRECT
  - GEOIP,LAN,DIRECT
  - MATCH,Proxy

LOGICAL Composite Rules

LOGICAL rules let you combine multiple rules using boolean logic for fine-grained traffic routing:

rules:
  # Only proxy google.com traffic on port 443
  - LOGICAL-AND,
    - DOMAIN,google.com
    - DST-PORT,443
    ,Proxy
  
  # Direct traffic from bilibili.com or douyin.com
  - LOGICAL-OR,
    - DOMAIN,bilibili.com
    - DOMAIN,douyin.com
    ,DIRECT

DNS Handling Differences

DNS handling is crucial for a proxy tool, directly affecting access speed and pollution prevention.

Original Clash DNS Capabilities

Meta's DNS Enhancements

Meta DNS Features
  • DoT/DoQ Support: Beyond DoH, also supports DNS over TLS and DNS over QUIC
  • EDNS Client Subnet: Can carry client subnet info for more accurate CDN resolution
  • Nameserver Policy: Assign DNS servers by domain for granular DNS routing
  • Optimized DNS Cache: Smarter caching strategy to reduce repeated queries
  • Respect-rules: DNS query results can be influenced by routing rules

Nameserver Policy is a standout Meta DNS feature:

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver-policy:
    # Use domestic DNS for Chinese domains
    "+.baidu.com":
      - "https://dns.alidns.com/dns-query"
    # Use foreign DNS for international domains
    "+.google.com":
      - "https://dns.google/dns-query"
    # Wildcard: all other domains
    "+":
      - "https://dns.alidns.com/dns-query"
      - "https://dns.google/dns-query"
DNS Performance Tip

Using fake-ip mode combined with Nameserver Policy provides both pollution prevention and the fastest resolution speed. Meta's DNS capabilities clearly surpass the original, so it's recommended to enable all DNS enhancements.

Configuration Syntax Differences

While Meta and the original share largely compatible configuration syntax, there are some differences to note:

1. Configuration Header Declarations

Meta recommends new header fields to declare kernel-specific options:

# Meta kernel configuration
profile:
  store-selected: true
  store-fake-ip: true

# Global client fingerprint
global-client-fingerprint: chrome

2. Proxy Group Type Differences

Meta adds the dialer-proxy field, allowing chained proxies (proxy over proxy):

proxies:
  - name: "ss-over-trojan"
    type: ss
    server: example.com
    port: 443
    cipher: aes-256-gcm
    password: "your-password"
    dialer-proxy: "trojan-relay"  # Route through trojan-relay proxy

3. TLS Configuration Enhancements

Meta significantly enhances TLS configuration with more fingerprinting options:

proxies:
  - name: "vless-reality"
    type: vless
    server: example.com
    port: 443
    uuid: your-uuid
    network: tcp
    udp: true
    flow: xtls-rprx-vision
    reality-opts:
      public-key: your-public-key
      short-id: your-short-id
    client-fingerprint: chrome  # Client fingerprint spoofing
    tls: true

4. Compatibility Notes

Configuration Compatibility
  • Original config to Meta: Most original configurations work directly in Meta, as it maintains backward compatibility
  • Meta config to Original: Meta-specific configurations (vless, reality-opts, mrs format) will cause errors in the original
  • mihomo naming: Meta was later renamed to mihomo; some configs may use "mihomo" as the identifier

Client Support Landscape

Since the original Clash is no longer maintained, the vast majority of active clients have switched to the Meta core:

Client-Core Reference Table
Client Core Status
Clash Verge RevMeta(mihomo)Actively maintained
FlClashMeta(mihomo)Actively maintained
Clash Meta for AndroidMetaActively maintained
Clash NyanpasuMeta(mihomo)Actively maintained
mihomo-partyMeta(mihomo)Actively maintained
Clash for WindowsOriginal ClashDiscontinued
Clash for AndroidOriginal ClashDiscontinued
OpenClashBoth supportedActively maintained
Client Selection Advice

If you're a new user or planning to migrate from an old client, choose a Meta-based client directly. For Windows, try Clash Verge Rev or FlClash. For Android, use Clash Meta for Android. For macOS, try Clash Verge Rev or mihomo-party.

Performance Comparison

Performance is another important dimension many users care about.

Memory Usage

Due to additional protocol and rule type support, Meta uses slightly more memory than the original. With few rules, the difference is minimal (about 10-20MB). However, when rule sets exceed thousands of entries, Meta's optimization mechanisms (such as binary mrs format) significantly reduce memory consumption.

CPU Usage

In daily use, CPU usage is nearly identical between the two. Meta's Vless/Reality protocols may incur marginally higher CPU overhead in some scenarios, but the difference is within 5%.

Network Throughput

When using the same protocols, network throughput is essentially the same. Meta's Tuic/Hysteria2 protocols are UDP-based and show clear throughput advantages in high packet loss environments.

Rule Matching Speed

Meta's mrs binary rule format loads and matches significantly faster than the YAML text format used by the original. If your configuration has a large number of rules, Meta's performance advantage is very noticeable.

Performance Benchmark Reference
  • Rule set loading time (10,000 rules): Meta mrs format ~200ms vs YAML format ~1,500ms
  • Single rule match latency: Both in microseconds, no significant difference
  • Memory with 100 concurrent connections: Meta ~45MB vs Original ~38MB
  • DNS resolution speed (fake-ip mode): Essentially identical

Migration Guide: Moving from Original to Meta

If you're still using the original Clash core, here are the complete migration steps to switch to Meta:

Step 1: Back Up Your Configuration

Before migrating, back up your Clash configuration files (typically in ~/.config/clash/ or %USERPROFILE%\.config\clash\). Focus on backing up your config.yaml file.

Step 2: Download a Meta-Core Client

Download the appropriate Meta-based client for your operating system:

  • Windows: Clash Verge Rev (from GitHub Releases)
  • macOS: Clash Verge Rev or mihomo-party
  • Linux: mihomo CLI or Clash Verge Rev
  • Android: Clash Meta for Android
  • Router: OpenClash (supports selecting Meta core)
Step 3: Convert Your Configuration

In most cases, your original configuration works directly in Meta. If you have the following items, manual changes may be needed:

  • Convert type: http rule sets to the recommended mrs format
  • If you use vless or reality related configurations, verify the syntax is correct
  • Check for any legacy syntax that Meta doesn't support (very rare)
Step 4: Update Rule Set URLs

The Meta community maintains dedicated rule sets. Switch to these for the best experience:

rule-providers:
  # Meta-specific rule sets (mrs format, better performance)
  reject:
    type: http
    behavior: domain
    url: "https://mirror.ghproxy.com/https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/lite/reject-domain.mrs"
    path: ./ruleset/reject.mrs
    interval: 86400
Step 5: Test and Verify

After migration, test each aspect:

  1. Confirm all nodes connect properly
  2. Verify split routing works (domestic sites direct, international via proxy)
  3. Confirm DNS resolution is normal (no pollution, normal speed)
  4. Verify TUN mode works (if using TUN mode)
Migration Notes

During migration, close the old Clash client first to prevent port conflicts. Running two cores simultaneously will cause port binding errors. Only uninstall the old client after confirming the migration is successful.

Which Should You Choose?

Scenario-Based Recommendations
  • New users: Use Meta directly; no legacy concerns
  • Provider uses Vless/Reality: Meta is mandatory, no choice
  • Need granular routing (by process, by app): Meta's process rules are essential
  • Pursuing peak performance: Meta's mrs rule set format is faster
  • Simple use, minimal tinkering: Differences barely matter, but since original is discontinued, Meta is still recommended
  • Old devices / low memory: Original uses slightly less RAM, but the gap is negligible; Meta handles it fine
Final Recommendation

In summary, Clash Meta has become the absolute mainstream choice. The original Clash, having stopped maintenance, receives no new features or security updates. Meta not only maintains full backward compatibility with original configurations but also delivers more protocols, a more powerful rule engine, and better DNS handling. Unless you have a very specific reason to stick with the original, we strongly recommend choosing the Meta core.