CLASH / TERMINOLOGY

Clash Glossary
Cores, routing, and network settings

Use this glossary to identify terms in the client interface and configuration files. Each entry explains what a term means, where it is used, and what it is easy to confuse it with. Jump to one of the six categories below, from importing a subscription to troubleshooting a connection.

For a first-time setup, start with subscriptions, proxy groups, and the system proxy. For step-by-step instructions, see Getting Started.

01 / CORE & CLIENT

Cores and Clients

The interface manages settings; the core executes them. Understand the difference before checking whether a feature is supported or where a setting takes effect.

mihomomihomo core: A proxy core derived from Clash Meta that handles protocol connections, DNS, and rule matching. It is also the execution component used by several clients in the Clash ecosystem. A client's name may not include mihomo; check its settings or core information to confirm which core is in use. Check the current core version and its documentation to see whether newer protocols and fields are supported—not just the installer name.

Clash MetaClash Meta: A former project name in the Clash ecosystem for an extended proxy core, historically related to the later mihomo name. Older guides, subscription labels, and some app names still use Meta. If you see “supports Meta,” check the specific fields, protocol parameters, and core version. Do not assume every client with Clash in its name supports them.

ClientClient: The application users interact with directly, providing interfaces for subscription management, node selection, connection monitoring, and system settings. Clash Verge Rev belongs to this layer and typically manages the core through a control interface. Even clients using the same core may differ in configuration merging, permission handling, and log display, so check the interface when following instructions.

CoreCore: The software component that reads the active configuration and establishes connections, handling listening ports, DNS, and routing rules. A client update may also update the core, or the core may have a separate update option, depending on the software. When troubleshooting compatibility, record the client version, core version, and any error fields. For core lineage, see the protocol guide.

02 / PROTOCOLS

Proxy Protocols

Protocols define how a client and server communicate. Node parameters must match the server; changing the protocol name cannot convert one protocol into another.

ShadowsocksSS: A protocol that establishes proxy connections using a shared key and specified encryption method. A node typically includes the server address, port, password, and encryption method. The client must support both the node's encryption scheme and any optional plugin. If import results in an authentication or handshake error, check these parameters first; similar encryption method names do not mean they are interchangeable.

VMess and VLESSVMess / VLESS: Two distinct protocols commonly found in the V2Ray and Xray ecosystems. Configurations often include a user ID, transport method, and security layer options. VLESS does not encrypt payloads by itself, so its security also depends on outer layers such as TLS. When troubleshooting, check the protocol type as well as the WebSocket path, server name, and other transport parameters—not just the server address.

TrojanTrojan over TLS: A proxy protocol that typically protects traffic with TLS and uses password authentication, with certificate validation playing an important role in the connection. The server name is used for TLS SNI and certificate verification, and may differ from the connection address. If a certificate error occurs, check the system clock, server name, and server certificate rather than treating certificate verification bypass as a routine fix.

Hysteria2 and TUICQUIC-based Proxy Protocols: Two QUIC-based proxy protocols that typically use UDP for transport, but have different authentication parameters and congestion-control designs. UDP restrictions, mismatched server settings, or changes in route quality can all affect availability. Protocol names alone cannot predict speed or battery usage on mobile devices; compare performance on the same device, under similar network conditions, and with the same workloads.

03 / RULES & ROUTING

Rules and Routing

Rules determine which outbound handles a connection. When reviewing them, check both the match conditions and the order, as well as the policy names they reference.

Rule-Based RoutingRule-based Routing: Rules are evaluated in configuration order against conditions such as domains and addresses, then connections are sent to a direct route, a proxy group, or a reject policy. Rules are generally checked from top to bottom, and the first match determines what happens next. A broad rule placed too early can shadow more specific rules below it. Check the rule list in the client and compare actual matches on the Connections page; this often makes issues easier to pinpoint than inspecting the config file alone.

GeoIPIP-based Classification: Matches destination IP addresses against an address database by region or address category. For example, GEOIP,private,DIRECT,no-resolve can match private addresses. Results depend on the database and do not prove a server's current physical location. no-resolve prevents the rule from triggering a DNS lookup just to match, but the rule can still match when a destination IP is already available.

GeoSiteDomain-based Classification: Matches domains against sets in a database, often grouping domains for a service or category into one rule, such as GEOSITE,cn,DIRECT. The category must exist in the currently loaded data file, and its contents may vary by data source. GeoSite matches domain sets, while GeoIP matches destination addresses; they are not interchangeable.

MATCH and Built-in PoliciesMATCH / DIRECT / REJECT: MATCH is a catch-all rule type, usually placed at the end of the rules list to handle connections not matched earlier. DIRECT means a direct connection, and REJECT means the connection is rejected; both are built-in policies. PROXY in an example is usually a custom proxy group name that must be defined in the configuration, not a fixed built-in keyword.

04 / GROUPS & NODES

Proxy Groups and Nodes

Nodes describe how to connect to a server; proxy groups determine how an outbound is selected. To understand the currently selected group and node in the interface, check which rules refer to them.

Proxy GroupProxy Group: Groups multiple nodes or other proxy groups under a name that rules can use as an outbound. select lets you choose manually, url-test selects based on test results, fallback switches according to availability and order, and load-balance distributes connections using an algorithm. Changing a group on the Proxies page affects only traffic that actually references it; groups can also be nested.

NodeProxy Node: A set of parameters describing how to connect to a proxy server, typically including the protocol, server address, port, and authentication details. The displayed node name is only a label and does not establish its exit location, performance, or availability. When sharing an error, you can keep the protocol type and error details, but hide sensitive information such as passwords, user IDs, and full subscription URLs.

Latency TestLatency Test: Estimates a proxy route's responsiveness by timing a request to a specified test URL. This is not necessarily the same as an ICMP ping from a system command. Results depend on the test site, connection reuse, handshake, and network conditions, and do not indicate download speed. A timeout may mean the node is unavailable, or simply that the test target cannot be reached; verify with the actual service and connection logs.

url-testAutomatic Test Group: A proxy group type that automatically selects a node based on periodic tests, useful if you want to reduce manual switching. interval sets how often tests run; tolerance helps prevent frequent switching due to small changes in response time. Choose a representative test target: a faster test does not mean every service will be faster. Existing connections may not move immediately when the selected node changes.

05 / SUBSCRIPTIONS & CONFIG

Subscriptions and Config Files

A subscription is a way to fetch content; a config file is the structure the core reads. Importing, selecting, overriding, and running a configuration are separate steps.

SubscriptionSubscription: A distribution method that fetches and updates proxy nodes or a complete configuration from a URL. Providers may return different formats. After importing on the Config page, select the configuration, then check its proxy groups on the Proxies page. Subscription URLs may contain access credentials, so do not share them publicly. If an update fails, check that the URL is valid and review the response content instead of repeatedly clicking Update.

YAMLYAML Configuration Format: A structured text format commonly used for Clash configuration, with indentation defining hierarchy and lists and key-value pairs organizing settings. Use spaces rather than tabs, and follow quoting rules when strings contain special characters. Valid syntax only means the structure can be parsed; it does not guarantee that the current core supports every field or that node parameters and rule references are correct.

Config FileProfile / config.yaml: A file that defines settings such as nodes, proxy groups, rules, DNS, and listening ports. It can be downloaded from a subscription or imported locally. The original file saved on the Config page may not be the complete configuration the core ultimately reads, since the client may layer global settings or overrides on top. If changes to a file have no effect, check the selected profile, reload result, and active configuration.

Overrides and MergingOverride / Merge: A way to layer local settings over an original subscription configuration, often to preserve personal ports, DNS settings, or custom rules and avoid reapplying them after every subscription update. Whether fields are replaced or merged, how arrays are handled, and the order in which changes are applied depend on the client. Back up the configuration before editing, then inspect the final result after reloading to ensure another layer has not overwritten the same setting.

06 / NETWORK & SYSTEM

Network and System Settings

Traffic capture, name resolution, and outbound selection are separate steps. Turning on a setting does not guarantee that queries and connections are handled as expected.

System ProxySystem Proxy: Points the operating system's proxy setting to the client's local listening address, so apps that honor the setting send requests to the proxy port. It usually cannot capture traffic from apps that ignore the system proxy, and does not automatically set environment variables for command-line tools. After enabling it, check the Connections page to see whether requests from the target app appear. For setup steps, see the system proxy setup guide.

TUN ModeTUN Mode: Receives IP packets through a virtual network interface and routing rules, useful when you need to capture traffic from more apps. It typically requires appropriate system permissions or service support. Whether traffic is captured also depends on routes, interfaces, DNS, and exclusion settings. TUN describes how traffic enters the core; rules still determine whether it connects directly or through a proxy. It is not the same as global proxy mode.

DNSDomain Name System: The system that looks up records such as IP addresses for domain names. Correct DNS resolution can affect connection setup and some rule matching. Client DNS, system DNS, and an app's own encrypted DNS may all be active, each handling different queries. When troubleshooting, distinguish resolution for the destination domain from resolution for the proxy server's domain, and check the resolver's own connection path; changing one setting alone may not address the whole issue.

Fake-IPSynthetic IP Mapping: A method in which proxy DNS returns synthetic addresses and the core stores an internal mapping between addresses and domains, allowing later connections to be routed by the original domain. A synthetic address in a query result does not mean the real website uses that address, nor does it by itself indicate a DNS failure. Some apps may need filter settings to use real DNS resolution; after changing them, consider stale DNS cache entries and existing connections.

DNS LeakDNS Leak: A DNS query taking an unexpected resolution path—for example, when it was meant to use a specified resolver but instead went through the system or an app. First clarify the intended configuration; direct DNS resolution is not necessarily a problem. The resolver's location shown on a test page does not prove a leak on its own. Check the app's resolution method, client logs, and actual DNS settings. See the DNS FAQ.

UWP LoopbackUWP Loopback: A network isolation restriction that can affect some Windows app containers accessing the local loopback address; 127.0.0.1, commonly used by local proxies, is a loopback address. A loopback exemption lets specified apps access local services, but does not select a node or change an app's proxy behavior. If only one Microsoft Store app cannot connect, see UWP loopback troubleshooting instead of resetting all network settings.