Clash Glossary Cores, Routing, and the Network Stack
First, distinguish the client from the core; then learn how subscriptions, rules, and traffic routing fit together. Look up terms from the settings interface to keep protocols, modes, and permissions clear.
The interface manages settings; the core handles connections. Subscriptions and local changes combine to produce the active configuration.
Client
Client
A client is an app that provides subscription import, mode switching, log viewing, and system integration controls, such as a menu bar utility or desktop control panel. It typically uses a proxy core to handle connections, but the interface's features are not the same as the core's capabilities. When looking for a setting, first identify the client. For protocol compatibility issues, check which core and version it uses.
mihomo
mihomo Core
mihomo is an open-source proxy core from the Clash Meta ecosystem. It handles protocol connections, DNS, rule matching, and outbound selection. Multiple clients can use the same core while offering different management interfaces. Before configuring a new feature, confirm that the active core supports the relevant fields; the client name alone is not enough.
YAML configuration
YAML Configuration
YAML represents data structure through indentation. Clash configuration files commonly use it for ports, nodes, policy groups, and rules. Use spaces for indentation; dashes introducing list items are part of the syntax. A file that parses successfully is only syntactically valid: references to nonexistent policy groups or conflicting ports can still cause loading or runtime failures.
Subscription
Subscription
A subscription uses a remote URL to fetch nodes or a complete configuration, which the client can update periodically. URL subscriptions, local YAML files, and Base64-encoded node strings are different input formats; do not assume they can all be used in the same import field. Subscription URLs may contain account access tokens, so redact them before sharing screenshots or logs. The example URL https://example.com/sub?token=xxxx is for illustration only and cannot be used to connect.
Configuration override
Configuration Overrides
Configuration overrides apply local changes on top of subscription content, often to adjust DNS, ports, or add rules. Clients may merge, replace, or process settings with scripts, so identically named settings do not necessarily take effect in the same order. Direct edits to a generated subscription file may be overwritten on the next update. Learn how your client saves persistent changes, then check the active configuration.
PROTOCOL / OUTBOUND
Nodes and Proxy Protocols
A node specifies the connection destination; a protocol defines how the connection works. A successful import does not guarantee that authentication and transport settings match.
Proxy node
Node
A node is a proxy outbound configuration entry, usually containing a server address, port, protocol, and authentication parameters. It may also include transport-layer and TLS settings. Its name is only a label: a region in the name does not verify the server's location, and appearing in a list does not mean it is available. If a connection fails, check the selected node and logs instead of repeatedly switching outbound modes.
Shadowsocks / ss
Shadowsocks
Shadowsocks is an encrypted proxy protocol, usually written as type: ss in configuration. The encryption method, password, and any plugin settings must match the server; do not substitute an arbitrary method. If a connection fails, distinguish an unreachable server, mismatched credentials, and incorrect plugin settings rather than attributing everything to node latency.
VMess
VMess
VMess authenticates with a user ID and can use different transport methods, such as WebSocket. The UUID, transport path, hostname, and TLS options in a node each serve a different purpose; omitting any one may prevent a connection. When troubleshooting authentication or handshake failures, check that the device clock is accurate and compare each setting against the full parameters provided by the server.
VLESS
VLESS
VLESS is a lightweight proxy protocol that does not provide encryption on its own and is often paired with security mechanisms such as TLS or REALITY. The UUID, transport method, security options, and any flow-control fields must each match the server. Changing a VMess node's type to VLESS does not convert it, and the protocol name alone does not determine the security of the whole connection.
Trojan
Trojan
Trojan typically uses TLS for transport and a password to authenticate proxy connections. The server address, password, and hostname used for certificate validation must all be correct; a valid password does not bypass certificate errors. For handshake failures, check the certificate's validity, the device clock, and the hostname. Disabling certificate verification is not a standard fix.
RULE / POLICY
Rules and Routing
Connections are matched against rules first, then sent to the corresponding outbound or policy group. Rule order is part of the configuration.
Rule-based routing
Rule-Based Routing
Rule-based routing selects where a connection goes based on its domain, destination IP, or other conditions. Rules are usually checked from top to bottom, and the first match selects the strategy. For example, DOMAIN-SUFFIX,apple.com,DIRECT sends domains with that suffix directly. A final MATCH rule can catch connections that did not match earlier rules. When troubleshooting, check both the matched rule and the final outbound.
Proxy group
Policy Group
A policy group organizes nodes or outbound strategies for rules to reference. select is for manual selection, url-test selects based on a test to a specified URL, and fallback typically switches to an available option in candidate order. Groups can also reference other groups, so when you see a group name, check which node it ultimately selects.
DIRECT
Direct Strategy
DIRECT is a built-in outbound strategy that connects to a destination using the device's available network, without forwarding through a remote proxy node. Direct connections are still subject to local routing, DNS, firewall, and network conditions. With TUN enabled, a connection can still enter the core before rules select a direct route, so direct does not mean the client is bypassed entirely.
REJECT
Reject Strategy
REJECT rejects connections that match a rule and can be used to block specific destinations. If a page loads but its images, login, or API requests fail, a required domain may have been rejected by mistake. Find the destination and matched rule in the connection log, then adjust the rule scope rather than deleting all reject rules.
GeoIP
IP Geolocation Matching
GeoIP matches regions using IP address allocation data in a database, for example GEOIP,CN,DIRECT. It is not real-time geolocation and does not classify domains by the organization that owns them. CDN address changes and database updates can affect results. A domain may need to be resolved before an IP rule can match; no-resolve prevents that rule from triggering an additional lookup.
DNS / NETWORK STACK
DNS and the Network Stack
Resolution paths, returned addresses, and traffic routing are connected. Latency tests only show results under their specific test conditions.
Domain Name System
DNS
DNS resolves domain names to IP addresses and other records, a prerequisite for many network connections. The operating system, browser, and proxy core may keep separate caches or use different resolvers. Apps may not immediately use a new path after you change the core's DNS settings. If resolution fails, first identify who sent the request and where it went, then decide whether to clear the relevant cache.
Fake-IP
Fake-IP Mode
Fake-IP returns a virtual address to the app and stores a mapping between that address and the domain in the core. A commonly used virtual address pool is 198.18.0.0/16. When the app connects to that address and traffic reaches the core, the core can recover the domain for routing. This depends on traffic following the correct path. For compatibility issues, configure fake-ip-filter as needed; avoid expanding exclusions indiscriminately.
Redir-Host
Redir-Host Mode
Redir-Host returns the real resolved address to the app instead of a virtual one, which suits some scenarios that require a real IP result. The core still needs to know the domain through DNS records, sniffing, or other means to match relevant domain rules. Switching to this mode does not guarantee that DNS goes through a proxy, and seeing a real IP in an app does not prove that routing is correct.
DNS leak
DNS Leak
A DNS leak occurs when a query leaves its expected resolution path and reaches an unintended resolver. Whether this is a problem depends on the intended privacy and routing goals. Encrypted DNS in a browser, IPv6 settings, and apps whose traffic is not intercepted can create separate paths. Interpret test results in the context of your routing design; local resolution for direct-connection domains is not necessarily a leak.
Latency test
Node Latency
Node latency is usually the time a client records when testing a node against a specified address; it is not necessarily an ICMP ping. The result may include DNS resolution, connection setup, the encryption handshake, and the server response, so it cannot be directly converted to download bandwidth. Keep the test address and conditions consistent when comparing results. If a test times out, check actual access and logs as well.
SYSTEM / PERMISSION
System Integration and Permissions
The system proxy is an app-level entry point; TUN takes over traffic through a network interface. Required permissions depend on the client.
System proxy
System Proxy
The system proxy registers a local proxy address and port with the operating system for apps that honor the setting. Some command-line tools, games, and apps that handle network requests themselves may ignore it, so turning it on does not mean every connection is intercepted. If the network stops working after you quit the client, check whether the system still points to a proxy port that is no longer listening.
TUN mode
TUN Mode
TUN routes network packets through a virtual network interface and can capture some connections that ignore the system proxy. It usually requires additional permissions or a background service. TUN is not the same as global proxy mode: rules still decide whether traffic entering the core goes direct or through a proxy. When running alongside another VPN or virtual network adapter, watch for routing and DNS conflicts, and check the actual connection path.
Mixed port
Mixed Port
mixed-port is a local listener that accepts both HTTP proxy and SOCKS connections. 7890 is a common example, not a required value. The address and port configured in apps must match the active listener. Access from other devices also depends on the listening address, allow-lan, and firewall settings; changing the port alone does not enable LAN access.
UWP loopback exemption
UWP Loopback
Network isolation can prevent some sandboxed Windows apps from accessing a proxy service on a local loopback address. This can look like a browser working while a specific app cannot connect. A loopback exemption allows a particular app to make local connections. First confirm that the app is affected by this restriction, then use the client's tool for that app. There is no need to disable all system protections.
System extension / Authorization
System Extensions and Permissions
A client may request system authorization for a virtual interface, proxy routing, or a background service, but not every client needs the same permissions. On macOS, network extensions, system extensions, and Keychain prompts grant different capabilities; they are not interchangeable. Check the app name and purpose shown in each prompt. If you deny access, use the relevant settings to restore it rather than granting every permission in response to a general connection failure.