Browse common terms for clients, proxy protocols, and YAML configurations across five categories. First understand how traffic reaches the core, then how rules choose an outbound route. These are separate concerns and should be troubleshot separately.
Each glossary card has its own anchor, so you can copy its link for discussion. Field behavior depends on the client, core version, and final effective configuration.
The interface handles controls, the core handles connections, and subscriptions provide configuration data. If importing succeeds but access fails, first identify which layer is causing the problem.
In everyday use, a client usually means a graphical app for importing subscriptions, switching policies, and managing the system proxy. The core running inside it handles connections and rule matching, and the same core can be used with different interfaces. When choosing a client, consider operating-system support, permissions, and core compatibility—not just how many toggles the interface offers.
mihomo is a proxy core in the Clash ecosystem. It handles incoming connections, DNS resolution, rule matching, and outbound connections, and was widely known as Clash.Meta. In older guides, Meta usually refers to this core lineage, not necessarily a particular graphical client. Check that configuration fields are supported by your current core; updating the interface does not always update the core too.
A subscription is usually a link for retrieving a list of nodes or a complete configuration, which the client can refresh on demand or on a schedule. Links may return different data formats, so check that the format is supported by Clash or your client before importing. Subscription URLs may contain account identifiers or access tokens; don't post them publicly. If an update fails, see subscription issues.
A proxy node is a set of outbound connection parameters, typically including a server address, port, protocol, authentication details, and optional transport settings. The node name is only a label; a region in the name does not necessarily reflect the actual exit location or server location. Importing a node adds a possible outbound route, but a policy group must reference it and app traffic must reach the core.
A client's latency test usually measures how long a request sent through a node takes to reach a specified test address; it may not send a ping directly to the server. Results depend on the test address, timeout, connection reuse, and local network. Lower latency does not directly translate to faster downloads or guarantee access to every site. Compare nodes under the same test conditions and check them against your actual use cases.
A protocol defines how the client communicates with the proxy server. Check support in the core actually in use, and make sure the server settings match even when the protocol name is correct.
An HTTP proxy accepts requests using the HTTP proxy mechanism and typically uses CONNECT to create a tunnel for HTTPS destinations. Local clients often provide an HTTP proxy listener for browsers and command-line tools. An HTTPS destination does not mean TLS is enabled on the connection between the client and proxy server; check encryption on each leg separately.
SOCKS5 is a general-purpose proxy protocol that supports TCP and can relay UDP when both client and server implementations support it. It does not encrypt traffic in transit, and username/password authentication is not a substitute for encryption. Whether an app resolves domain names locally or through the proxy depends on the app and its settings; the proxy address alone does not reveal the DNS path.
Shadowsocks is an encrypted proxy protocol. Configurations usually include a server, port, encryption method, and password. The encryption method and any extended parameters must match the server, and support can vary across protocol generations and implementations. If authentication or handshakes fail, first check the imported settings and core compatibility; renaming a node does not change its connection parameters.
Trojan typically uses TLS to protect proxy connections. Along with the server and password, certificate and server-name settings must be configured correctly. The connection address may differ from the domain on the certificate, but both must match the server's deployment. For certificate errors, check the system time, domain, and certificate chain first; disabling certificate verification is not a suitable long-term fix.
Hysteria 2 is a QUIC-based proxy protocol that relies on UDP, and both the client and server need to support it. If the current network blocks UDP, the availability of other TCP nodes does not mean Hysteria 2 will work. The protocol name does not guarantee speed; performance also depends on the route, congestion control, and server resources. Check authentication details and TLS settings when configuring it.
First identify the connection mode, then check which rule matched and which policy was ultimately selected. If a node works but traffic takes an unexpected route, start here.
Rule-based routing checks connection details such as the domain, destination IP, and port in configuration order. The first matching rule determines the policy. Specific domain rules generally go before broader rules, with a catch-all rule at the end. If a rule matches a policy group, that group still selects the actual outbound route. When reviewing logs, check both the matched rule and the final outbound—not just the node name.
Rule mode selects policies based on rules, Global mode typically sends all captured connections to the global policy, and Direct mode routes them directly. These modes control what happens after traffic reaches the core; they do not make every app send traffic to it. If access still fails in Global mode, first verify that the system proxy or TUN capture is working. See proxy mode settings.
A policy group combines multiple nodes or other policies into a selectable outbound route. Common types include manual selection with select, choosing based on test results with url-test, and switching based on availability with fallback. Automated tests reflect only their test conditions and do not guarantee how an app will perform. If rules reference a policy group by name, the spelling must match exactly.
GeoIP uses an IP geolocation database for matching. For example, GEOIP,CN,DIRECT sends destinations assigned to that region to the Direct policy. Results depend on the database and the destination IP; they do not identify the site's operator or the region its content belongs to. CDNs and shared infrastructure can affect geolocation, so domain rules are usually a better choice when you need precise control over a site's route.
MATCH handles connections that did not match any earlier rule. It usually goes at the end of the rules list. For example, MATCH,Proxy sends those connections to the policy named Proxy, provided the configuration defines a policy with that name. If MATCH appears earlier in the list, later ordinary rules will never get a chance to match.
System proxy, TUN, and DNS settings each have their own scope. An enabled toggle only confirms that a feature is configured; verify the actual traffic path with a connection test.
DNS resolves domain names to records such as IP addresses, an important step before an app can connect. In a proxy setup, app queries, core lookups, and proxy-server hostname resolution may follow different paths; one DNS toggle does not describe them all. If a domain fails but its IP address works, first identify which layer's resolution is failing, then see DNS configuration fields.
Fake-IP assigns virtual addresses to domain names and maintains a mapping, allowing connections that later reach the core to be associated with their original domains for rule-based routing. The virtual address shown to an app is not the destination website's real address and does not indicate a problem with the site. Some apps and local network services may need exceptions. If old resolution results persist after changing modes, consider clearing the relevant DNS cache.
View Fake-IP settings →A DNS leak usually means domain queries are taking an unintended path—for example, queries that were supposed to use a controlled resolver are sent directly to another resolver by the system or app. To determine whether a leak is occurring, first define the expected policy; a location shown by a test page alone is not enough. Check browser-level DNS, system resolution, IPv6, and TUN capture scope to determine where queries originate.
The system proxy is an operating-system setting that clients typically point to a local listening address and port. Only apps that honor this setting use it; some command-line tools, games, and background services use their own network settings. So a working browser and a nonworking terminal are not contradictory. Check whether the tool needs proxy options or environment variables instead of repeatedly switching nodes.
TUN mode uses a virtual network interface and routing settings to capture IP traffic, including traffic from apps that ignore the system proxy. It usually requires appropriate permissions and may conflict with other VPNs, virtual adapters, or routing rules. Enabling TUN does not mean every connection is proxied or that DNS follows the expected path. The final outbound route still depends on the capture scope, proxy mode, and routing rules.
This section explains what each field does and where its limits are. For complete examples, indentation, and rule syntax, see the YAML guide. Before making changes, keep a restorable copy of the original configuration.
YAML is a common format for Clash configurations. It uses spaces for indentation and hyphens for list items; tabs cannot be used for indentation. Quote strings containing special characters according to YAML syntax, and preserve the original nesting when copying examples. Passing a syntax parser only means the structure is readable; the core still needs to check whether fields are supported and referenced policies exist.
mixed-port sets a local mixed listener that accepts both HTTP and SOCKS proxy connections on the same port. It is not the port of a remote node, and changing it does not change the node's server settings. If an app has a manually configured proxy address, update its port there too. Whether other devices can connect also depends on the listening address, firewall, and LAN access settings.
proxy-providers defines the source and update method for a proxy collection, allowing the node list to be maintained separately from the main configuration. Policy groups typically reference the collection with use; updating the node collection does not replace the entire configuration. Check that provider names, policy group references, and returned data formats all match. If the download succeeds but the group has no nodes, check the references next.
rule-providers defines reusable rule collections, useful for keeping long domain or IP lists separate from the main configuration. The collection's behavior type must match its file format. A RULE-SET rule then typically specifies which collection to use and which policy to apply. Defining a rule provider without referencing it does not make its rules take effect.
Overrides and merging apply local changes on top of a subscription configuration, for example to preserve custom DNS, ports, or rules. Clients may handle object merging, list replacement, and processing order differently, so the same snippet may not work everywhere. Don't rely only on the source shown in the editor; check the final effective configuration. After subscription updates, confirm that your custom changes are still applied as expected.