Configuration Reading · Concept Reference

Clash Glossary

A focused reference for common terms in subscriptions, nodes, rule routing, protocols, cores, and DNS configuration. Each entry explains the concept, its practical role, and commonly confused boundaries—useful when reading tutorials or checking a configuration.

5 categories 26 terms Configuration and networking concepts

Core Concepts

Start by distinguishing configuration sources, connection targets, and runtime state. These terms appear repeatedly on the client home screen, in subscription management, and throughout Troubleshooting steps.

Subscription: A remote configuration endpoint published by a service provider, typically containing nodes, proxy groups, or rules. The client fetches content from the subscription URL and generates a usable configuration after updates. Updates overwrite content managed by that source, so confirm override support before making local changes.

Node: A proxy endpoint that the client can use to establish a connection. A node usually contains a server address, port, protocol, and authentication parameters. Appearing in the list does not guarantee availability; status also depends on the parameters, network path, and server operation.

Latency: The time required for a test request to travel from the client to a response, usually measured in milliseconds. Lower latency generally means faster interaction, but it does not by itself represent bandwidth, stability, or actual download speed. Results may also differ between test endpoints.

Configuration File: A structured file describing ports, proxy nodes, proxy groups, DNS, and routing rules. The Clash ecosystem commonly uses YAML, where field hierarchy and indentation directly affect loading. A configuration may come from a subscription or be maintained locally.

Runtime Configuration: The complete configuration currently passed by the client to the core for execution. It may combine local settings, subscription content, scripts, and override rules, so it may not exactly match the original subscription file. When investigating rule or DNS issues, check the actual runtime configuration first.

Protocols and Transports

The protocol determines how the client and server authenticate and exchange data, while transport parameters describe how the connection is carried. Matching names do not mean every parameter combination is interchangeable.

Shadowsocks（SS）: A relatively lightweight encrypted proxy protocol, often abbreviated as SS. The server address, port, encryption method, and password must match. Whether an encryption algorithm is available also depends on the current core's support.

VMess: A proxy protocol in the V2Ray ecosystem. Its configuration commonly includes a user ID, transport method, and security parameters. It can be combined with WebSocket, HTTP, and other transports. Compatibility with legacy fields and transport combinations varies between clients.

Trojan: A proxy protocol designed around a TLS-style connection. Common fields include the server, port, password, and server name. The client may also handle certificate validation and ALPN options. A mismatch involving the server name or certificate parameters often prevents the connection from being established.

VLESS: A protocol that separates authentication from the underlying transport. It is often combined with TLS, Reality, WebSocket, or gRPC. Writing only VLESS in a node name does not describe the complete connection method. Compatibility depends on the core version and complete transport parameters.

UDP: A datagram-oriented transport protocol that does not first establish a reliable byte stream like TCP. Voice, gaming, and some DNS requests may use UDP. The node, proxy group, and core must support it for this traffic to be forwarded as expected.

Rules and Routing

Rules identify connections, while proxy groups choose the outlet. Understanding match order and the fallback rule is the foundation for adjusting Clash rule routing.

Rule Routing: Uses domains, IPs, processes, or rule sets to decide whether a connection should go direct, be rejected, or be sent to a specified proxy group. Rules are usually matched from top to bottom, and the first match determines the destination. The key difference between Rule and Global modes is whether this step-by-step evaluation runs.

Proxy Group: Combines multiple nodes or other strategies into a logical outlet that rules can reference. A proxy group can be selected manually or make automatic decisions based on latency tests, failure order, or load. When a rule points to a group name, the final node depends on the group's current state.

DOMAIN-SUFFIX: A rule type that matches a specified domain suffix and its subdomains. For example, a suffix rule for example.com will usually also match www.example.com. It is useful for covering a set of services under the same parent domain.

GEOIP: A rule type that matches according to the geographic assignment of the destination IP in a GeoIP database. Results depend on the local GeoIP data and its update time. It handles the location of the resolved IP, not classification of the domain itself.

MATCH: Handles connections not matched by any earlier rule and is usually placed at the end of the rule list. It acts as the default outlet for the entire rule set. If MATCH appears too early, later specific rules never get a chance to match.

Rule Set: A data collection that groups similar matching conditions for independent maintenance and reuse. Remote rule sets can be updated separately, reducing duplicate entries in the main configuration file. Their format, behavior type, and reference name must meet the current core's requirements.

Clients and Cores

Graphical interfaces, proxy cores, and configuration formats are separate layers. Distinguishing them helps identify whether a capability is provided by the interface or by the core.

mihomo: The core name used after Clash Meta, responsible for parsing configuration, establishing proxy connections, executing rules, and handling DNS. Graphical clients typically add subscription management, toggles, and visual controls on top of mihomo. When checking protocol support, the core version is usually more important than the interface version.

Clash Meta: The name of an extended core branch in the Clash ecosystem, adding support for more protocols, DNS features, and network interception. The project is now maintained under the name mihomo, so older documentation still frequently refers to Clash Meta. In different historical contexts, the two names may refer to the same development line.

Graphical Client: A desktop or mobile application that wraps a proxy core and provides windows, menus, and system integration. The client handles subscription imports, toggles, and status displays, while the core usually processes the actual traffic. Interface and core versions may be updated independently.

YAML: The text serialization format commonly used for Clash configuration, with indentation expressing hierarchy. Spaces, list markers, and colon placement are syntactically significant. Tabs, incorrect nesting, or missing required spaces can prevent the configuration from loading.

Networking and DNS

These terms describe how traffic enters the core and how domains are resolved. System proxy and TUN operate at different interception layers, and the DNS path must be checked separately.

System Proxy: Points the operating system's HTTP or SOCKS proxy settings to Clash's local listening port. Applications that follow system proxy settings send relevant requests to the client. Some apps use an independent network stack, so enabling the system proxy may not cover all traffic.

TUN Mode: Receives system traffic through a virtual network interface, then lets the core apply routing and forwarding. It usually covers more applications than a system proxy and can handle more non-HTTP traffic. Enabling it requires correct system permissions, routes, interface settings, and DNS configuration.

Mixed Port: A listening mode that accepts both HTTP and SOCKS proxy connections on the same local port. The configuration field is usually written as mixed-port; 7890 is a common local port example. When another application is configured to use the proxy, also verify the listening address and port.

Fake-IP: The DNS module returns mapped addresses to applications and restores the target domain from the mapping when a connection is made. This helps apply domain rules earlier and reduces information loss caused by resolving before matching. LAN devices, connectivity checks, and special domains may need to be added to a filter list.

DNS Leak: A situation in which an app's domain lookups bypass the expected DNS path and go directly to another resolver. Check system DNS, browser Secure DNS, TUN coverage, and nameserver settings together. A successful proxy connection alone cannot fully reveal the DNS path.

Nameserver: The upstream server list used for standard domain resolution in the DNS configuration. It serves a different purpose from fallback and default-nameserver and should not be swapped based on names alone. The request path also depends on DNS mode, domain rules, and kernel settings.

Continue Exploring Configuration Resources

When you need to apply these terms in a real workflow, start with Getting Started; when comparing protocols, cores, and compatibility, consult the protocol reference.

Read Getting Started View Protocol Reference View FAQs