Clash Glossary: Every Term, One Page
Hit a term you don't recognize in the tutorials? Look it up here. 25 core concepts are organized into five categories, each with just a definition and a use case, so you can look it up and get straight back to what you were doing. To compare protocols, check the protocol reference; to follow along step by step, see the tutorial.
Proxy Protocols
That word in parentheses after a node's name determines its encryption, handshake speed, and core compatibility. Get to know these before choosing.
ShadowsocksProxy Protocols
An early widely-used encrypted proxy protocol with a simple structure and low handshake overhead. Configuration needs only server address, port, password, and encryption method. Low on resource usage, it runs reliably on older devices and routers, and remains a common sight in subscriptions today.
VMessProxy Protocols
A protocol designed by the V2Ray project, featuring user-ID authentication and time validation, with richer features than Shadowsocks and support for transports like WebSocket and TLS. Note: a clock offset of more than 90 seconds on your device will cause connections to fail outright — check system time first when troubleshooting.
TrojanProxy Protocols
A protocol that disguises proxy traffic as standard HTTPS, behaving almost identically to normal web browsing. It requires a valid TLS certificate, has few configuration options and a lightweight implementation, and delivers top-tier speed and stability.
VLESSProxy Protocols
A streamlined successor to VMess that drops built-in encryption entirely, delegating it fully to the TLS layer for lower overhead. Often paired with newer transports like REALITY and XTLS. In the Clash ecosystem, it requires the mihomo core.
Hysteria2Proxy Protocols
A next-generation protocol built on QUIC (UDP) that uses custom congestion control to push more speed out of lossy connections. The improvement is especially noticeable over long distances or on poor networks; the trade-off is that some networks throttle UDP, in which case a TCP-based protocol is the fallback. Requires the mihomo core.
TUICProxy Protocols
Also built on QUIC, this lightweight protocol focuses on 0-RTT fast handshakes and multiplexing. It reconnects quickly when switching between Wi-Fi and mobile data, with a simpler configuration than Hysteria2. Supported only by mihomo-family cores.
Cores & Clients
The core does the heavy lifting; the client gives you the interface. Once you separate the two layers, questions like "which app should I use" and "which protocols does it support" both get easier to answer.
mihomoCores & Clients
The de facto mainstream core in the Clash ecosystem today, continuing the work of the Clash Meta project. Built on top of the original core, it adds support for newer protocols like VLESS, Hysteria2, and TUIC plus more rule types. It's the core built into mainstream clients like Clash Verge Rev and FlClash.
Original Clash CoreCores & Clients
The original core program of the Clash project, which defined the YAML config format and rule-based routing model. After maintenance stopped in 2023, all new protocols and features have gone into mihomo instead. Older tutorials referring to "the Clash core" usually mean this one; configs are broadly compatible, but newer fields simply won't work.
Clash Verge RevCores & Clients
The leading desktop Clash client for Windows, macOS, and Linux, a community-maintained fork that took over after Clash Verge stopped receiving updates. It comes with the mihomo core built in, along with subscription management, a TUN mode toggle, and system proxy takeover. On Windows it depends on the WebView2 component — check that first if installation fails.
FlClashCores & Clients
A cross-platform client built with Flutter, offering one unified interface for both desktop and Android. It also comes with mihomo built in and works out of the box, with an interface that's friendly to newcomers. The workflow stays consistent between mobile and desktop, so switching devices means no relearning.
Config File Fields
Those top-level fields you see when opening config.yaml. Once you understand them, error messages that reference a specific field become easy to trace back.
YAMLConfig File Fields
The text format used by Clash config files, which relies on indentation to express structure. There's really only one hard rule: indentation must always use spaces — a single tab character is enough to break parsing of the whole file. Before editing, make sure your text editor isn't set to auto-convert indentation to tabs.
mixed-portConfig File Fields
A mixed listening port that accepts both HTTP and SOCKS5 proxy requests on the same port, commonly defaulting to 7890. It's an alternative to using separate port and socks-port fields — new configs only need mixed-port, and both the system proxy and command-line tools can point to it.
proxiesConfig File Fields
The node list field; each entry describes a proxy server: name, type, address, port, and protocol parameters. Updating a subscription is essentially refreshing this list. When adding nodes manually, keep names unique — a duplicate name will silently overwrite the earlier one.
proxy-groupsConfig File Fields
The proxy group field, which organizes the nodes from proxies by purpose and defines selection logic. A matched rule doesn't point directly at a node — it points to a proxy group first, and that group's own logic decides the final exit node. The "switch node" option in a client's UI is really editing this field.
Subscription LinkConfig File Fields
A URL provided by a service that returns a complete node configuration when visited. The client re-fetches it on a schedule or on demand, and the node list updates automatically as a result. The link itself functions like an account credential — never paste it into a public chat or leave it visible in a screenshot.
Rules & Routing
The rules list is checked top to bottom and stops at the first match — remember that one line, and the next five terms all build on it.
Rule Mode (mode: rule)Rules & Routing
One of Clash's three run modes, and the one recommended for everyday use: traffic is checked against the rules list from top to bottom, stopping at the first match. The other two are global (everything through the proxy) and direct (everything bypasses it), mainly useful for quick troubleshooting — just remember to switch back afterward.
DOMAIN-SUFFIXRules & Routing
A rule type that matches by domain suffix — for example, DOMAIN-SUFFIX,youtube.com matches youtube.com and all of its subdomains. It's the most commonly seen rule type in any rule list. Note that it only matches the suffix, not any domain that merely contains that string.
GEOIPRules & Routing
A rule type that matches by the geographic location of the target IP, with the most common pattern being GEOIP,CN,DIRECT — routing mainland China IPs directly. It relies on a local GeoIP database, and an outdated database can misclassify a handful of addresses; this rule is usually placed near the end of the list as a fallback.
MATCHRules & Routing
The final catch-all rule in a rule list, matching any traffic that didn't match anything above it. Without it, unmatched traffic's fate becomes unpredictable. When reviewing a config, check whether the last line is MATCH, then check which proxy group it points to.
url-test and selectRules & Routing
The two most commonly used proxy group types. url-test periodically sends requests to a test URL and automatically picks the lowest-latency node; select is fully manual — whatever you pick is what gets used. Use url-test for smooth streaming, and select to lock in a fixed node for IP-sensitive logins.
Run Modes & Networking
"Why isn't my traffic going through the proxy even though it's on" — the answer is almost always hiding in these five terms.
System ProxyRun Modes & Networking
A proxy setting at the operating system level, applied by the client with one click. Well-behaved apps like browsers will respect it, but many command-line tools, games, and some client software will ignore it entirely. That kind of traffic needs either separate environment variables or TUN mode to take over.
TUN ModeRun Modes & Networking
A mode where the client creates a virtual network adapter to intercept all traffic at the network layer, without relying on apps cooperating. It covers far more ground than a system proxy — command-line tools and games all get routed through it. Enabling it requires administrator or system extension authorization; use either this or the system proxy, never both at once.
Fake-IPRun Modes & Networking
A DNS handling strategy: the client first returns a fake IP from a reserved range, deferring the real resolution until traffic is actually sent. This saves a DNS round trip, speeds up connection setup, and helps avoid DNS pollution. A handful of LAN apps that depend on real IPs may misbehave — these can be excluded with fake-ip-filter.
DNS LeakRun Modes & Networking
A situation where domain resolution requests still go out directly over the local network even with the proxy on. The content itself goes through the proxy, but which domains you've looked up gets exposed to the local network. Combining TUN mode with Fake-IP is a common fix — verify it afterward with an online DNS leak test page.
Node LatencyRun Modes & Networking
The response time, in milliseconds, measured when the client sends a request to a test URL. It reflects the full path from your device through the node to the test server, not the raw performance of the node itself. If every node times out, don't blame the nodes first — check subscription expiration, system clock, and port conflicts in that order.
Done looking up terms? Two paths from here: if you understand the concepts but haven't tried it yet, head to the tutorial page and start with importing a subscription; if you're stuck on a specific error, check Troubleshooting first — chances are it's already answered. Haven't installed a client yet? Go straight to the client download page and grab the installer for your platform.