Browse terms by configuration layer, from subscription import to network access. Protocols define how clients connect to servers; the core applies configuration; rules select connection policies; and system proxy or TUN determines how app traffic reaches the core.
These concepts are related but not interchangeable: importing a subscription does not enable system integration, and switching nodes does not change routing rules. Each definition explains a term's purpose, requirements, and common misconceptions. For actual support, check the client and core currently running.
A protocol name describes how a connection and authentication work; it is not a speed rating. When choosing a node, also check server settings, transport, TLS configuration, and support in your core.
Shadowsocks forwards connections using a shared secret and a specified encryption method. Common node fields include the server address, port, password, and encryption method. The client and server must use the same method, and traditional implementations have different requirements from Shadowsocks 2022. Check core support for any plugins or protocol extensions separately; an SS label alone does not guarantee that a node can be imported.
Compare proxy protocols →VMess comes from the V2Ray ecosystem and typically identifies users with a UUID, with its own authentication and transport protection mechanisms. VMess nodes can still use different transports and TLS settings, so a correct address does not mean other fields can be omitted. Some authentication methods require accurate system time. If authentication fails, first check the device clock and the parameters supplied with the subscription.
Compare protocol differences →Trojan typically uses TLS to protect traffic between the client and server, with password-based authentication. The server name and certificate trust affect the handshake, so check the server address, SNI, and password separately. Rather than bypassing certificate verification, check that the name matches, the device clock is correct, and the certificate chain is trusted.
TLS and protocol guide →VLESS uses a streamlined authentication structure and typically identifies users with a UUID, but the protocol does not encrypt traffic on its own. Security and compatibility depend on related settings such as TLS, REALITY, transport, and flow. If import fails, check whether the current core supports that combination instead of comparing node names alone; settings must match the server configuration.
Check core compatibility →Hysteria2 is based on QUIC, relies on a working UDP path, and offers bandwidth-related congestion control settings. It may behave differently from TCP-based options on some high-loss networks, but speed still depends on server capacity, link quality, and configuration. UDP blocking or unsuitable bandwidth settings can cause failures or instability. On mobile, consider actual battery usage as well.
Compare options by use case →TUIC is also built on QUIC and supports connection multiplexing and UDP forwarding. Check the protocol version and authentication fields used by the server, as well as the format supported by the client core; do not mix parameters from different versions. TUIC relies on UDP reachability. When testing a node, check whether the target app works rather than relying on a single connectivity test.
Compare QUIC protocols →The client interface, runtime core, and configuration file are separate layers. To troubleshoot compatibility, first identify the core actually loaded, then check whether it supports the configuration syntax and feature fields in use.
The proxy core reads configuration, opens local listening ports, matches rules, handles DNS, and connects to proxy servers. The graphical client typically manages subscriptions, settings, and runtime controls; its toggles must ultimately map to configuration the core can understand. Similar-looking clients may use different cores, so check the actual core information to confirm protocol support.
Explore core family relationships →mihomo is a proxy core that evolved from the Clash Meta project, with support for rule-based routing, DNS, TUN, and multiple proxy protocols. It inherits aspects of the original Clash configuration, but other cores are not guaranteed to recognize its extended fields. When a subscription uses a newer protocol or a specific DNS option, check the documentation for the version actually running rather than inferring support from the client name.
Check mihomo configuration compatibility →Clash Meta was the former project name for an extended core in the Clash ecosystem; its successor project uses the name mihomo. Older guides and client names may still say Meta. The name does not reveal the software's current core version or whether the client is still being updated. When reading documentation, distinguish the former project name, the graphical client, and the runtime core.
Understand name and feature differences →YAML is a data format that uses indentation to represent structure, and Clash configurations commonly use it to define ports, nodes, policy groups, and rules. Use spaces for indentation and follow the required syntax for lists and key-value structures; quote strings containing special characters when needed. Passing YAML parsing only confirms that the structure is valid—the core must still check field names, values, and references.
See how to import a configuration →config.yaml is a common configuration filename. A file typically combines local listeners, proxy nodes, policy groups, DNS, and routing rules, though the actual filename can vary. A client may merge local overrides with the original subscription, so the runtime configuration may differ from the downloaded content. Before editing, distinguish the source configuration from generated files, or a subscription update may overwrite your changes.
Rules determine which policy a connection uses; policy groups then determine the specific node. When checking logs, review both the matched rule and the final policy used for a clearer diagnosis than checking the proxy toggle alone.
Rule-based routing selects how to handle connections based on conditions such as domain, IP address, or process, usually in rule mode. Rules are generally checked from top to bottom, and the first applicable match determines the route, so specific matches should come before broad ones. DIRECT means connect directly; REJECT means block the connection. PROXY is often the name of a policy group defined in the configuration, not an automatically available built-in group.
Check rule order and policies →GeoIP uses a database to assign IP addresses to country or region categories. For example, GEOIP,CN,DIRECT sends addresses matching the CN category directly. Database records are not precise measurements of physical location, and results can change as IP allocations and data are updated. If the destination is a domain, IP-based rules may also depend on DNS resolution, so consider DNS settings when interpreting matches.
GeoSite is a collection of domains grouped by service, purpose, or region for category-based matching. Unlike GeoIP, which matches IP addresses by region, GeoSite matches domains; the meaning of each label depends on the data source. Before using these rules, confirm that the core supports them, the data file is available, and the label exists. Category names are not a universal standard across data sources.
Explore domain rule references →MATCH catches connections that have not matched an earlier rule and is usually placed at the end of the rule list. For example, MATCH,PROXY sends remaining connections to the policy named PROXY, if that policy is defined in the configuration. If the catch-all rule appears too early, later rules cannot match. When troubleshooting unexpected routing, check its position and target policy first.
Policy groups combine nodes or other policies into a selectable entry that rules can reference; the configuration defines the group name. select is typically for manual selection, url-test selects automatically based on test results, and fallback switches to another option according to the configured order. Selecting a node in a group does not route every connection through it—only connections matched to that group use the selected option.
A subscription provides updated content, a node holds connection parameters, and a test result is a snapshot in time. Check each separately to distinguish a download failure from incompatible settings or an unavailable connection.
A subscription typically uses a link to retrieve and update nodes or configuration. The response may contain a complete YAML configuration or just a node list. The client must recognize the format, and the configuration must be selected or enabled after downloading to take effect. The link may contain credentials, so protect it like a password and hide the full URL in screenshots or logs shared with others.
Import a subscription link →A node is a set of parameters needed to connect to a proxy server, typically including its address, port, protocol, and authentication details, with possible TLS and transport settings. Its display name is only a label; a region name does not guarantee the actual location of the entry or exit point. When choosing a node, also check protocol compatibility, service availability, and how the target app performs—don't rely on the name alone.
Choose and connect to a node →A client's node latency usually measures the time taken to reach a specified test target through the node; whether the test includes a handshake or connection reuse depends on the implementation. This value is not available bandwidth and does not predict video, download, or gaming performance. Results may also change with the test target. A timeout means the test did not complete as expected; check logs and real-world access to distinguish authentication, DNS, and network issues.
Understand node speed tests →proxy-providers is a mihomo configuration field for loading an external collection of nodes from a remote URL or local file. Policy groups typically reference it with use, keeping node updates separate from local policies and rules. Provider files must use a supported node-collection format; do not assume any full subscription will work as-is. Check the update interval and cache separately.
System proxy and TUN handle how traffic enters the core; rule mode determines how traffic is routed after it gets there. DNS affects how domain names resolve to addresses, so check it alongside the traffic entry point and routing.
TUN mode receives IP packets through a virtual network interface and passes them to the core for processing and routing. It can cover apps that ignore system proxy settings, but traffic coverage depends on system routes, permissions, and exclusions—not a single toggle. Whether UDP can be proxied also depends on node support. If another VPN or virtual network adapter is active, check for routing and DNS conflicts.
Check TUN permissions and settings →A system proxy points the operating system's proxy settings to the client's local listening port. Apps use the proxy only if they honor those settings. Some command-line tools, apps with their own network stacks, and UDP traffic may bypass this entry point. Before enabling it, make sure the client is listening. If old proxy settings remain after the client exits, apps that follow them may lose connectivity.
Check system proxy connectivity →A mixed port accepts HTTP and SOCKS proxy requests through the same listener. For example, mixed-port: 7890 is a common setting, but the port can be changed. System proxy and app settings must match the actual listening address and port, and no other process should occupy the port. This is a local traffic entry point, not a remote node port. If allowing access from your local network, consider the listening address and access controls.
A DNS leak occurs when domain queries leave through an unexpected resolver instead of the intended resolution path. This may reveal queried domains or cause DNS results to conflict with the traffic route. The operating system, browser, and apps may each make their own queries, and encrypted DNS does not automatically follow the intended route. Check DNS configuration, browser settings, and core logs; a test page showing a provider's name alone is not conclusive.
Check DNS and integration settings →Fake-IP returns synthetic IP addresses to queries handled by managed DNS and maps them to the original domains. When a connection reaches the core, it can restore the domain and apply routing rules. These addresses are not the real addresses of destination servers, so they cannot be used to determine an exit location. Some local network services, games, and other apps need exclusions. After switching DNS modes, you may also need to clear old app or system DNS cache entries.
Explore domain routing references →