CLASH / CONFIGURATION REFERENCE
Browse core, protocol, routing, and configuration terms across six categories. Each card explains a concept and clarifies common distinctions; share a specific entry with its glossary link.
Start by distinguishing the program that handles connections from the app that provides the user interface.
mihomo is a proxy core evolved from the Clash Meta project. It handles core functions such as connections, rule matching, and DNS. A graphical client can use mihomo, but the client and core may have different names. To check whether a setting is supported, look at the core that is actually running and its capabilities rather than relying on the app's name.
A proxy core is the program that handles connections, applies routing rules, and creates outbound connections. A graphical client may bundle a core with its installer or let you manage core updates in its settings. When troubleshooting configuration errors, core logs are often more useful than the client's connection toggle: turning it on does not mean every connection was established successfully.
A graphical client provides an interface for importing subscriptions, choosing proxy groups, viewing connection logs, and managing the system proxy, then passes a valid configuration to the core. Clients using the same core may still have different menu names and ways of saving configurations. Treat button locations in tutorials as a guide: find the corresponding feature in your client rather than expecting identical labels.
Configuration compatibility describes whether a client and core can recognize the fields, protocols, and behavior options in a configuration. A YAML file being parseable does not mean every feature in it is supported. If an import reports an unknown field, missing policy, or unsupported protocol, first confirm which core the configuration targets, then check field spelling, reference names, and feature support.
A protocol defines how a client and server communicate; it is not the same as a node name or transport method.
Shadowsocks is an encrypted proxy protocol. Its configuration typically includes a server address, port, encryption method, and password. The client and server must use compatible encryption methods, so a matching password alone does not confirm that the configuration is correct. Some nodes also require plugin parameters; enter the complete settings provided by the service when configuring them manually.
VMess is a proxy protocol that typically identifies users with a UUID and can use different transport methods. The server address, port, transport settings, and TLS options must match the server configuration. WebSocket paths and headers are transport settings, not node remarks; leaving them out can make a server reachable without allowing the proxy connection to establish.
VLESS is a lightweight proxy protocol that does not provide transport encryption on its own; it is usually deployed with TLS or mechanisms such as REALITY. It is distinct from VMess, and changing the protocol name alone cannot convert one into the other. If an import reports unsupported settings, check both the core's capabilities and the server requirements, especially the transport method, flow control, and handshake parameters.
Trojan is a proxy protocol that typically establishes an encrypted connection over TLS and uses a password for authentication. A successful connection also depends on matching the server name, certificate, and transport settings. If you encounter a certificate error, check the device clock, the configured domain, and certificate validity; disabling certificate verification should not be a routine fix.
rule, global, and direct control outbound selection; TUN controls how traffic enters the core.
Rule mode corresponds to mode: rule. The core checks incoming connections against the configured rules in order and applies the outbound policy specified by the first matching rule. Direct and proxied connections can therefore coexist. After switching to rule mode, check the selected route in your proxy group too; the mode itself does not choose a node for you.
Global mode corresponds to mode: global and sends all connections entering the core through the GLOBAL policy. It changes outbound selection within the core; it does not automatically route traffic from every app into the core. If an app bypasses the system proxy, switching to global mode alone may not help—you may also need to check how traffic enters the core.
Direct mode corresponds to mode: direct and connects traffic entering the core straight to its destination, without a remote proxy node. It is not the same as quitting the client; the core may still handle DNS and connections. To compare against your normal network, distinguish between switching to direct mode, disabling the system proxy, and stopping TUN: each affects a different part of the traffic path.
TUN mode routes traffic through a virtual network interface and can capture traffic from some apps that do not follow system proxy settings. It is a way to feed traffic into the core and can be used with rule or global mode. Enabling it usually involves system permissions, routing, and DNS interception. If another VPN is running, check for conflicts with the default route rather than repeatedly switching nodes.
Rules match traffic, policies determine how it is handled, and data collections provide reusable match conditions.
Routing rules use conditions such as domain, destination IP, or process to send connections to a direct, reject, or proxy policy. Rules are usually evaluated from top to bottom, so a broad rule near the top can take precedence over a more specific one below it. If a website is using the wrong route, check the matched rule in the connection log, then adjust its position or conditions.
A proxy group combines nodes or other policies into an outbound option that rules can reference. select lets you choose manually, while url-test and fallback select an available route using their respective checks. Rules reference the proxy group by name, so if you rename it, update all references to avoid configuration errors caused by a missing policy.
GeoIP matches a destination IP against location data from an IP database and is often used to select policies by country or region. Database results do not identify where a website operator is based and may lag behind changes in IP allocation. Domain rules and GeoIP rules match at different levels; for a website that needs a specific route, an explicit domain rule is usually the better starting point.
Rule providers define rule collections with rule-providers, which are then referenced in the rules list using RULE-SET. They make rules easier to maintain and update independently, but placement and rule order still matter. The rule set's content must match its declared behavior type; a successful download does not guarantee that it will parse or match as expected.
Name resolution, traffic interception, and connection testing are separate steps and should be checked independently.
DNS resolves domain names to records such as IP addresses, an important step before establishing a network connection. Even with core DNS enabled, check whether system and app queries actually use that resolution path. A browser's built-in encrypted DNS may use a different route, so when troubleshooting name resolution, check the client, system, and app separately.
With Fake-IP, the core returns a virtual IP to an app and keeps a mapping between that address and the domain. When the app connects to the address, the core can recover the domain and apply the appropriate routing and connection handling. This is not the website's real server IP. If an app keeps using a cached address after you switch DNS modes, reconnect it or refresh its DNS cache.
A DNS leak usually means domain queries bypass the intended resolution path and reach another DNS resolver. Opening a webpage through a proxy does not, by itself, prove that DNS queries followed the intended route. Interpret test results in light of browser encrypted DNS, the system resolver, and the client's DNS policy; seeing multiple resolvers does not necessarily indicate a configuration problem.
The latency shown by a client is usually the time taken to probe a specified test address; the exact measurement depends on the implementation. It is not download speed and does not represent the experience on every website. Compare nodes using the same test address and conditions. A timeout may also be caused by restrictions on the target service, so one failed test does not prove a node is unusable.
Before editing, understand how the file format, remote source, and local changes fit together.
YAML is a common format for Clash configuration, using key-value pairs, lists, and indentation to organize settings. Indent with spaces and align items at the same level; list items usually start with a hyphen. Avoid duplicate keys and quote values when special characters could affect parsing. Even when the syntax is valid, check that fields mean what you expect and that policy references resolve correctly.
A subscription lets a client fetch remote configuration or a node list on demand or at regular intervals. A link may return a complete configuration or just node data; whether it can be imported depends on the format and client support. Subscription links often contain personal access tokens and should be kept private. Updating a subscription does not renew it: account validity and data refresh are separate things.
A node is a set of parameters for connecting to a remote proxy service, usually including a name, protocol, address, port, and authentication details. Its display name alone does not establish its actual location, quality, or availability. After importing a node, add it to a proxy group and route the relevant traffic through that group; a node appearing in the list does not mean it is in use.
Overrides and merging let you save local changes separately from a subscription configuration and apply them when generating the active configuration. Clients may handle field replacement, list additions, and processing order differently. Editing a subscription cache directly may not survive the next update. For lasting changes, use the client's override feature and check the final active configuration.