26 high-frequency terms sorted into five categories: kernel, protocol, rules, subscription, and DNS each get their own section, with every entry explained in a few sentences covering meaning, usage, and common pitfalls. Hit an unfamiliar word in a guide or the handbook? Come back to this page and look it up.
What's actually running under the hood and how traffic gets captured — start with these
The continuation of the Clash Meta project after its rename, now built into Clash Verge Rev, FlClash, Clash Plus, and pretty much every other mainstream client. It handles protocol handshakes, rule matching, and traffic forwarding — the engine of the whole system. Newer protocols like VLESS and Hysteria2 only work if the client runs mihomo, so check the core first when picking a client.
The earlier closed-source Clash core, once the default engine for Clash for Windows. It stopped receiving updates in 2023 along with the original project and no longer supports newer protocols or rule types. When old configs mention Premium-only features, mihomo almost always has an equivalent or improved version of the same thing.
A working mode that creates a virtual network adapter on the system, pulling all network traffic into the core for processing. Command-line tools, games, and other apps that ignore the system proxy can only be covered by TUN. Enabling it for the first time usually requires administrator rights or installing a system service — check this step first if it won't turn on.
A mode that points the operating system's HTTP/SOCKS proxy settings to Clash's local listening port (commonly 7890/7897). Software that respects the system proxy, like browsers, routes traffic automatically; apps that don't respect it are completely bypassed and need TUN mode or a manually specified proxy to cover the gap.
A local RESTful API exposed by the core, written as external-controller in the config, listening on a port like 9090 by default. Client panels and web dashboards both rely on it to read the node list, switch proxy groups, and view connections and logs. If the panel goes blank, check whether this port is occupied or has been changed.
What's behind that string of protocol names in your subscription — one section covers them all
An entry in the proxies section of a config file, containing fields like server address, port, protocol type, and password — the smallest unit of a traffic exit point. The region label in front of a node's name is just something the provider chose to call it; treat actual location as something to be verified by testing.
A long-standing encrypted proxy protocol with a simple structure and low transmission overhead, needing only a server, port, cipher, and password to configure. It's supported across the entire Clash client family, often shows up as the baseline protocol in subscriptions, and has a solid reputation for stability.
A native protocol from the V2Ray ecosystem, using a UUID as its credential and often layered with WebSocket and TLS. It has quite a few more fields than Shadowsocks and is usually delivered automatically via subscription rather than filled in by hand, since it's easy to miss a parameter; it's also sensitive to system clock drift, so sync your clock first if it won't connect.
A protocol that disguises proxy traffic as standard HTTPS access, relying on the server holding a valid TLS certificate so its handshake looks almost identical to visiting an ordinary website. It has few config fields and a quick learning curve, making it a common pick where a low profile matters.
A newer QUIC-based protocol built for throughput on high packet loss, long-distance links — maxing out bandwidth for video is its strong point. Only the mihomo core recognizes this type of node; clients still stuck on the older Premium core will just report it as unsupported.
A client feature that sends a request to a test URL (commonly Google's generate_204) and measures response time in milliseconds. The number reflects handshake round-trip time, not bandwidth; a timeout doesn't mean the node is definitely dead either — it could just be the test URL getting blocked on the node's side, so try a different test URL.
Which traffic goes through the proxy and which goes direct — this section decides it
Clash's signature capability: every connection is matched top-to-bottom against the rules section, stopping and executing the matched action on the first hit. Order equals priority — putting specific rules before broad ones is how you get precise control, like direct routing inside mainland China and proxying everything outside it.
The most common domain suffix matching rule: write DOMAIN-SUFFIX,example.com,PROXY and that domain plus all of its subdomains will match. Use DOMAIN for an exact single domain, and DOMAIN-KEYWORD for fuzzy keyword matching — mix all three as needed.
A rule type that matches based on where a target IP's location falls in a geographic database, with the classic form GEOIP,CN,DIRECT sending all mainland China IPs direct. The database is a separate file distributed with the core; if it's too outdated it will misjudge, so remember to refresh it alongside client updates.
A mechanism that bundles multiple nodes into one selectable group: select for manual picking, url-test to auto-pick the fastest, fallback to step in when things fail, and load-balance to spread traffic. Rule exits typically point to a proxy group rather than a specific node, so switching nodes only means changing the group's selection — no need to touch a single rule line.
A mechanism that splits tens of thousands of rules into separate remote files, referenced by name in the main config, with scheduled auto-updates via interval. Nearly every large routing setup is organized this way, letting the main config shrink to a few dozen lines and letting rule maintenance happen without touching the main file at all.
The final catch-all rule in the rule list — any traffic that didn't match anything above lands here. Whether the catch-all points to PROXY or DIRECT decides the default destination for unknown traffic; if traffic is mysteriously taking the wrong exit, check where MATCH is pointing first.
Where nodes come from and what the config looks like — this section covers the supply chain
A single URL provided by a service, which the client fetches to auto-generate a full node list and config, and can refresh on a schedule. This is the standard way most users get their nodes; a subscription URL is effectively a login credential, so don't paste it anywhere public.
The text format used by Clash config files, expressing hierarchy through indentation and separating keys from values with a colon and a space — it's extremely sensitive to whitespace. Getting an indent wrong or dropping a space by even one character when editing by hand can make the entire file fail to load; run it through a YAML validator before importing to save a lot of debugging time.
A service or tool that converts node links or subscriptions in other clients' formats into Clash-readable YAML, and can even attach a ready-made routing rule template while it's at it. The process handles your node info directly, so prefer a self-hosted instance or one with a verifiable community reputation instead of tossing it into a random online service.
The unit for managing a complete config inside a client: multiple profiles can be saved at once and switched with one click. Updating a subscription is, at its core, just refreshing the currently active profile; users with several providers can keep one profile per provider without any conflicts, which also makes it easier to pinpoint which config is causing an issue when troubleshooting.
Where resolution goes and whether it leaks — half of the tricky bugs live in this section
A situation where the proxy is on but domain resolution requests still go straight to the local ISP's DNS, exposing what's actually being visited. The usual fix is enabling Clash's built-in DNS paired with Fake-IP or TUN mode; run an online DNS leak test page to confirm whether it's actually plugged.
A Clash DNS response mode: it first returns a virtual IP from the reserved 198.18.0.0/16 range so the connection is established immediately, deferring the real resolution until after rule matching. The upside is faster first-byte time and naturally avoiding DNS poisoning; a handful of apps that need the real IP don't cope well and can be excluded via fake-ip-filter.
The two upstream groups in Clash's DNS section: nameserver handles day-to-day resolution and is usually filled with fast local DNS, while fallback steps in when results look poisoned, typically filled with DoH/DoT encrypted DNS to keep resolution accurate for sites outside China. Each has its own job — don't dump every encrypted DNS entry into nameserver, since that just slows resolution down.
A DNS mode opposite to Fake-IP: it gets the real resolution result first, then connects by IP. It's more compatible but slower on the first packet and more exposed to poisoned results, so newer configs rarely use it anymore. When migrating an old config that has weird resolution issues, switching to Fake-IP mode usually fixes things right away.
A node's and protocol's support for UDP traffic, which voice calls, online gaming, and video conferencing all heavily depend on. When a node doesn't have UDP enabled, the typical symptom is connecting fine but with no audio, or heavy packet loss in games; check that the udp field is set to true in the node config, or just switch to a node explicitly marked as UDP-supporting.
Terms just get you in the door — here's where to actually put them to use