Glossary / Configuration Reference

Clash Glossary: Core, Subscriptions & Rules

First, understand how traffic enters the client; then see how rules select an outbound route. This guide covers 25 common configuration terms, each with its own linkable URL anchor. For hands-on help, see the Getting Started guide or Advanced Config.

Reading path: the client intercepts traffic → rules select a proxy group → a node establishes the connection. DNS resolves domain names, while subscriptions and YAML provide configuration for each step.

Core and client

The interface, traffic entry point, and network processing each have distinct roles. An enabled toggle does not mean every app's requests are reaching the core.

Mihomo / Clash.Meta

Mihomo core

Mihomo is the core responsible for network functions such as connection handling, rule matching, proxy protocols, and DNS. It was previously known as Clash.Meta. Clash Verge Rev provides the graphical interface, while the core processes network requests. Treat the client's features and the core's capabilities as separate. When troubleshooting configuration compatibility, first check which core is running and which fields it supports—not just the client name.

Explore core configuration →

Client

A client is an application for managing configuration, proxy groups, connection records, logs, and system settings. Clash Verge Rev is a desktop GUI client. The client, core, and remote proxy service are three distinct components: the interface manages settings, the core handles connections, and the remote service provides the proxy endpoint. After installing the client, import a compatible configuration and select the right proxy group to establish the connection you expect.

Clients and platforms →

System Proxy

System proxy

The system proxy registers a local proxy address and port with the operating system, allowing apps that follow this setting to send requests to the client. It does not capture all network traffic: some command-line tools, games, and apps that manage their own networking may ignore the system proxy. If a browser works but another app connects directly, check that app's proxy settings first, then consider whether TUN mode is needed.

TUN Mode

TUN mode

TUN mode uses a virtual network interface and routing settings to send eligible traffic to the core. It is useful for apps that ignore the system proxy. Rules still determine whether connections go direct or through a proxy; enabling TUN does not send every connection through a proxy endpoint. TUN typically requires system permissions or service support. If another VPN is running, check for routing or DNS conflicts.

Mixed Port / mixed-port

Mixed port

A mixed port accepts HTTP and SOCKS proxy connections on the same local listening port. In YAML, it is configured with mixed-port; Clash Verge Rev commonly uses 7897. The port number is not fixed, so update any apps where you entered it manually if you change it. Check separately for a port already in use, an incorrect listening address, and LAN access that has not been allowed.

Proxy protocols

A protocol defines how the client communicates with the server. Its parameters must match the server; the protocol name alone says nothing about speed or reliability.

Proxy Node

Proxy node

A node is a set of remote proxy connection parameters the core can use, typically including a server address, port, protocol, and authentication details. Its display name is just a label. A successful connection to a node does not guarantee access to every website; rules, the outbound network, and the destination service also matter. Latency results depend on the test target and method. They cannot be directly converted into download speeds or guarantee that an actual request will succeed.

Shadowsocks / SS

Shadowsocks

Shadowsocks establishes a proxy connection using an agreed encryption method and key. It is typically represented in configuration as type: ss. The server, port, encryption method, and password must all match. If the service requires a plugin, its type and settings matter too. If the connection fails after import, compare the configuration with the original details from your provider instead of changing the encryption method at random.

VMess

VMess is a proxy protocol that authenticates using a user ID and can be used with different transport methods and TLS settings. Node details may include more than a user ID: path, Host, server name, and other transport parameters can all be required. Missing any of them can cause a handshake failure. Check the system time as well, so a time-related authentication issue is not mistaken for a port problem.

VLESS

VLESS authenticates using a user ID and related information, but the protocol itself does not provide transport encryption. Connections typically also depend on TLS, REALITY, or other transport settings. The server name, public key, and transport path required by the server cannot be inferred from the protocol name alone. Before importing, confirm that the current core supports the complete node configuration; changing type does not convert one protocol into another.

Trojan

Trojan typically carries proxy traffic over a TLS connection and uses a password for authentication. A reachable server address only suggests that the network path may be available; the password, server name, and certificate validation must still be correct. For certificate errors, check the system time, domain name, and server certificate first. Disabling certificate verification is not a routine fix.

Rules and proxy groups

Rules decide where a connection goes; proxy groups decide which outbound option to use. Check the matched rule first, then the selection within its group.

Rule-based Routing

Rule-based routing

Rule-based routing directs connections to a direct, reject, or specified proxy group action based on domains, IPs, ports, or other conditions. In rule mode, rules are usually checked from top to bottom, and the first match determines the action. More specific rules generally belong above broader ones. If a website uses an unexpected route, check the connection log to see which rule matched before changing the order. Simply switching nodes may not change the routing result.

How to manage rules →

Proxy Group / proxy-groups

Proxy groups

A proxy group organizes nodes or other groups under a name that rules can reference. The group type determines how options are selected: select lets you choose manually, url-test selects based on configured tests, and fallback uses available options in order. The group name in a rule must match the configuration. Test results apply only to the configured target and network conditions at the time of testing.

DOMAIN-SUFFIX

Domain suffix rules

DOMAIN-SUFFIX matches a specified domain and its subdomains. For example, DOMAIN-SUFFIX,github.com,PROXY can match github.com and its subdomains, provided the configuration includes a PROXY group. This is not a general substring match: an unrelated domain containing the same text will not match just for that reason. To match one exact domain, use DOMAIN.

GeoIP / GEOIP

GeoIP

GeoIP matches connections by the geographic category associated with an IP address in a database. For example, GEOIP,CN,DIRECT sends matching destinations direct. Results depend on the actual destination IP and the local database, not company registration, or visitor location. Websites using a CDN may resolve to different addresses; if routing looks wrong, check both the DNS result and database updates.

MATCH

MATCH catch-all rule

MATCH has no additional domain or IP condition and catches connections that did not match earlier rules. It is usually placed on the last line of rules. MATCH,PROXY sends remaining traffic to the group named PROXY; it does not automatically pick a particular node. If placed earlier, it will usually prevent later rules from handling those connections.

DNS and networking

DNS resolution, traffic interception, and proxy routing are separate steps. First identify where a request originates, then check whether it follows the expected route.

Domain Name System

DNS

DNS resolves domain names to IP addresses and other records, usually before a connection to a website is made. Client DNS settings cover the listening address, upstream resolvers, request routing, and caching. Entering a resolver address does not mean every app will use it. When troubleshooting, distinguish between “no DNS result” and “the connection fails after an address is returned”; each points to different logs and fixes.

Fake-IP

Fake-IP mode returns a virtual address to an app and keeps a mapping between that address and the original domain in the core. When the related connection reaches the core, it can be handled using the domain. This helps preserve domain information, but depends on both DNS resolution and the connection following the correct route. Enabling DNS mode alone is not enough if traffic is not intercepted. For LAN services or apps that require a real IP address, configure exclusions based on the issue at hand.

DNS Leak

DNS leak

A DNS leak occurs when queries take a different route from the one you expect and reach an unintended resolver. Seeing the name of a resolver in a particular region does not, by itself, mean there is a leak. In-app encrypted DNS, system resolver settings, other VPNs, and routing rules can all affect where queries go. Check the test conditions, client logs, and app settings. First establish which resolver should handle the query, then verify the actual route.

Sniffing / sniffer

Domain sniffing

Domain sniffing attempts to infer the destination domain from information visible in the initial connection data, such as some HTTP request details or TLS handshake information, to help with rule matching. It does not decrypt arbitrary HTTPS content, and it cannot identify every connection. If sniffing causes unexpected routing, check the settings for the specific destination and its override rules rather than enabling broader sniffing for all connections.

DNS Hijack / dns-hijack

DNS hijacking

In a client TUN configuration, DNS hijacking usually means redirecting qualifying traditional DNS requests to the core's resolver for centralized handling. Here, the term describes a configuration feature—not malicious tampering with DNS responses on a public network. Redirecting traditional DNS traffic does not necessarily affect DoH or DoT requests sent directly by an app, so check the app's own DNS settings as well.

DNS and TUN settings →

Subscriptions and configuration files

Subscriptions distribute configuration, YAML describes it, and local overrides preserve your changes. After fetching a subscription, make sure its configuration is enabled.

Subscription

Subscriptions

A subscription distributes a list of nodes or a complete configuration through a link. The client fetches the content from that link, but subscriptions can return Clash YAML, an encoded node list, or another format. A link that opens successfully is not necessarily usable by your client as-is. Subscription URLs may contain private access credentials; hide the full link before sharing logs or screenshots so others cannot use the same access.

How to import a subscription →

YAML

YAML configuration

YAML uses indentation to represent mappings, lists, and nested structures. Clash configurations commonly use it for sections such as dns, proxies, proxy-groups, and rules. Indent with spaces and align items at the same level; list-item hyphens are part of the structure, not decoration. A file that parses successfully may still use fields unsupported by the current core. After saving, check the configuration validation results and runtime logs.

Subscription Conversion

Subscription conversion

Subscription conversion reformats source nodes or a configuration so a target client can read them. It may also use a template to generate proxy groups and rules. Conversion cannot fill in missing server parameters or make an unsupported protocol compatible. Online services may access your original subscription URL and node credentials, so verify the service before using it. Subscriptions already in a compatible format can usually be imported directly.

Local Override / Merge

Local overrides

Local overrides apply changes on top of a subscription configuration, making it easier to keep custom DNS, rules, or other settings without re-editing them after each update. Features may merge fields, replace lists, or process scripts differently; do not assume every list is automatically appended. Keep a copy of the original before editing, then check the effective configuration—especially rule order, proxy group names, and list contents.

Subscription Update

Subscription updates

A subscription update fetches remote content again and may change node parameters, proxy groups, or rules. Updating is not the same as switching the active configuration. Downloading, parsing, enabling a configuration, and reloading the core are separate steps; check them in order if something goes wrong. Set the update interval based on your provider's recommendations and your needs. If connections fail after an update, check whether node names changed and whether local overrides still reference valid names.