First identify whether a term belongs to protocols, rules, configuration, the core, or network resolution. Then determine whether it affects connection setup, traffic routing, or client operation. This guide explains common terms and highlights boundaries that are easy to confuse.
The “client” is the control interface, while the “core” handles the actual connections. A “subscription” is a configuration source, and a “node” is just one type of connection parameter. A “policy group” determines the available paths, while a “rule” determines which policy handles a connection. When something fails, checking these layers in order is more effective than repeatedly switching nodes.
A protocol name describes the connection mechanism; it does not directly indicate speed or stability. Real-world performance is also affected by the server implementation, network path, TLS parameters, client core version, and DNS configuration. For a closer comparison of protocols and cores, see Protocol and Core Technical Reference.
The protocol determines how the client and server establish a connection, authenticate identities, and transfer data. Before choosing one, confirm that the protocol supplied by the subscription is recognized by the current core.
A relatively simple encrypted proxy protocol. Nodes typically include a server address, port, password, and encryption method; a mismatch in any field can cause the connection to fail. Encryption methods supported by different cores may vary, so check compatibility before migrating a configuration.
A protocol in the V2Ray ecosystem. Common configurations include a user ID, transport method, TLS, hostname, and path. VMess nodes with the same name may use different transport combinations. If importing fails, check both the protocol fields and outer transport parameters such as WebSocket or gRPC.
A proxy protocol built on TLS connections. Common configurations include the server address, port, password, domain, and certificate options. The domain, SNI, and certificate-verification settings must correspond. Disabling certificate verification alone cannot fix an incorrect address, port, or password.
A lightweight protocol whose security is usually provided by outer mechanisms such as TLS or Reality. When importing it, do not check only the VLESS name; also verify the transport type, flow control, server name, public key, and other parameters. Older Clash cores may not recognize some extension fields.
A QUIC-based protocol designed for high-latency or unstable networks. It uses UDP as its underlying transport, so the network, firewall, and server must allow the relevant traffic. Also confirm that the client uses mihomo or another compatible core that supports Hysteria2.
A QUIC-based proxy protocol. Configurations commonly involve user credentials, congestion control, and TLS parameters. When a mobile device switches between Wi-Fi and cellular networks, recovery speed depends on the core implementation and server settings. The same protocol name does not guarantee identical options across clients.
Rules determine where a connection goes; policy groups provide the available paths. When troubleshooting routing errors, first check whether a rule matched, then inspect the current selection in the matched policy group.
Routes connections to different policies based on domains, IP addresses, ports, processes, or rule sets. Rules are usually checked from top to bottom and stop after the first match. A broad rule placed too early can hide more precise rules below it.
A selection unit made up of multiple nodes or other policies. Common types include manual selection, automatic testing, and failover; exact names are defined by the configuration author. Rules usually reference policy-group names, so renaming one requires updating related rules.
Indicates that a connection reaches its destination directly without using a proxy node. It is commonly used for LAN addresses, system services, or explicitly direct domains. A DIRECT match does not guarantee success; the destination, DNS result, and local network can still affect access.
Rejects connections that match the conditions instead of sending them through a proxy node or direct path. It is useful for domains or requests that are known to be unnecessary. Overly broad rules may block application APIs, so check matching entries in the logs after making changes.
A dataset mapping IP address ranges to regions or network categories. GeoIP rules process the destination IP, so results depend on DNS resolution and database freshness. Missing databases, incorrect paths, or unsupported category names can prevent rules from loading.
A collection of domain rules organized by site category, reducing the need to maintain large numbers of domains manually. Available categories depend on the data file and core support. Category updates may change existing rule names, so review the loading logs when refreshing data.
Subscriptions solve the problem of obtaining configuration; configuration files describe how the client runs. A subscription being updateable does not guarantee compatibility—the current client and core must still validate the result.
A remote configuration endpoint published by a service provider. The client uses the subscription URL to fetch nodes, policy groups, or a complete configuration. Updating a subscription usually rereads the remote content and may overwrite manual changes. Before editing rules, confirm whether the client merges or replaces the configuration.
A set of server parameters that lets a client establish a proxy connection. The protocol, address, port, authentication details, and transport options together determine whether a node works. A successful latency test only confirms that the test connection worked; it does not guarantee that every destination or protocol will work.
A configuration mechanism for loading node collections from external files or remote URLs. A Provider can be reused by multiple policy groups and updated at a configured interval. If the Provider downloads successfully but the policy group is empty, check the filters, node format, and referenced name.
A structured text format commonly used for Clash configuration, with strict requirements for indentation, hierarchy, and punctuation. List items usually begin with a hyphen, and keys must be separated correctly from values. Tabs, full-width punctuation, or inconsistent spacing can all cause parse errors.
A complete file describing ports, nodes, policy groups, rules, DNS, and runtime options. The same YAML file may not be equally compatible across different cores. Before importing, keep the current working configuration and use the client logs to confirm that the new file loaded successfully.
The graphical interface handles operation; the core handles execution. Similar client names do not necessarily mean identical core versions, configuration extensions, or system-integration methods.
The core program responsible for protocol connections, rule matching, DNS handling, and traffic forwarding. GUI clients typically provide subscription management, policy selection, and log views around it. To determine whether a protocol is supported, check the core's capabilities rather than only whether the client interface has an input field.
A core project evolved from Clash Meta, supporting a wide range of protocols, rules, and DNS features. Different clients may bundle different versions or follow their own update schedules. When migrating a configuration, check extension fields, rule-database formats, and the target platform architecture.
A graphical application that provides the core with subscription importing, system-proxy control, policy selection, log viewing, and update controls. The GUI determines which settings users can see, but the core still executes the underlying protocols. When choosing a client, compare operating-system support, core type, and configuration compatibility.
A runtime mode that takes over traffic through a virtual system network interface and can cover some applications that ignore system proxy settings. It may require system permissions and can be affected by routing tables, DNS hijacking methods, and other network software. If the network goes down, disable TUN first, then check core logs and the virtual-adapter status.
Points the operating system's HTTP or SOCKS proxy settings to Clash's local listening port. It works only with applications that follow system proxy settings; some games, command-line tools, and apps with independent network stacks may bypass them. For broader coverage, consider TUN mode instead.
Domain resolution usually happens before a connection is established, followed by rule matching and protocol negotiation. An incorrect DNS path often appears as a working node that cannot reach a particular domain.
The basic service that converts domain names into network addresses. Clash can forward, cache, or rewrite DNS requests according to its configuration and use domain rules for routing. When troubleshooting resolution, check system DNS, browser secure DNS, and core DNS separately rather than changing only one layer.
A DNS enhancement mode in which the core first returns a reserved address and records the domain mapping, then restores the real destination domain during the subsequent connection. It preserves domain information and enables earlier rule matching. Some LAN devices or applications that require real addresses need to be excluded.
A situation where an application's DNS request bypasses the expected DNS path and is handled by another resolver. Common causes include browser-level secure DNS, stale system DNS settings, or incomplete TUN coverage. Check which resolver actually received the request instead of only checking whether the webpage opens.
Accepts both HTTP and SOCKS proxy connections on the same local listening port, allowing different applications to use one port configuration. To expose it to other LAN devices, also verify the bind address, LAN-access setting, and system firewall. If another program already uses the port, the core will usually report the bind failure in its logs.
The process of connecting to a specified test address and recording the response time. The result reflects the connection at that moment, to that target, over the current network path; it does not equal download speed or sustained throughput. Compare nodes with the same test address and use real access results as well.