A focused guide to common Clash terms found in configuration files, client interfaces and runtime logs. Topics cover kernels, proxy paths, rules, subscriptions, DNS and system traffic interception for faster setup and troubleshooting.
Start with the stage where the problem occurs. For configuration errors, check subscriptions and configuration; when connections work but routing is wrong, check rules and policy groups; when an app is not intercepted, check proxies and tunnels or platform integration.
Distinguish the kernel that processes network traffic from the client that provides the interface, along with the configuration and data directories they share.
The core program that reads configuration, establishes proxy connections, opens local ports and matches rules. A graphical client is usually only the control layer; the kernel handles the actual traffic. When startup fails, check client interface logs and kernel runtime logs separately rather than treating them as one process.
The proxy kernel project maintained as the successor to Clash Meta, covering rule-based routing, TUN, enhanced DNS and multiple protocols. Some clients label it the Meta kernel or mihomo kernel in settings. Client and mihomo version numbers belong to separate release histories and should be checked independently when comparing features.
A desktop or mobile app that wraps a proxy kernel with visual controls for importing subscriptions, switching policies, viewing logs and managing the system proxy. Even with the same kernel, clients may use different configuration directories, permission models and system integrations. Before switching clients, confirm that the existing configuration can be imported directly.
The local directory that stores YAML configuration, rule sets, GeoIP data, caches and logs. A graphical client may create a separate subdirectory for each configuration or temporary files during updates. During troubleshooting, confirm the loaded path in runtime logs before editing the matching file, so you do not modify an inactive copy.
How traffic enters the kernel, connects to remote nodes, and differs between system proxy and TUN interception.
A server entry used to establish a remote proxy connection, usually containing an address, port, protocol and authentication parameters. The node name is only a display label and says nothing about route quality or actual location. When a node fails, use connection logs to distinguish DNS errors, handshake failures, authentication errors and remote timeouts.
The time from a client request to a test target until a result is received, usually measured in milliseconds. Results depend on the test address, congestion, remote load and test method. Low latency does not necessarily mean high bandwidth; throughput also depends on packet loss, link capacity and the target site's response.
Point the operating system's HTTP, HTTPS or SOCKS proxy settings to Clash's local listening port. Browsers and most desktop apps that follow system network settings use this path, but programs with their own network stack may bypass it. If an app connects directly while the system proxy is enabled, first check the app's own proxy settings.
Receives system IP traffic through a virtual network interface, then lets the kernel decide whether to connect directly or use a proxy. It can usually intercept apps that ignore system proxy settings, while also changing the DNS and routing troubleshooting path. Enable it only with the required system permissions, and check the virtual adapter, routing table and other network tools for conflicts.
How connections move from matching conditions into policy groups, and how rule order, external rule sets and regional data affect the result.
Matches connections by domain, IP, process or rule set, then sends them to the selected policy group. Most configurations evaluate rules from top to bottom, so the first match wins; specific rules generally belong before broader ones. When routing is wrong, use logs to confirm the matched rule type and target policy.
Organizes multiple nodes or other policy groups into a logical exit supporting manual selection, automatic testing, load distribution or failover. Rules normally target the group, so changing nodes does not require editing every rule. Deeply nested groups add troubleshooting layers; verify the final exit one level at a time.
A purpose-built collection of domains, IP ranges or other matching conditions loaded from a local file or remote address. Rule sets keep the main configuration compact and can be updated independently. If a remote download fails, the client may continue using a cached copy, so check the update time, download logs and actual matches together.
A data and rule type that matches the region associated with an IP address, commonly used for connections already resolved to IPs. It is not a real-time geolocation service; results depend on the local database. After updating Clash GeoIP, confirm that the kernel reads the new file, as stale data may route newly allocated addresses incorrectly.
DOMAIN-SUFFIXHandle the specific domain scope firstPROCESS-NAMEThen add routing by application processGEOIPHandle resolved IP ranges by regionMATCHCatch connections not matched aboveDistinguish remote subscriptions, the active configuration, YAML syntax and external proxy providers to locate import and parsing problems.
A remote configuration source published and periodically updated by a service provider. Successfully importing a Clash subscription URL only means the client saved the address; the network request, content download and configuration parsing must also complete before nodes appear. For failures, check the response status, returned content and parsing logs separately.
The text serialization format commonly used for Clash configuration, using indentation to represent object and list hierarchy. Tabs, inconsistent indentation, missing spaces or unquoted special characters can cause parsing failures. When editing manually, preserve the existing hierarchy, change a small amount at a time and rerun configuration validation.
A YAML document describing listening ports, proxy nodes, policy groups, rules, DNS and TUN parameters. A client can save multiple configurations but loads only the active one at runtime. If changes do not take effect, confirm the file was saved, the configuration was reloaded and the interface shows the intended active configuration.
A configuration mechanism that loads proxy nodes from an external file or remote address, with options for update intervals, cache paths and health checks. It separates node sources from the main configuration and works well for combining multiple sources. If a provider fails to load, referencing policy groups may be empty; check the provider status before testing the group.
How domain resolution enters Clash, how Fake-IP differs from Redir-Host, and what to check for DNS leaks and split DNS.
The condition where connection traffic is proxied but domain lookups still use the system's default resolver path. This can expose requested domains or produce results that do not match the proxy exit region. Combine browser tests, system DNS settings, TUN status and kernel logs; a single webpage result is not enough to identify the cause.
A DNS enhancement mode in which the kernel returns a reserved address for a domain, maps it back to the original domain during connection handling and applies rules. It preserves domain information, but some LAN devices, games or specialized apps may reject the result. Add exclusions for specific domains when compatibility requires it.
A DNS enhancement mode that returns the real resolution result, so subsequent connections mainly use the actual IP. Network behavior is closer to conventional DNS, but domain information may be lost during connection handling, requiring sniffing or another mechanism for some domain rules. Clear the old DNS cache before testing after a mode change.
A configuration item that assigns DNS servers according to domain conditions and routes different domains through different DNS paths. It is commonly used for split DNS, LAN domains or specific rule sets. Check the primary nameserver, fallback and matching conditions together to avoid unexpected overrides.
Covers background services, virtual network adapters, process identification and bypass scopes—the operating-system network behavior beyond the client interface.
A runtime arrangement in which the kernel or an auxiliary component starts as an operating-system background service and can continue handling traffic after the user interface closes. Services may use separate accounts, permissions and working directories. When the interface and actual proxy state differ, check the service process, startup arguments and configuration path it reads.
The logical network interface created or used by TUN mode to receive IP traffic routed to Clash. It participates in system routing but is not a physical network port. If creation fails, check administrator permissions, driver status, stale routes and network components from VPN or virtualization software.
A matching method that selects rules by the name or executable path of the program initiating a connection, useful for giving a specific app its own policy. It relies on process information from the operating system and may be limited in containers, background services and some mobile platforms. If a rule does not match, confirm the actual process name recorded in the logs.
Domains, addresses or network ranges excluded from system proxy handling, commonly for LAN devices, development addresses and internal system services. A range that is too narrow can disrupt local access; one that is too broad can send requests that should be proxied directly. After changes, test LAN addresses and external targets separately.
For configuration parsing errors, start with YAML, the configuration file and proxy-provider. If a rule matches but the exit is wrong, check rule-based routing and policy groups. If connections fail, check the node and latency. If only some apps bypass the proxy, check the system proxy, TUN, process matching and bypass list.
Terms identify the troubleshooting layer; they do not replace the log's conclusion. Change one variable at a time, reload the configuration, reproduce the problem and compare the logs before and after the change.