Look up terms by topic, from proxies and configuration imported through subscriptions to DNS and proxy groups used for rule-based routing. These definitions explain settings; exact menus, fields, and support depend on the core used by your client.
The protocol defines how a client communicates with a server. Transport and encryption may be configured separately. Even when protocol names match, check each setting rather than changing only the protocol label.
A proxy protocol that forwards traffic using a shared key and a specified encryption method. Connection settings typically include the server, port, password, and encryption method. The client and server must use matching encryption methods, and SS 2022 uses a different key format from older versions. If the configuration includes a plugin, check that the core supports it and its parameters; do not simply discard the plugin settings.
A proxy protocol from the V2Ray ecosystem that identifies users with a UUID and uses time-sensitive authentication checks. WebSocket, TLS, paths, and hostnames in a subscription are additional connection settings, not options you can omit after entering the UUID. For authentication or handshake errors, check these parameters and make sure the device clock is accurate.
A protocol that typically carries proxy traffic over TLS and uses password authentication. The server address, certificate name, and client SNI setting can all affect the handshake. For certificate errors, first check the domain, system time, and certificate chain. Avoid disabling certificate verification as a long-term fix; support for additional transports depends on the core.
A lightweight proxy protocol that separates authentication from transport security, often used with TLS or REALITY. The name VLESS alone does not mean the connection is fully encrypted. Preserve the transport type, server name, flow, and related verification parameters when importing. An older core may recognize VLESS but not support a particular combination used by the subscription, causing the connection to fail.
A QUIC-based proxy protocol that carries connections over UDP and is designed with throughput and performance on unstable networks in mind. Actual results depend on UDP reachability, server capacity, network congestion, and bandwidth settings; the protocol name alone does not guarantee speed. Hysteria 2 differs from the first generation in both protocol and configuration, so changing only the type name will not migrate a setup.
A QUIC-based proxy protocol that uses multiplexing to carry connections and provides settings related to UDP forwarding. The client and server must use compatible protocol versions, and authentication and congestion-control parameters must match the server's requirements. If the network restricts UDP, changing the proxy name usually will not help; check the underlying connection first.
For protocol resource usage and use cases, see Protocol and Core Technical Reference.
The client provides the controls; the core handles the network logic. To determine whether a protocol or configuration will work, check both the app's interface and the core it actually runs.
An application with an interface for importing subscriptions, selecting proxies, setting the system proxy, and viewing logs. Some clients also manage the core process and background services. Even clients using the same core may merge, override, or filter configuration. Menu names in a guide may not match exactly, so distinguish values saved in the interface from those loaded by the core when troubleshooting.
The program that establishes connections and handles protocols, DNS queries, and rule matching. It may be managed by a graphical client or run independently. Whether a configuration loads depends mainly on the core's supported fields and protocols, as well as the runtime environment. Updating the app interface does not necessarily update the core. If you encounter unknown fields or unsupported proxy types, check which core is actually running.
The core name used by the project that followed Clash.Meta. It retains Clash-style YAML configuration and extends protocol, rule, DNS, and traffic-capture capabilities. It is a core, not a client with a fixed interface, and different apps can bundle it. After migrating an older configuration, check the logs and field meanings; do not assume mihomo's newer features are recognized by the original or other older cores.
Usually refers to the Clash.Meta core branch and its historical names, part of the project's lineage leading to mihomo. The term also appears as an ecosystem label in app names and older guides. A client with Meta in its name does not necessarily use the same core build or expose every setting. When comparing documentation, check the running core's name, feature support, and configuration syntax.
A configuration file describes settings such as listening ports, proxies, proxy groups, rules, and DNS. Whether it can be parsed, establish connections, and route traffic as expected are three separate things to verify.
A structured text format commonly used for Clash configuration, using indentation to define hierarchy and colons and list markers to organize data. Use spaces for indentation, quote strings with special characters where needed, and keep fields at the correct level. Valid YAML syntax only means the text can be parsed; the core must still validate field types, proxy group names, and rule references.
Chooses direct access, a block, or a proxy group for each connection based on criteria such as domain, IP, or process. Rules are usually matched from top to bottom: DOMAIN-SUFFIX matches a domain suffix, while MATCH provides a final catch-all. If a broad rule comes before an exception, the exception may never take effect. The connection panel's matched rule is more useful than checking only the selected proxy.
Combines proxies or other proxy groups into a single outbound option for use by routing rules. select lets you choose manually; url-test picks based on test results; fallback checks options in order for an available one; and load-balance distributes connections according to its strategy. Automatic policies depend on the test URL and interval. A change usually affects new connections and does not guarantee that existing connections will move.
Separates a set of match conditions into an independent source, declared with rule-providers and referenced by a RULE-SET rule. The rule set supplies the conditions; the rule that references it specifies the outbound policy. Updating a rule set does not replace the full configuration. The source format and behavior must be supported by the core. Even after a successful download, check that the set was loaded and referenced.
GeoIP provides classification data such as region for IP addresses, while GeoSite groups domains by site or purpose. They can be used with GEOIP and GEOSITE matching, respectively. Classification depends on the data source, format, and update status; it is not definitive proof of a server's actual location or ownership. Collections with similar names may contain different entries, so choose labels based on the data source in use.
First distinguish how traffic reaches the core, then look at how domains are resolved. System proxy settings, TUN, and DNS modes operate at different stages; enabling one does not automatically fix issues at the others.
Uses the operating system's proxy settings to send connections from apps that honor them to a local proxy port. It does not capture all network traffic on the device. Some games, command-line tools, and apps with their own network stacks may ignore it. If a browser works but other apps still connect directly, first check whether those apps support proxies. After closing the client, check that the system settings have been restored.
Captures IP packets through a virtual network interface and routing, then passes them to the proxy core. This is useful for apps that do not honor the system proxy. TUN usually requires additional permissions or a background service, and involves choices for routing, DNS, and the network stack. TUN and rule mode are not mutually exclusive: TUN determines how traffic enters the core; rules determine its outbound route. Watch for conflicts with other virtual network adapters.
A lookup system that translates domain names into addresses and other records. Name resolution usually happens before a connection to a service. Who sends the query, which resolver handles it, and how the resolver connects are separate from the route used by the service connection. Browser-level encrypted DNS, system cache, and app-level resolution can all change the result, so troubleshooting should not stop at the single DNS address in the configuration.
Returns synthetic addresses to apps and stores a mapping between each address and its original domain in the core, allowing later connections to match rules by domain. The address shown to an app may not be the target server's real address; this does not by itself mean resolution failed. Some apps that rely on real addresses may need an exception in fake-ip-filter. Watch for stale DNS cache entries after switching modes.
When domain queries do not follow the expected resolution path—for example, the connection uses a proxy while DNS queries take another route. Whether this is expected depends on routing targets, how the app resolves names, and the resolver's connection path. A test page's reported resolver location is not conclusive; also check browser encrypted DNS, system resolution settings, and core logs.
Accepts both HTTP and SOCKS proxy connections on the same local listening port, configured with mixed-port. The commonly used 7890 in tutorials is only an example; you can change it. The address and port set in an app must match the actual listener. If you allow LAN access, also check the listening address, authentication, and firewall. Do not expose a proxy port directly to the public internet.
A subscription provides a way to obtain a configuration or proxies; a proxy is a set of connection parameters; and a test result is an observation under specific conditions. Check each separately—one speed test is not a substitute for verifying the full connection.
A way to fetch and update a proxy list or full configuration from a URL; it is not a single, fixed protocol. Base64 proxy lists, Clash YAML configurations, and formats for other clients are not necessarily interchangeable, so first check which formats the receiving client supports. Subscription URLs may contain account details; do not share them publicly or submit them to untrusted conversion services. If an update fails, check the error type first.
A set of parameters describing a remote proxy service, usually including the server address, port, protocol, authentication details, and optional transport settings. The displayed name is only a label; it does not prove the server's location, exit location, or available bandwidth. A client successfully reading the parameters does not guarantee the service is available. Check the handshake, authentication, and access from the target app.
A client measures connection time to a specified test address, often by establishing a proxy connection and making an HTTP request. This is not necessarily an ICMP ping. Results depend on the test target, timeout, connection reuse, and network conditions; a lower number does not mean faster downloads. A timeout only means that test did not finish in time. Use logs and real-world access to narrow down the issue.
A source of proxies declared with proxy-providers. It can come from a file or remote URL and be referenced by proxy groups. This separates proxy updates from the main configuration: updating a provider usually refreshes proxy entries, not the rules or DNS settings in the main configuration. A full configuration subscription and a proxy provider file have different structures; entering one URL in the other's import field does not make them compatible.