26 frequently used terms, sorted into five categories. Each entry is 2-4 sentences—get the concept down, then head to the setup guide or advanced handbook to try it out.
The protocol determines how a node communicates with its server. Which protocols appear in a subscription is up to the provider—the client side just needs a core that supports them.
A lightweight encrypted proxy protocol, often abbreviated SS. Simple in design and low in overhead, it's natively supported by Clash and the mihomo core, making it one of the most common protocols in subscriptions. A node name containing "SS" usually refers to this.
An encrypted transport protocol designed by the V2Ray project, relying on time sync between client and server for authentication—a large clock drift can cause connection failures. Configuration is more complex than Shadowsocks, with support for WebSocket, gRPC, and other transport disguises.
A protocol that disguises proxy traffic as standard HTTPS traffic, relying on a real domain and TLS certificate. Because its traffic pattern closely resembles ordinary browsing, it's harder to detect. All Clash-family cores support it, and its fewer config fields make troubleshooting easier.
A streamlined successor to VMess that drops the built-in encryption layer, usually paired with TLS or Reality for security. The original Clash core doesn't support it, but the mihomo core does—if your subscription has VLESS nodes, make sure the client runs the newer core.
A QUIC-based proxy protocol with congestion-control tuning for high-loss, high-latency networks, giving noticeably better throughput on weak connections. Only newer cores like mihomo support it—discontinued clients (like Clash for Windows) simply ignore these nodes.
The mode decides how traffic flows overall; proxy groups decide exactly which node handles it. Understand these two layers and the switches on the client's home screen stop being mysterious.
Clash's default working mode: every connection is checked against the rules section entry by entry, and whichever rule it matches determines direct or proxy routing. Keep RULE mode for everyday use—how well it splits traffic depends entirely on rule quality.
Skips all routing rules and sends every connection through one selected proxy exit. Handy for briefly checking "is this a rule problem or a node problem," or when all traffic genuinely needs the proxy for a while. Leaving it on long-term also detours domestic sites, slowing things down.
All traffic bypasses the proxy and goes out directly from the local network—effectively "turning off" the proxy without quitting the client. Switching to DIRECT to compare results is one of the fastest ways to bisect a network issue.
Organizes multiple nodes into a selectable group. Common types include manual select, automatic url-test, fallback, and load-balance. Rules usually point to a proxy group rather than a single node, so switching nodes just means switching within the group—no rule edits needed.
The client sends requests to a specified test URL and measures the response time in milliseconds to gauge node speed. A url-test proxy group periodically re-tests and automatically picks the lowest-latency node. Note that low latency means fast response, not necessarily high bandwidth.
Rules are matched top to bottom, and the first match wins. Understanding matching order is the first step to figuring out why a site isn't going through the right exit. See real-world examples in the advanced handbook's rule-routing chapter.
The mechanism that routes different traffic to different exits based on domain, IP location, process name, and similar conditions—Clash's core capability beyond a simple proxy tool. A typical setup routes domestic sites directly and overseas sites through the proxy, balancing speed and reachability.
A rule type that matches by domain suffix: matching one root domain covers all its subdomains too. It's the most frequently used matcher for custom rules. Related types include exact-match DOMAIN and keyword-match DOMAIN-KEYWORD, ranging from narrow to broad in scope.
A rule type that matches based on a geolocation database of the destination IP, most commonly used to route mainland China IPs directly. Since domain resolution must complete first to get an IP, GEOIP rules usually sit after all domain-based rules, avoiding unnecessary resolution overhead.
A catch-all rule matching any traffic not caught by earlier rules, and it must be the final entry in the rules section. It determines the default destination for unknown traffic—pointing it to a proxy group means "unknown goes to proxy," pointing to DIRECT means "unknown goes direct."
A mechanism that spins large sets of rule entries into external files, referenced by the config and updated automatically on a schedule. Community-maintained rule sets often cover tens of thousands of domains—one reference line replaces hours of manual maintenance. The mihomo core has the broadest format support.
The core handles the actual proxying and routing; the client is the GUI wrapped around it. Telling the two apart makes it easier to know which side "owns" a given feature. See a side-by-side comparison in our client comparison.
The open-source core the community continued after the original Clash core was archived, formerly known as Clash Meta. Nearly every active GUI client today runs mihomo under the hood, and it supports newer protocols like VLESS and Hysteria2 plus richer rule types—the de facto standard core today.
An open-source desktop client built on the mihomo core, covering Windows, macOS, and Linux. The community took over maintenance after the original Clash Verge stopped updating, adding TUN mode and subscription management—one of the leading desktop options today.
A multi-platform client covering iOS, Android, Windows, and macOS; the iOS version is distributed through the App Store, with clashplus.io as its official site. It gives phone and computer the same operating logic—handy for multi-device users. See installers on the download page.
A method that creates a virtual network adapter on the operating system to capture all network traffic, covering apps that ignore system proxy settings (CLI tools, some games, etc.). Enabling it usually requires administrator or system extension permissions—just follow the client's prompt the first time.
The client writes its listening port into the OS's proxy settings, so browsers and other apps that respect that setting route through it automatically. It's the most common and least disruptive way to take over traffic; apps that ignore the system proxy need TUN mode to fill the gap.
Between getting a subscription link and having rules take effect lie two steps: the config file and DNS. This group covers the concepts you'll run into most often when importing a config.
A single usable proxy server record in the config, containing address, port, protocol, and authentication details—corresponding to the proxies section. After importing a subscription, nodes appear in proxy groups for manual selection or automatic speed testing.
A URL provided by a service that the client periodically fetches to get the latest nodes and rules; refreshing the subscription syncs any changes. A subscription link functions as an access credential—don't screenshot or paste it anywhere public. See import steps in the setup guide.
The process of converting node subscriptions in other formats into Clash-readable YAML config, done via an online conversion service or a client's built-in feature. It usually applies a rule template during conversion too, producing a ready-to-use config in one step. With third-party services, the subscription data passes through their servers—weigh that trade-off yourself.
The config file format Clash uses, expressing hierarchy through indentation, mainly containing port, DNS, proxies, proxy-groups, and rules sections. Wrong indentation width or mixed-in tabs is the most common cause of a config failing to load; the line number in the error message is where to start looking.
A DNS handling strategy: a domain is first given a virtual IP from a reserved range so the connection can start immediately, with the real address resolved by the core as needed. This skips DNS wait time and avoids tampered results; a few LAN apps that depend on real IPs may need to be added as exceptions.
Refers to traffic going through the proxy while domain resolution requests are still sent in the clear from the local network, letting observers see the destination. Enabling core DNS takeover or Fake-IP mode prevents it; you can self-check for leaks with a public DNS leak test page.