Kernels, protocols, routing rules, DNS, and subscriptions. Look up terms used in configuration files and tell apart settings with similar names but different roles.
26 terms5 topicsDirect links
New to configuring Clash? Start with the Clash setup guide. To compare protocols and core capabilities, see the protocol reference. This page explains terminology; it does not replace setup instructions for a specific client.
CORE & CLIENT
Kernels and Clients
First, distinguish the core that handles connections from the app that provides the user interface.
Original Clash Core
Original Clash core
An early rule-based proxy core in the Clash ecosystem, responsible for establishing connections, handling DNS, and matching rules. Graphical interfaces are usually provided by other projects. The original open-source version differs from later versions of Meta and mihomo in protocol and field support, so features described in older guides may not apply to every fork. To check whether a configuration will work, identify the core type rather than relying on whether the client name includes Clash.
A core fork that expanded Clash with additional proxy protocols, rules, and networking features, later continuing development under the mihomo name. Older configuration guides, downloads, and client interfaces may still use the Meta label. It usually refers to the core lineage, not a specific desktop app. If a feature guide only says Meta, check support against the exact core version.
A rule-based proxy core descended from Clash Meta, with support for multiple proxy protocols, rule sets, and DNS features. It can be used through a graphical client or run as a standalone program on a server or router. Client and core versions may not match, so check the running core version and build to confirm that a setting will take effect.
An app with an interface for importing subscriptions, selecting policies, viewing logs, and integrating with the system, such as Clash Verge Rev. The client organizes user actions; the core handles connections. They are not the same thing. Settings may be in different places across clients using the same core, and client-generated overrides can make the active configuration differ from the original subscription.
Uses the operating system's proxy settings to route traffic from apps that honor them to a local HTTP or SOCKS proxy port. Some games, command-line tools, and apps with their own network stack may ignore system proxy settings, so enabling the option does not capture every connection. TUN or other traffic interception may remain active after the system proxy is disabled; check each separately.
A protocol name is only the starting point. Authentication, transport, and TLS requirements must also match.
Shadowsocks
SS
An encrypted proxy protocol whose node settings typically include a server, port, encryption method, and password. The client and server must support the same encryption method; switching between old and new methods is not as simple as changing the name. If a connection fails after import, first check the method and credentials, then verify that the current core supports UDP forwarding and any additional features.
A proxy protocol in the V2Ray ecosystem that typically uses a UUID to identify users. The system clock must also be accurate for connections to work. VMess and WebSocket belong to different layers, so preserve both the protocol identity and transport settings when importing. If the server is reachable but the handshake fails, check the system clock, UUID, path, and TLS settings instead of just renaming the node.
A proxy protocol that typically uses password authentication over a TLS connection. The server certificate and server name are part of the connection requirements. Copying only the address, port, and password may leave out essential settings such as SNI. For certificate errors, check the domain, system clock, and certificate trust chain first; disabling certificate verification is not a general fix.
A lightweight proxy protocol that uses UUID-based identities and does not encrypt content on its own. Connection security usually relies on accompanying mechanisms such as TLS or REALITY. VLESS is not tied to a particular transport, and nodes with the same name can use different combinations. When choosing a client, check that its core supports the transport, security mechanism, and related options you need.
A QUIC-based proxy protocol that requires UDP connectivity, so it may not work on networks that restrict UDP. Performance depends on packet loss, congestion, server resources, and device capabilities; the protocol name alone cannot predict speed. Hysteria v1 and v2 use different configuration types and are not directly interchangeable, so confirm the version when importing.
A QUIC-based proxy protocol that can carry TCP and UDP traffic, and likewise requires the underlying network to allow the necessary UDP communication. It is not the same protocol as Hysteria2, so its authentication fields, connection behavior, and congestion control settings cannot be reused interchangeably. Before connecting, check the server protocol version, credentials, and TLS settings, then assess performance on your current network and mobile device.
Match conditions determine which policy to use; the policy determines the actual route.
Routing Rules
Rule-based routing / rules
Select an action for a connection—such as direct, proxy, or reject—based on conditions like its domain, destination address, or process. In rule mode, rules are generally checked from top to bottom, and the first match determines what happens next. Put specific conditions before broader ones. In global or direct mode, the connection may not behave as expected from the original rules.
Groups nodes or other policies into a logical outbound that rules can reference by name. select is for manual selection; url-test and fallback focus on automatic testing and failover, respectively. Exact behavior depends on the group configuration. A rule pointing to a group does not mean all its nodes handle the connection at once.
A matching method that uses a database mapping IP addresses to regions, for example GEOIP,CN,DIRECT. An address's geographic classification in the database does not indicate where the service operator is based or where the user is located. A CDN may also return addresses associated with different regions for the same domain. DNS results, database updates, and rule order all affect matches. If you add no-resolve, make sure you understand that it skips DNS resolution.
Store a set of matching conditions in a local or remote file, define it with rule-providers, and reference it with a RULE-SET rule. Rule sets provide conditions for matching domains or addresses; they do not provide proxy nodes. The format, behavior type, update method, and core support must all be compatible. A successful download does not mean the rules are being matched correctly.
The final rule catches traffic not matched by any earlier rule and is usually placed at the end of the rules list. MATCH,PROXY sends remaining connections to the policy named PROXY, which must exist in the configuration. If MATCH appears earlier, later rules usually get no chance to match. It does not switch the client to global mode.
Traffic capture, DNS resolution, and route selection are separate steps; check each one independently.
DNS
Domain Name System
DNS resolves domain names to IP addresses and other records. Apps, the operating system, and the proxy core may all perform lookups. The destination website and the proxy server itself may use different DNS paths, and encrypted DNS does not guarantee that requests go through a proxy. When troubleshooting, check which component made the lookup, which resolver it used, and whether the result was cached.
The core returns a reserved address to the app and keeps an internal mapping between that address and the domain. Later connections use the mapping to recover the destination domain. This is not the destination server's real public IP, nor does it mean the service has been moved. For apps that rely on real DNS results, configure fake-ip-filter as needed and check the filter mode and other DNS rules rather than blaming every issue on the mapping mechanism.
Captures IP traffic through a virtual network interface and routing settings, including connections from apps that ignore system proxy settings. TUN is a way to capture traffic, not a node protocol, and captured connections do not all have to go through a proxy. Before enabling it, check permissions, routes, and DNS handling. When using another VPN at the same time, also check for route conflicts and local network access.
Identifies domain clues in the initial data of supported connections to help the core match domain rules. It does not arbitrarily decrypt HTTPS content; detection depends on the protocol, encryption, and visible handshake data. Some configurations also let you adjust the destination information used for a connection. If enabling sniffing causes compatibility issues, check the logs and related override options.
When DNS requests take a different route than intended—for example, when an app sends a request directly to another resolver instead of letting the core handle it. Whether this counts as a leak depends on the intended policy; a test page showing a particular region is not enough to draw a conclusion. Check app-specific DNS, encrypted DNS in browsers, IPv6, system resolvers, and the actual egress path. Distinguish the DNS result from the network route.
First identify the imported content's format, then check how nodes, policies, and rules reference one another.
Subscription
Subscription URL / profile
A way to distribute node information or configuration files through a URL that can be used to fetch updates. The content may be a complete YAML file or just a node list. Different formats may require a specific client import option or a trusted conversion method; a successful import does not guarantee that every protocol and rule is supported. Subscription URLs may contain credentials, so remove sensitive parts before sharing a full URL in logs or screenshots.
A set of settings for establishing a proxy connection, typically including a server address, port, protocol, and credentials. Some protocols also require transport and TLS settings. A node name is only a display label; a region or purpose in the name does not prove the actual route or connectivity. Availability also depends on the server, valid credentials, and the local network path—not simply on whether the client is installed.
The time a client takes to make a request to a specified test target. It may include connection setup, the handshake, and the response; it is not necessarily an ICMP ping. Results vary with the test address, timeout settings, and network conditions, so latency cannot be converted directly into download speed. A test timeout does not necessarily mean a node is completely unusable; check real-world connections and logs as well.
A structured text format commonly used for Clash configuration, with indentation defining hierarchy and lists and key-value pairs organizing nodes, rules, and DNS settings. Use consistent spaces for indentation, avoid tabs, and quote special characters where needed. Valid YAML syntax only means the file can be parsed; the current core still needs to check whether fields are supported and policy names exist.
A way to load and update a collection of nodes separately, from a local or remote source, then reference it from a proxy group with use. This differs from rule-providers, which supply matching conditions. A node collection is not a drop-in replacement for the main configuration. Check the data format, provider name, and update settings to avoid overwriting manually maintained configuration logic during a remote refresh.