Browse 24 common terms by function, from kernels and connection protocols to configuration files. Identify each term's role, then compare it with client settings or runtime logs to distinguish DNS resolution issues from connection problems.
For step-by-step instructions, read the Getting Started Guide. For platform-specific permissions, installation, and network settings, see the Cross-Platform Guide.
The interface provides controls; the kernel handles connections. Check both when troubleshooting compatibility.
Proxy engine · formerly Clash Meta
mihomo is the project name used after Clash Meta. It handles configuration parsing, rule matching, proxy connections, and DNS. It can run independently or be launched and managed by a graphical client. The same client interface may use different kernel builds, so check the running kernel's support before relying on a protocol or configuration field.
Read the kernel and platform configuration guide →Graphical client
A Clash client typically provides a graphical interface for the kernel, with features such as importing subscriptions, switching proxy groups, viewing logs, and setting the system proxy. The client and kernel are different components, and the interface may not expose every kernel capability. When choosing a client, check operating system support, configuration compatibility, and permission management—not just appearance.
See the client selection guide →Proxy endpoint
A node is a set of proxy connection parameters, typically including a server address, port, protocol, authentication details, and transport settings. Its display name is just a label; it does not verify the server's location, route quality, or available bandwidth. Successfully loading a node only means its configuration could be read. Test the connection and try accessing a service to confirm it works.
URL Test · request timing
Clients often measure latency by accessing a specified test address through a node and displaying the time taken. The result may include connection setup, protocol handshake, and target response time, so it is not the same as an ICMP ping. Low latency does not guarantee high download speeds. Compare nodes using the same test address, and consider packet loss, repeated access, and real-world transfer performance.
Learn how latency tests work →A protocol defines how a client and server exchange data. Identify the protocol, transport method, and encryption layer separately.
Encrypted proxy protocol
Shadowsocks carries proxy traffic between a client and server using a shared secret and a specified encryption method. The encryption method, password, and related protocol settings must match the server. An address and port alone are not enough to establish a connection. Encryption methods vary in support and overhead; being able to import an older configuration does not mean the current kernel supports every option in it.
V2Ray protocol
VMess is a proxy protocol in the V2Ray ecosystem. It commonly identifies users with a UUID and can use different transport methods. WebSocket, TLS, and VMess operate at different layers, so align protocol authentication, transport path, and server name separately. Some authentication flows depend on accurate system time, so check the clock and server settings if a handshake fails.
Lightweight proxy protocol
VLESS is a lightweight proxy protocol that uses UUID authentication but does not provide a general-purpose payload encryption layer. Connections commonly use TLS or REALITY settings. The server's flow control, transport method, and security parameters must all match. Changing the type name in a VMess configuration to VLESS does not convert it; the protocols have different structures and requirements.
TLS-based proxy protocol
Trojan typically carries proxy traffic over TLS and authenticates with a password. Along with the password, check that the server name matches and the certificate is valid and trusted. Skipping certificate verification changes the security boundary and should not be the default response to a handshake failure. First check the system clock, domain settings, and server certificate.
Rules determine the route a connection takes; proxy groups determine which node that route uses. Rule order and group names are both part of the configuration.
Rule-based routing
Rule-based routing selects a direct, proxy, or reject policy based on criteria such as domain, destination IP, or process. Rules are usually checked from top to bottom, and the first match wins, so specific exceptions should come before broader rules. After editing rules, check the connection details to see which rule matched. Looking only at the exit IP often cannot explain why an app still uses its previous route.
See rule syntax and priority →Proxy group
A proxy group gives multiple nodes or policies a shared name that rules can reference instead of specifying a node each time. Common types include select for manual selection, url-test for choosing based on test results, and fallback for switching when a node is unavailable. Automatic selection is not guaranteed to be faster for every use case. Check the group members, test address, and switching conditions together.
Built-in policies and configured names
DIRECT is a built-in direct policy: it connects to the destination without a proxy server. REJECT rejects matching connections. PROXY is usually just a user-defined proxy group name, not a built-in policy available in every configuration. Group names referenced by rules must exactly match their definitions; differences in capitalization, spacing, or renaming can cause the configuration to fail to load.
Catch-all rule
MATCH matches every remaining connection not handled by an earlier rule, and is usually the catch-all at the end of the rule list. For example, MATCH,DIRECT sends the remaining connections directly; choose the policy that fits the configuration. If MATCH is placed first, later, more specific rules usually never get a chance to match. Check its position first when troubleshooting routing issues.
IP geography and domain categories
GeoIP provides IP-based location categories, while GeoSite provides domain categories. Both are used for rule matching, not as sources of proxy nodes. Categories can change with the data source and update schedule, and do not indicate a user's or server's precise physical location. Check that the kernel supports the data format, the files loaded successfully, and earlier rules are not overriding the relevant rules.
Check database updates and rule syntax →Traffic routing and domain resolution are related but distinct paths. Even with a proxy enabled, check which path each app actually uses.
Virtual network interface
TUN mode receives IP traffic through a virtual network interface and passes it to the kernel for routing and connection handling. Compared with the system proxy, it can cover more apps that ignore system proxy settings, but actual coverage still depends on routing, exclusions, and platform support. Enabling it usually requires appropriate permissions. Check for conflicts with other VPNs, virtual network adapters, and local network access rules.
Read the TUN setup guide for each platform →Operating system proxy settings
The system proxy points the operating system's proxy settings to the client's local listening address and port, for apps that honor those settings. It does not create a tunnel for every network connection; some games, command-line tools, and apps with their own network stacks may ignore these settings. If the client exits but leaves the proxy enabled while its listening port is closed, the browser may be unable to connect.
Domain Name System
DNS resolves domain names to records such as IP addresses; a successful resolution usually comes before the connection to the destination. Browsers' secure DNS, the system resolver, and the kernel's DNS may all be active, so changing a DNS option in the client may not change every app's query path. When troubleshooting, distinguish a resolution failure from an unsuitable returned address or a failed destination connection; each requires different steps.
Synthetic address mapping
Fake-IP returns a synthetic address for a queried domain and stores the address-to-domain mapping in the kernel. When a connection reaches the kernel, it can use that mapping to recover the domain before routing and connecting, rather than treating the synthetic address as the website's real IP. Apps that rely on real DNS results may need exceptions. After switching DNS modes, remember that the system or an app may still have old results cached.
DNS query path leakage
A DNS leak typically occurs when queries bypass the intended resolution path—for example, when an app queries another resolver directly instead of sending queries through the proxy as planned. Check where queries actually go, what transport they use, and whether that matches expectations; the exit IP alone is not enough to tell. Encrypted DNS protects a particular transport segment but does not automatically route queries through a proxy. Check browser settings, system routing, and kernel logs together.
Browse network troubleshooting FAQs →Subscriptions distribute configuration; configuration files define behavior. A successful import, valid syntax, and working connection are three separate checks.
Subscription URL
A subscription uses a URL to fetch and update node information or a full configuration, and its contents may not work with every client. The URL may contain access credentials, so hide it before sharing screenshots, logs, or support requests. Updates may overwrite local edits. Put custom rules in a client-supported override or merge mechanism, then check the result after updating.
See the subscription import steps →YAML configuration format
YAML is a structured text format commonly used for Clash configuration. It uses indentation for hierarchy and lists and mappings to organize parameters. Use spaces, not tabs, for indentation, and quote values containing special characters according to YAML syntax. A successful parse only confirms the text structure is valid; the current kernel must still check whether fields are supported and referenced proxy groups exist.
Runtime configuration file
config.yaml is a common configuration filename for proxy kernels. It can define listening ports, nodes, proxy groups, rules, and DNS settings. A graphical client may merge subscriptions, overrides, and interface settings into a separate runtime configuration, so the file being edited may not be the one the kernel ultimately reads. If changes have no effect, verify the active configuration, save status, and reload result instead of repeatedly editing the same field.
Subscription conversion
Subscription conversion reformats node information or an existing configuration for another client, and may add proxy groups and rule templates. It cannot add support for a protocol the kernel does not support, or supply required parameters missing from the source. A remote conversion service may have access to the subscription URL and node credentials, so check what data it handles first. If the configuration is already compatible, try importing it directly.
External proxy providers
proxy-providers declares a collection of nodes from a remote or local source, keeping node updates separate from maintenance of the main configuration. After loading, a proxy group usually needs to reference the provider with use for its nodes to appear among the available choices. A successful provider download does not mean its nodes can connect; check the content format, reference name, and node test results separately.
External rule providers
rule-providers declares an external rule set. Use RULE-SET in the main rule list to specify where it applies and which policy to use. The set's content must match the declared behavior and format; a domain list cannot be treated as a rule set in any arbitrary format. Even when the contents of a rule set are updated, its position in the main list still determines whether it matches a connection.