Clash Terminology Guide

Clash is a network proxy ecosystem centered on rule matching, policy-based routing, and local proxies. In everyday usage, Clash may mean an early core, a compatible configuration format, or a graphical client built around a related core.

When reading documentation, first identify what is being discussed: the client handles the interface and system integration, while the core handles connections, resolution, and forwarding. Their versions, supported fields, and release cycles may differ.

mihomo is a proxy core evolved from Clash Meta. It reads configuration files and handles low-level functions including proxy protocols, rule matching, DNS, TUN takeover, and control interfaces.

Graphical clients such as Clash Verge Rev and FlClash can call or manage mihomo, but a client name is not the same as the core name. When checking whether a field is supported, verify both the integrated core and the configuration syntax.

A graphical client provides the core with interfaces for importing configurations, switching policies, viewing logs, controlling the system proxy, and managing updates. It commonly also requests system permissions, stores user preferences, and starts the core process.

A successful connection status in the interface only indicates that the relevant switch or process has reached its expected state. Whether traffic actually uses the proxy must be assessed through the system proxy, TUN routes, matched rules, and logs.

The system proxy is the mechanism through which an operating system publishes HTTP, HTTPS, or SOCKS proxy addresses to applications. Browsers and most desktop programs that follow system network settings read this address and send requests to Clash's local listening port.

Some games, command-line tools, and applications with their own network stacks may ignore the system proxy. This traffic usually requires separate proxy environment variables or TUN mode for interception.

TUN mode receives IP traffic from the operating system through a virtual network interface, then lets the core decide whether to connect directly, use a proxy, or reject it according to the rules. It covers more applications than the system proxy and can handle some programs that do not read proxy settings.

Enabling TUN typically requires administrator privileges, VPN permissions, or a corresponding system extension. Route conflicts, other VPNs, virtual machine adapters, and firewall policies can all affect the takeover result.

A node is an object in a configuration that describes a remote proxy endpoint, typically including a server address, port, protocol, authentication parameters, and transport options. Policy groups reference these objects by name.

Node names are primarily identifiers; region or traffic-multiplier information in a name is defined by the configuration provider. Availability should be judged through real connections, access to target sites, and sustained stability.

A proxy protocol defines how the client and remote service establish a connection, authenticate identities, and encapsulate traffic. Protocols have different requirements for TLS, transport layers, UDP, plugin parameters, and server implementations.

The protocol field in a configuration must match the server settings. Changing only the protocol name does not convert a format; missing fields or mismatched parameters typically cause the handshake to fail.

Latency usually means the time between a probe sent by the client and the response received, measured in milliseconds. A client's latency test accesses a specified URL, so the result is also affected by the test address, DNS, and network path at that moment.

Lower latency does not mean higher download speed, nor does it reveal long-term packet loss or bandwidth fluctuations. Use latency for initial screening, then consider the node's actual performance with the target service.

UDP forwarding means that a proxy path can handle UDP datagrams, commonly used by real-time communications, some games, QUIC, and DNS queries. Unlike TCP, it does not establish a reliable byte stream, so timeout and session management work differently.

Actual support depends on the core, proxy protocol, node server, and policy group together. A node field declaring UDP support does not guarantee that every link in the path is correctly enabled.

Multiplexing carries multiple logical requests over fewer underlying connections. Its usual goal is to reduce repeated handshakes and connection setup overhead, not to increase line bandwidth directly.

On networks with significant packet loss or an incompatible server implementation, multiplexing can also cause requests to affect one another. Enable it only after consulting the protocol documentation and testing in practice.

A policy group is a collection of nodes, child policy groups, or built-in actions. Common types include manual selection, automatic latency testing, fallback, and load balancing; the available types depend on the core.

Rules usually point to a policy group name, separating exit selection from rule conditions. This lets you switch nodes or change selection logic without editing the rules.

Rule-based routing sends requests to a specified policy group according to domains, IPs, ports, processes, or rule sets. It lets different destinations use different exits instead of sending all traffic to one fixed node.

Rules are usually matched from top to bottom in declaration order. A broad condition placed too early can hide later, more precise rules. When troubleshooting routing results, first confirm the rule that actually matched in the connection log.

DIRECT means that a request connects to its destination through the local network without being sent to a remote proxy node. It suits local network resources or destinations that explicitly need the current network exit.

Direct connection does not mean that all Clash processing is bypassed. The request may still pass through the core's DNS handling, rule evaluation, or TUN routing before using the local network as its final exit.

REJECT means that matching connections or requests are denied. It is commonly used to block traffic from specified domains, IP addresses, or rule sets.

A rejected application may fail immediately, time out, or be unable to load a resource, depending on the core's response behavior and the application's network implementation. To troubleshoot false blocks, inspect rule order and rule-set contents.

GeoIP uses a database to assign IP addresses to country or region codes and then matches rules accordingly. It is suitable for coarse routing based on network address allocation.

Database records change as addresses are allocated, and content delivery networks may return different IPs in different locations. GeoIP results should not be interpreted as a server's exact physical location.

MATCH is the final fallback condition in a rule list, receiving requests that matched none of the preceding rules. It is usually placed at the end of the rules section and points to a general policy group or DIRECT.

If MATCH appears near the top of the list, later rules will have little chance to match. When investigating unexpected routing, verify the fallback rule's position and target policy.

DNS is a distributed system that translates domain names into IP addresses or other resource records. A Clash core can listen for local DNS requests and send queries to different upstream resolvers according to its configuration.

A successful DNS lookup only means that an address was returned; it does not guarantee that the destination connection works. The connection still requires rule matching, route selection, a proxy handshake, and a response from the destination service.

Fake-IP mode first returns a reserved address for a domain and records the address-to-domain mapping inside the core. When an application connects to that reserved address, the core can restore the original domain and continue rule matching and remote resolution.

This approach helps preserve domain information, but some applications that depend on real local-network addresses or perform special DNS checks may need to be added to the filtering range. Adjust filters for specific domains rather than broadly.

Redir-Host performs conventional DNS resolution first and returns the real IP to the application. The subsequent connection enters the core based on that address, so its processing path differs from Fake-IP.

This mode can be more straightforward on some local networks and with special applications, but how much domain information is retained may depend on sniffing and connection behavior. After switching modes, recheck which domain rules actually match.

A DNS leak occurs when queries intended for a designated resolution path are sent directly to a different resolver by the system, router, browser built-in mechanism, or other network software. It usually indicates that DNS interception does not cover the expected scope.

Check the system DNS addresses, the client's listening port, TUN DNS hijacking settings, the browser's Secure DNS setting, and other VPNs. Changing only one upstream address is usually not enough to locate the complete path.

nameserver-policy selects an upstream resolver for DNS queries based on domain conditions. It can send different domains to different DNS services or establish a fixed resolution path for specific domains.

This field controls where DNS queries are sent; it does not directly decide whether application connections use a proxy or connect directly. The connection exit is still determined by rules and policy groups.

A subscription is an update source that retrieves a node list or complete configuration from a remote address. The client requests the content manually or on a schedule, then saves the result as a usable configuration.

A subscription may return YAML, an encoded node list, or a provider-specific format converted by the server. If importing fails, first check the response content and status, then verify which fields the client supports.

YAML is the structured text format commonly used for Clash configurations. Spaces express object hierarchy and hyphens express list items. Colons after field names, string quotes, and indentation depth all affect parsing.

Do not mix tabs with spaces for YAML indentation. Fields at the same level must use consistent indentation, and values containing special characters can be quoted to reduce parsing ambiguity.

A configuration file is a YAML document that stores fields such as ports, operating mode, DNS, nodes, policy groups, and rules. When starting, the core reads the configuration and builds its listeners and forwarding logic from those fields.

A graphical client may also store interface settings separately from YAML, such as launch-at-startup, the system proxy switch, and the core path. Copying a configuration file does not necessarily copy these client preferences.

A proxy provider is commonly defined by proxy-providers and loads a set of nodes from a separate file or remote address. Policy groups can reference these nodes through the provider instead of repeating every node in the main configuration.

Configure the provider's update interval, storage path, health checks, and format separately. A provider loading successfully does not mean that every node in it can establish a connection.

Overrides and merging describe how a client adds, replaces, or combines local fields on top of subscription content. Common uses include adding custom rules, adjusting DNS, adding policy groups, or preserving local port settings.

Merge syntax and precedence vary between clients. The final value of a duplicate field depends on processing order, so after editing, inspect the generated configuration rather than only the override fragment.