Clash Core Architecture Analysis: Technical Implementation from Rule Engine to Traffic Distribution

1. Overview

Clash is a cross-platform proxy client developed in Go, renowned for its flexible rule system and efficient traffic distribution. Its core architecture follows a modular design, primarily consisting of a rule engine, DNS module, connection manager, and proxy adapters. This article dissects the technical implementation of these components.

2. Rule Engine

The rule engine is the heart of Clash, responsible for matching network traffic against user-defined rules and determining forwarding policies.

2.1 Rule Matching Process

• Rule Types: Supports DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD, GEOIP, IP-CIDR, SRC-IP-CIDR, etc.
• Matching Order: Rules are evaluated sequentially as defined in the configuration file; the first match terminates the process.
• Performance Optimization: Uses prefix trees (Trie) and hash tables for domain matching, and CIDR trees for IP rules.

2.2 Proxy Groups

Proxy Groups allow combining multiple proxy nodes with custom selection logic, such as:

• url-test: Automatically selects the optimal node based on periodic latency tests.
• fallback: Switches nodes in priority order.
• load-balance: Distributes traffic using consistent hashing.

3. DNS Resolution and Caching

Clash includes a built-in DNS module supporting multiple resolution modes to mitigate DNS pollution and leakage.

3.1 Resolution Modes

• Redir-Host: Redirects DNS queries to a specified upstream server.
• Fake-IP: Returns fake IP addresses, which Clash intercepts and maps to real domains, reducing DNS leakage.

3.2 Caching Mechanism

• LRU Cache: Caches DNS query results to reduce redundant requests.
• TTL Management: Respects DNS record TTLs but allows configurable min/max TTL to balance performance and freshness.

4. Connection Management

Clash employs an event-driven model for connection management, with core modes including tun and redir.

4.1 Connection Lifecycle

1. Listening: Listens for HTTP/SOCKS5 requests on a local port (e.g., 7890).
2. Parsing: Extracts the target address and queries the rule engine.
3. Proxying: Selects a proxy node based on the rule and establishes an outbound connection.
4. Forwarding: Performs bidirectional data copying, supporting TCP and UDP.

4.2 Multiplexing

• mux: Multiplexes multiple TCP connections over a single proxy connection, reducing handshake overhead.
• Connection Pool: Reuses idle connections to improve throughput.

5. Traffic Distribution and Proxy Adaptation

5.1 Proxy Protocol Support

Clash supports multiple proxy protocols, including Shadowsocks, VMess, Trojan, HTTP/HTTPS, and SOCKS5. Each protocol is implemented via an adapter pattern for easy extensibility.

5.2 Traffic Distribution Policies

• Direct Connection: Traffic matching DIRECT rules is sent directly.
• Proxy Connection: Traffic is forwarded through a proxy node.
• Reject Connection: Traffic matching REJECT rules is dropped.

6. Conclusion

Clash achieves high performance and customizability through its sophisticated rule engine, efficient DNS handling, flexible connection management, and extensive proxy protocol support. Understanding its architecture aids in optimizing configurations or conducting secondary development.