Clash Glossary: Proxy Protocols, Rule Routing & Client Feature Terms Explained

A lightweight proxy protocol built on symmetric encryption; client and server only need to agree on a cipher and password to communicate. It's designed to be simple and efficient with low encryption overhead. A node with type: ss uses this protocol, with common ciphers being aes-256-gcm and chacha20-ietf-poly1305.

The native protocol of the V2Ray ecosystem, using a UUID for authentication with a handshake that depends on time sync — if the local clock drifts more than roughly 90 seconds from the server, the connection simply fails. Often paired with WebSocket and TLS as the transport layer, with config field type: vmess.

A streamlined successor to VMess: it drops the protocol's built-in encryption entirely, leaving security to an outer TLS or REALITY layer, which cuts packet overhead. The original Clash core doesn't support it — it needs the mihomo core, which mainstream GUI clients already bundle.

A protocol that disguises proxy traffic as standard HTTPS; the server must hold a valid TLS certificate and listen on port 443, so its traffic pattern looks like a normal website visit. Client-side config is short: address, port, password, with config field type: trojan.

A QUIC-based proxy protocol that carries data over UDP with aggressive built-in congestion control, giving noticeably better throughput than TCP-based protocols on high-loss, high-latency links. Requires the mihomo core; if the network throttles UDP, results can go the other way.

The current name of the Clash Meta core, a community-driven continuation after the original Clash core stopped being maintained. Clash Plus, Clash Verge Rev, FlClash, and other mainstream clients all use it as the underlying engine, handling port listening, config parsing, rule matching, and traffic forwarding. It supports protocols the original core never had, such as VLESS and Hysteria2.

The config.yaml the core reads, using indentation to express structure, with the main sections being mixed-port, dns, proxies, proxy-groups, and rules. Indentation must use spaces only — mixing in tabs causes an outright parse failure, the most common error when editing configs by hand.

A combined listening port: the same port accepts both HTTP and SOCKS5 proxy requests, saving the trouble of configuring two separate ports. 7890 is a common default. A startup error like bind: address already in use means another process already holds that port — change the port number or stop the conflicting process.

The core creates a virtual network adapter that takes over all outbound traffic at the network layer, regardless of whether an app reads proxy settings. Command-line tools and game clients that ignore the system proxy can only be covered by TUN mode. Turning it on needs admin or root privileges, and some clients require installing a system service first.

A DNS working mode: the core immediately returns a fake address from the 198.18.0.0/16 reserved range for a domain lookup, deferring the real resolution until after rule matching. This skips the resolution wait and lets the core route precisely by domain; the trade-off is that a few LAN apps needing the real IP must be listed under fake-ip-filter.

The RESTful control API the core exposes, listening on 127.0.0.1:9090 by default. The web dashboard uses it to read the node list, switch proxy groups, and view connections and logs. A secret field can be set as an access token, so other devices on the LAN can't call it freely.

For every new connection, the core checks the rules list from top to bottom and stops at the first match, letting that rule decide whether the connection goes direct, through a proxy group, or gets rejected. Order matters a lot: put precise rules first, and always keep the MATCH catch-all rule on the last line.

A set of nodes defined under the proxy-groups section; a rule's target is usually a proxy group rather than a single node. Common types: select for manual choice, url-test to auto-pick the lowest latency, and fallback for ordered failover. The groups you can switch on the client's proxy page are exactly these.

An IP location database, used with GEOIP rules to route by the destination's region. GEOIP,CN,DIRECT shows up in almost every config: if the target IP is in mainland China, go direct. The database is refreshed periodically by the core or client; a stale one can cause location mismatches.

A domain classification library organized by site purpose; a single line like GEOSITE,category-ads-all,REJECT covers an entire category of ad domains without listing them one by one. The difference from GeoIP: GEOSITE matches at the domain stage, GeoIP matches after resolution — so GEOSITE takes priority.

An external rule set referenced through rule-providers: the rule content lives in its own file hosted remotely, and the main config just writes a single RULE-SET,name,policy reference line. Rule sets can auto-update on an interval, making this the recommended way to maintain large custom rule sets.

The situation where, even with the proxy on, domain lookups still go straight to the local ISP's DNS. Two consequences: browsing intent gets exposed to the local network, and tampered results can break the connection. Turning on enhanced-mode: fake-ip under dns with an encrypted upstream is the common fix.

A proxy link's ability to forward UDP packets. Web browsing mostly runs on TCP, but online gaming, voice calls, and video conferencing rely heavily on UDP; when a node or protocol doesn't support UDP, these apps fail to connect or lose audio in one direction. The udp: true field in a node's config declares support.

The extension field during the TLS handshake that carries the target domain in plaintext, letting the server choose which certificate to return — and letting middleboxes identify where the traffic is headed. It's directly tied to how well Trojan-style protocols disguise themselves; the sni or servername field in a node's config is exactly this.

127.0.0.1 (a.k.a. localhost) points to the local machine itself, so the data never leaves the network card. Setting the system proxy to 127.0.0.1:7890 means browser traffic gets handed to the Clash client listening on port 7890 locally, which then decides where it goes. It only works on the local machine — other devices on the LAN need the machine's LAN IP instead.

A URL provided by a service that returns a full node list (usually an entire YAML config or an encoded node list) when accessed. Once imported, the client can pull updates manually or on a schedule, syncing node changes automatically. If an update fails, open the subscription link directly in a browser first to confirm it returns config content, not an error page.

A single server entry under the proxies section, containing address, port, protocol type, and credentials — the actual exit point for traffic. Each selectable item on the client's proxy page is a node; nodes are usually organized into proxy groups, and rules decide when each one gets used.

A toggle where the client registers an HTTP/SOCKS proxy address with the operating system; once on, apps like browsers that "respect system settings" route through the proxy automatically. Coverage is limited: programs that don't read system settings (most CLI tools, some games) are unaffected — that traffic needs TUN mode to take over.

The client sends an HTTP request through a node to a test URL (commonly http://www.gstatic.com/generate_204) and measures the time, reflecting the whole link's quality rather than a simple ping. Showing timeout means the node is currently unusable; a url-test proxy group uses this exact result to auto-pick the lowest-latency node.

Two troubleshooting entry points on the client: the log page streams core runtime output in real time (level controlled by log-level), and the connections page lists each active connection's target, the rule it hit, and its exit node. When routing doesn't behave as expected, check the connections page for which rule the domain actually hit — far faster than blindly editing the config.