Understand the boundaries between cores, protocols, rules, and DNS. Browse by category, then check the corresponding config fields against your client's actual settings.
Start by distinguishing the software that handles connections, the interface that manages settings, and the server details needed to connect.
The background process responsible for proxy connections, rule matching, and DNS handling. A GUI typically communicates with it through a control interface. The original Clash and later derivative cores do not support the same features, so a config labeled for Clash may not work with every core. If you encounter an unknown field or unsupported protocol, first identify the core in use rather than relying on the client name alone.
An open-source proxy core derived from the Clash Meta project, with features such as rule-based routing, TUN, domain sniffing, and rule sets. It is not a specific GUI client; different apps can integrate the same core. Older articles mentioning Meta usually refer to this core lineage, but check current core documentation for supported fields.
A desktop or mobile app for managing subscriptions, policy selection, the system proxy, and logs. It may bundle a core or provide tools to manage one. Interface options do not necessarily map one-to-one to YAML fields; some settings are written into a generated config at startup. When troubleshooting, distinguish client behavior from core behavior.
A set of server parameters for establishing a proxy connection, usually including an address, port, protocol, and authentication details, and sometimes transport settings. A node's display name is only a label; it does not guarantee the actual exit location or service availability. Installing a client does not provide nodes—you'll also need to verify the service source and protocol compatibility before importing one.
The time taken by a client using a specified test method; a typical URL test is not the same as an ICMP ping. Results depend on the test URL, timeout, connection reuse, and current network conditions. They are not a direct measure of bandwidth or browsing speed across all sites. A timed-out test does not necessarily mean the node is completely down; check actual access and connection logs too.
The protocol determines how a connection is established. Check the transport, authentication parameters, and security layer together.
A protocol that establishes a proxy connection using a pre-shared key and a specified cipher. In mihomo node configs, it is written as type: ss. The client and server must use matching cipher and key settings, and different ciphers may require different key formats. If the node relies on a plugin, check that the client supports it and its required parameters.
A protocol that typically carries proxy traffic over a TLS connection and uses password authentication. A successful connection depends on more than the password: certificates, the server name, and transport settings also matter. If you see a certificate error, check the system clock and server settings rather than treating certificate verification bypass as a routine fix.
A lightweight proxy protocol that typically identifies users with a UUID. It does not encrypt traffic on its own, so its configuration must be understood alongside security layers such as TLS or REALITY. A matching UUID does not guarantee a valid configuration; the transport, server name, and related security parameters must also match. Keep the full set of parameters provided by the service when importing a node.
A QUIC-based proxy protocol that requires UDP connectivity and uses TLS and authentication parameters to establish a connection. It may not work on networks that restrict UDP; an open server port alone does not prove it is usable. Performance depends on network conditions and configuration, not just the protocol name.
A general-purpose protocol for connecting applications to proxy servers. It can be used as a local proxy listener or as a remote node type. It supports TCP and UDP forwarding, but the application, listener, and outbound connection must all support the intended mode. SOCKS5 does not encrypt traffic; whether domain names are resolved locally or by the proxy also depends on how the application uses it.
Rules determine which connections match; policy groups determine which outbound route to use.
In Rule mode, the core checks connections against the rules list from top to bottom. The first matching rule determines the policy. For example, DOMAIN-SUFFIX,github.com,Proxy sends matching domains to the policy named Proxy. Proxy must be defined separately, and MATCH,Proxy is typically placed last to handle remaining connections.
Groups that organize nodes or other policies for rules to reference, so each rule does not have to point directly to a single node. Use select for manual selection, url-test for periodic testing and selection based on results, and fallback to use available members in order. The test URL and interval affect automatic selection; the group name itself does not determine its behavior.
These modes determine how connections that have reached the core are handled. Rule selects a policy based on rules, Global uses the global policy, and Direct connects to the destination directly. These modes do not route application traffic into the core; check separately whether the system proxy or TUN is enabled.
Matches destination addresses against an IP geolocation database. For example, GEOIP,CN,DIRECT sends addresses classified as CN by the database direct. This classification does not indicate domain registration location, or actual operating location; CDNs can also affect resolution. Matching a domain connection may require DNS resolution; adding no-resolve to the end of a rule can prevent that lookup from being triggered.
Store matching conditions separately by declaring them with rule-providers, then referencing them in a rule such as RULE-SET,work,Proxy. The set defines what to match; the rule that references it specifies the final policy. If an update fails, check the format and whether behavior matches it. A node subscription cannot be used as a rule set.
DNS resolution, traffic capture, and outbound routing are related steps, but they are not interchangeable.
DNS resolves domain names to IP addresses, commonly before an application connects. In mihomo, nameserver specifies upstream resolvers, while nameserver-policy can choose different resolvers for specific domains. Encrypted DNS protects traffic only between you and the resolver; it does not guarantee that queries use the selected proxy route.
This DNS mode returns virtual addresses to applications while the core keeps a mapping between each address and its domain, helping rules match by domain later. These are not the website's real addresses, and the mode does not route traffic into the core on its own. If an application requires real DNS results, adjust fake-ip-filter as needed rather than expanding exclusions indiscriminately.
Receives system IP traffic through a virtual network interface, allowing some apps that ignore the system proxy to be handled by the core. Commonly configured with fields such as tun.enable, auto-route, and dns-hijack, and may require administrator privileges. The traffic captured still depends on routing, DNS, the operating system, and other networking software.
DNS queries do not follow the intended resolver path or outbound route—for example, a browser's built-in resolver may bypass the planned system path. A resolver's region on a test page does not prove a leak by itself; check the target policy and logs. Troubleshooting should include browser secure DNS, system resolution, TUN capture, and the core's upstream settings.
Attempts to identify domains from supported TLS, HTTP, or QUIC handshake information, adding matchable domain details to connections that only have an IP address. It is not a general-purpose way to decrypt encrypted content, and it cannot identify every connection. Sniffing may affect rule matching or destination handling, so check connection logs after enabling it.
Distinguish data sources, file formats, and the final runtime config to reduce the risk of settings being overwritten during updates.
A way to distribute and update node lists or complete configurations through a link. Content may be a URI list, encoded text, or YAML, so the link's appearance alone does not reveal its format. Direct import depends on the formats and protocols supported by the client. Subscription URLs often contain access credentials; do not post them publicly in screenshots or logs, or share them with untrusted conversion services.
A text data format for organizing mappings, lists, and scalars, commonly used to represent the hierarchy in Clash configs. Use spaces rather than tabs for indentation and align fields at the same level; quote strings containing special characters. Valid YAML syntax does not guarantee a usable config: the core must still support its fields and resolve policy references.
A file describing settings such as ports, nodes, policy groups, DNS, and rules. config.yaml is a common filename, not a required one. The config ultimately passed to the core may be generated from a subscription, client settings, and overrides. If a field has no effect, inspect the active runtime config rather than only the original downloaded subscription.
A collection of nodes defined by proxy-providers and loaded from a file or remote URL. Policy groups reference it with use. It stores nodes, unlike rule-providers, which stores matching conditions. Provider updates, health checks, and policy group selection are separate steps; a successful update does not mean every node can connect.
A mechanism for retaining local changes outside a subscription and including them in the generated config, often used to set fixed ports or DNS settings, or add rules. Overrides are not a single core field shared by all clients; merge order, list additions, and field replacement depend on the client. After making changes, inspect the generated result to ensure rule order and policy group references have not changed during an update.
Import a subscription for the first time? Follow the guide to verify your connection. If you're already connected but need to adjust rules, DNS, or TUN, see the advanced configuration guide. For a specific error, note the client name, actual core, and error text instead of reporting only that “Clash isn't working.”