When you encounter an unfamiliar field in a configuration file, use this glossary to identify which layer it belongs to. Each entry explains the concept, common uses, and its relationship to nearby settings.
Click a term to jump directly to its explanation.
How clients obtain proxy information, establish connections, and interpret test results.
A node is a server entry used to establish a proxy connection, typically containing an address, port, protocol, and authentication details. The node name shown in a client interface is mainly for identification; the protocol parameters inside the entry determine how the connection actually works. Whether a node connects successfully also depends on the local network, the remote service, and the system clock.
A subscription is a URL for retrieving a remote configuration or list of proxy entries. After importing it, the client can fetch it again on a schedule to synchronize changes to proxies, proxy groups, and rules. Subscription updates usually overwrite the remotely supplied content, so personal rules that must persist are better placed in an override configuration.
A proxy protocol defines how the client connects to the remote service, authenticates, and transfers data. Supported transport layers, encryption parameters, and extension fields vary by protocol, so the configuration must match the remote service. Whether a protocol is supported also depends on the core version and how the client is packaged.
Latency is the time between a client sending a request to a specified test address and receiving a response. It mainly reflects connection setup and round-trip response time, not download speed, stability, or long-duration transfer performance. For meaningful comparisons, use the same test address and method for every node.
WebSocket is an optional transport supported by some proxy protocols, allowing bidirectional data transfer over a persistent connection. It commonly appears alongside a path, request headers, or TLS settings. A mismatch between the client and remote service can cause the handshake to fail or the connection to close prematurely.
Clash checks connections against rules from top to bottom and stops at the first match.
Rules determine whether a connection is handed to a proxy policy, connected directly, or rejected based on its domain, IP, process, or rule set. This differs from Global mode, which generally sends most connections to one policy, while Rule mode evaluates them individually. When troubleshooting a routing result, check the rule order, target type, and final proxy group together.
DOMAIN-SUFFIX matches a target by domain suffix. For example, example.com will usually also cover its subdomains, making it suitable for applying one policy to an entire site family. To match only one exact domain, use the narrower DOMAIN rule.
IP-CIDR matches target IP addresses using CIDR notation. The trailing no-resolve option means the rule will not actively trigger domain resolution for matching, reducing unnecessary DNS queries. The prefix length determines the matching range, so verify the network prefix before saving it.
GeoIP applies rules according to the target IP's location in a geographic database. It is useful for connections whose IP address is already known, but the database result does not identify the service operator or guarantee the actual access experience. Accuracy can be affected by the database version, IP reassignment, and resolution results.
GEOSITE organizes large collections of domains by region or purpose, allowing a configuration to reference an entire category with one rule. It matches domain information, unlike GeoIP, which classifies IP addresses. The domains included in a category may change when the rule set is updated.
MATCH is a common fallback at the end of a rule list for connections not matched earlier. Because it catches all remaining traffic, placing it in the middle prevents later rules from matching. When reviewing a configuration, make sure no ordinary rules that still need to apply appear after MATCH.
The graphical client handles the user interface, while the core reads the configuration and processes the actual network connections.
mihomo is an open-source proxy core that carries forward Clash Meta capabilities, parsing configuration, applying routing rules, handling DNS, and taking over network connections. Desktop and mobile clients commonly call it through their graphical interfaces. Whether a setting is available depends on both the mihomo version and whether the client exposes the relevant control.
Clash Meta is the name of a core branch in the Clash ecosystem that expanded protocol, rules, DNS, and TUN capabilities. Later projects and maintenance moved toward mihomo, so newer documentation more often refers to mihomo. When Meta appears in an older configuration, it usually describes the core's origin or compatibility range.
YAML is a common format for Clash configuration, using indentation for hierarchy and keys and lists to organize settings. Incorrect indentation, mixing tabs with spaces, or omitting a space after a colon can all cause parsing failures. After editing, check the client log for configuration syntax errors.
config.yaml is a common main configuration filename that can store listening ports, DNS, proxies, proxy groups, and rules. Some clients generate a separate configuration for each subscription, so the filename is not always fixed. Direct edits to a generated file may be replaced during the next subscription update.
A proxy group organizes multiple proxies, other proxy groups, or direct actions under a name that rules can reference. Common group types include manual selection, automatic testing, and fallback. Switching a proxy group only affects connections that reference it; it does not rewrite the rules themselves.
Rule Provider splits rules into a separate file or remote resource, which the main configuration references by name. This allows the download URL, update interval, and rule behavior to be configured independently. If remote content fails to load, check the path, format type, storage location, and current network status.
DNS settings determine how domains are resolved and can affect whether domain rules retain complete matching information.
DNS converts domain names into network addresses. Clash can take over queries and select local, encrypted, or specified upstream resolvers according to the configuration. If a domain is unreachable while its IP connects successfully, the DNS path is usually the first thing to check.
Fake-IP mode first returns a reserved address to the application, then restores the original domain when the connection enters the core. This helps preserve domain information and apply domain rules earlier. Some LAN services or applications that depend on real DNS results may need to be added to the filter list.
Redir-Host mode returns the real resolution result and attempts to maintain the mapping between the domain and the connection. Its main difference from Fake-IP is that the application receives the actual address. Whether a client offers this mode, and how it implements it, depends on the core version.
A DNS leak occurs when domain queries bypass the intended resolution path and are sent directly by the system, browser, or another network interface. This can make actual routing differ from the configured design. Troubleshooting should cover system DNS, browser Secure DNS, the traffic range intercepted by TUN, and Clash's DNS listener status.
nameserver-policy assigns DNS upstreams by domain or rule set, allowing different queries to follow different resolution paths. It is useful for region-specific resolution or domains that require a fixed resolver. When matching conditions overlap, also check the configuration order and the core's rule behavior.
IPv6 is a next-generation network addressing protocol that can coexist with IPv4. After enabling IPv6 in Clash, DNS resolution, listening addresses, and exit connections may all use IPv6. If local networking or the remote exit has incomplete support, only some websites may experience connection problems.
These settings determine how traffic enters the core and whether applications in the operating system can be intercepted.
A system proxy points the operating system's proxy settings to Clash's local listening port. Browsers and applications that follow system proxy settings send connections through that port. Some games, command-line programs, and standalone network components do not read system proxy settings; they require separate configuration or TUN mode.
TUN mode creates a virtual network interface to take over system traffic at the network layer. It can cover applications that ignore system proxy settings, but usually requires system authorization and involves routing, DNS, and firewall configuration. System proxy and TUN suit different scenarios and should not be treated as the same switch.
A mixed port typically accepts both HTTP and SOCKS proxy connections on the same port, giving different local applications a shared entry point. It describes only the local listening method, not the proxy protocol used by the remote service. If another program occupies the port, the core reports the listening failure in its startup log.
Allowing LAN connections makes the local proxy port accessible to other devices on the same network. After enabling it, also check the listening address, system firewall, and the device's subnet. Share connections only on trusted networks and avoid exposing the control interface to untrusted networks.
A configuration override adds to or modifies local settings outside the subscription content, commonly preserving DNS, rules, and port preferences. It reduces the effect of subscription updates on personal settings. Clients implement overrides through merging, scripts, patches, or other methods, so check the relevant client documentation for field precedence.
A GUI client provides a graphical interface for the proxy core, handling configuration imports, policy selection, system integration, and log viewing. The client name may differ from the actual core name, and a client may switch core versions in an update. To determine feature support, confirm the client version, core type, and current configuration together.
Once you understand the fields, follow the getting-started guide to import a subscription, choose a policy, and verify the connection. For platform-specific installation differences, continue to the full user handbook.