CLASH CONCEPT INDEX
Terms for cores, protocols, nodes, rules, and DNS are organized in configuration order. Use this guide to understand client settings, subscription content, runtime logs, and YAML fields.
CATEGORY 01 / RUNTIME
First distinguish the graphical client, proxy core, subscription source, and configuration file. They belong to the same runtime chain but serve different roles.
CLASH / ECOSYSTEM
Clash is a rule-based proxy ecosystem for forwarding traffic. A typical client combines a graphical interface, proxy core, and configuration management, so Clash clients can differ in both interface and core version.
When configuration compatibility issues arise, verify the client name, the core actually in use, and the configuration syntax rather than relying only on the software title.
MIHOMO / CORE
mihomo is an actively maintained Clash-compatible proxy core. It parses configuration, establishes connections, applies rules, and handles DNS and TUN traffic. When a graphical client starts its proxy service, it usually invokes the core in the background.
Fields supported by the core may change between versions. Before copying a configuration example, confirm which core the current client actually loads.
GUI / CLIENT
A client is the graphical application users operate directly. It usually provides subscription management, node selection, system proxy controls, log viewing, and core update options. The client handles interaction, while the core performs most connection and routing work.
Clients do not handle configuration overrides, backup paths, or permission requests in exactly the same way. Check each one separately when migrating.
PROFILE / SUBSCRIPTION
A subscription is a remote configuration endpoint published by a service provider. After reading its URL, the client can obtain nodes, policy groups, and some rule configuration, then fetch updated content later.
A subscription link is not the same as a single node and may not return complete YAML directly. If importing fails, first check that the link is complete, has not expired, and returns a supported format.
YAML / CONFIG FILE
YAML is a common data format for Clash configuration files. Indentation expresses field hierarchy, arrays usually begin with a hyphen, and spacing after colons must be correct.
Tabs, misaligned indentation, duplicate fields, and unclosed quotes can all cause configuration parsing to fail. Keep a copy of a configuration that starts successfully before editing.
CATEGORY 02 / TRANSPORT
The local proxy entry point and the remote node protocol operate at different layers. The former determines how an application hands traffic to the client; the latter determines how the core connects to the server.
HTTP / LOCAL INBOUND
An HTTP proxy receives HTTP requests from browsers or applications and can forward HTTPS connections through CONNECT. It suits browsers, download tools, and development environments with explicit proxy settings.
This describes how local applications connect to the client; it does not mean the remote node must use HTTP.
SOCKS5 / LOCAL INBOUND
SOCKS5 is a general-purpose protocol for forwarding connections and does not need to understand web content. Many terminal tools, browser extensions, and developer applications support SOCKS5 addresses.
Whether DNS is resolved remotely through SOCKS5 depends on the application and connection parameters; the port type alone is not enough to determine this.
MIXED-PORT / INBOUND
A mixed port accepts HTTP and SOCKS5 proxy connections on the same listening port. It reduces the number of local ports to remember and maintain, making one shared entry point practical for multiple applications.
Applications must still select a supported proxy type and enter the host address and port correctly.
OUTBOUND / PROTOCOL
A proxy protocol defines how the core and remote server handshake, authenticate, and transfer data. Protocols differ in transport layer, encryption, UDP support, and network compatibility.
The protocol name in the configuration must match the server. Changing only the display name or port cannot convert one protocol into another.
UDP / DATAGRAM
UDP forwarding handles connectionless datagrams generated by DNS, real-time communications, and some games. Whether a node can forward them depends on the node protocol, server capabilities, and current network mode.
A webpage loading successfully does not prove that UDP works. Troubleshooting requires checking node parameters, policy selection, and TUN routing separately.
CATEGORY 03 / OUTBOUND
Nodes provide specific outbounds, while policy groups determine how to choose among them. Rules usually reference a policy group rather than binding directly to one node.
PROXY / NODE
A node is a proxy server configuration usable by the core, recording the server address, port, protocol parameters, and authentication details. Its name is mainly for identification in the interface and does not automatically change line quality.
A single node is not the same as a subscription. A subscription usually contains multiple nodes and their group relationships, and can update from a remote configuration.
DELAY / CONNECTIVITY TEST
Latency usually means the time for a test request to travel from the local device to a target and return. Local networking, the test address, node load, and route all affect it, so repeated results may differ.
Low latency does not directly mean high download speed or guarantee long-term stability. Consider connection success rates and real-world access performance when choosing a node.
PROXY-GROUP / POLICY
A policy group organizes multiple nodes or other policy groups into an outbound that rules can reference. Common types include manual selection, health checks, failover, and load balancing.
Policy groups can be nested, but circular references cause configuration errors. After renaming a group, also check the target name in the rules.
URL-TEST / AUTO SELECT
An automatic-selection policy group checks candidate nodes at a configured test address and interval. The core typically chooses a reachable node with the lowest test result as the current outbound.
The test address should be stable and representative of the main use case. An interval that is too short creates extra requests and may cause frequent switching.
FALLBACK / FAILOVER
Failover checks candidate nodes in a preset order and switches to the next when the current node is unavailable. It prioritizes connection continuity, usually keeping the first available node in the order.
Failover therefore does not mean always choosing the lowest-latency node. Arrange candidates according to stability and intended use.
CATEGORY 04 / RULE ENGINE
The rule engine checks connection attributes in order. When troubleshooting routing errors, first confirm the target information, then inspect the first rule that matches.
RULES / ROUTING
Rule-based routing sends connections to different policies based on domains, IPs, processes, or network types. Common uses include direct access for local networks and specific sites, with other connections handled by a policy group.
Rules are usually evaluated from top to bottom and stop after the first valid match. More specific rules should generally come before broader ones.
MATCH / FINAL RULE
MATCH is the final catch-all rule in a rule list. When domain, IP, process, and rule-set rules above it do not match, the connection is sent to the policy specified by MATCH.
It normally belongs at the end of the rule list. If it appears earlier, later rules lose their opportunity to match.
DOMAIN-SUFFIX / DOMAIN RULE
DOMAIN-SUFFIX matches targets by domain suffix. With example.com configured, it can cover the main domain and its usual subdomains.
Unlike DOMAIN, it does not perform an exact match, and a complete URL path should not be placed in the rule. The target handles only the domain portion.
GEOIP / IP DATABASE
GeoIP uses an IP address database to determine a target address’s region. It is useful when the destination IP is already known, but results depend on database versions and changes in address assignment.
Domain and GeoIP rules may participate at different stages. During troubleshooting, check the DNS mode to determine whether the core ultimately sees a domain or an IP.
RULE-PROVIDER / RULESET
A rule set moves many matching entries into a separate file or remote resource, which a rule provider loads from the configuration. This makes reuse, categorization, and independent updates easier.
When a rule-set update fails, an old cache may continue working, or the related rules may become unavailable. Check the resource URL, behavior type, save path, and update logs.
CATEGORY 05 / NETWORK MODE
The system proxy affects only programs that follow proxy settings; TUN and the DNS module handle a wider range of system connections while preserving domain information.
TUN / VIRTUAL INTERFACE
TUN mode receives system traffic through a virtual network interface and can cover applications without proxy settings. It usually requires system permissions, while the core configures routing, DNS hijacking, and interface parameters.
For connection problems, check permissions, the virtual adapter, routing conflicts, the firewall, and DNS settings in sequence. Turning on a UI switch alone does not guarantee that all traffic enters TUN.
FAKE-IP / DNS MAPPING
Fake-IP mode returns reserved addresses to applications and maps them back to the original domains during connection setup. This preserves domain context for the rule engine and reduces matching errors caused by resolving to real IPs too early.
Some LAN devices, games, or specialized applications may not work well with mapped addresses. Use a filter list to exclude the relevant domains.
REDIR-HOST / REAL IP
Redir-Host mode returns actual DNS resolution results to applications and behaves more like conventional network resolution. It does not rely on a Fake-IP address pool, but some connections may retain only the destination IP later.
When rules depend on domains but a connection retains only IP information, matching may differ from expectations. After switching modes, retest DNS caching and routing.
DNS LEAK / RESOLVER PATH
A DNS leak occurs when domain queries bypass the intended Clash DNS path and are handled by another resolver. Common sources include browser-specific encrypted DNS, system service caches, other virtual adapters, and incomplete TUN DNS hijacking.
During troubleshooting, first identify which process initiated the query, then verify system DNS, browser settings, listening ports, and runtime logs.
SYSTEM PROXY / OS SETTING
A system proxy is the proxy address setting provided by the operating system. Browsers and applications that follow it send requests to Clash’s local listening port.
Some programs ignore the system proxy, and some command-line tools also require separate environment variables. To cover this traffic, evaluate TUN mode based on the operating system and network conditions.
Use the glossary to understand concepts; consult the configuration reference for field structures, rule syntax, and YAML examples.