Clash / mihomo · Glossary

Clash Glossary

From subscriptions and nodes to rule-based routing, TUN, and config fields. Browse terms by topic, understand what each one does, and identify the setting to change.

This page covers 25 terms. Use the link beside a term heading to jump directly to that entry for bookmarking or reference.

Cores, Configs, and Connections

Core Concepts

The client provides the interface, the core handles network traffic, and the subscription supplies configuration content. They are separate components.

mihomo Core #mihomo core: mihomo is the network core responsible for proxy connections, DNS handling, and rule matching, continuing the technical direction of Clash Meta. The GUI client manages subscriptions, the interface, and system settings; the core applies the runtime configuration. To check whether a protocol or field is supported, look at the version of the core integrated into the client, not just the client name.

Subscription #Subscription: A subscription is usually a URL for fetching remote proxy nodes or a complete configuration; it is not itself a proxy connection. The response may be a YAML config or just a list of nodes, depending on the format supported by the client. An update may replace existing content, so make lasting changes in a client-supported override location. Subscription URLs often contain access credentials and should not be shared publicly.

Proxy Node #Proxy node: A proxy node is a set of parameters describing a proxy server and how to connect to it, usually including an address, port, protocol, and authentication details. A region in the node name is only a label; it does not confirm the exit location or route. Choose a node based on connectivity for your actual use case, exit IP, and sustained performance—not just its name or a single speed test.

Configuration File #Profile / config.yaml: A configuration file stores proxies, proxy groups, rules, and network settings such as DNS. A common filename is config.yaml. A profile is usually a configuration entry managed by the client, sourced from a local file or remote subscription. The final runtime config may be merged or overridden and affected by client options. After editing a source file, confirm that the changes appear in the active runtime config.

Latency #Latency / URL test: The latency shown by a client usually measures how long a node takes to reach a specified test URL; it may not be an ICMP ping. The target, connection reuse, timeout, and current network conditions all affect the result. Low latency does not mean fast downloads, and a test timeout does not necessarily mean every site is unavailable. Check the target service and connection logs as well.

How Data Is Transmitted Between Nodes and Servers

Proxy Protocols

The protocol determines how connection parameters are interpreted. The client and server must use compatible protocols; changing a name does not convert one protocol into another.

Shadowsocks #SS: Shadowsocks is an encrypted proxy protocol. A node typically requires a server address, port, encryption method, and password. Both ends must use compatible encryption methods, and some methods also require a specific key format. UDP support and plugin requirements are separate capabilities and settings; the protocol name alone does not confirm that a config is complete.

VMess and VLESS #VMess / VLESS: VMess and VLESS are different protocols. Although both commonly use a UUID, their authentication and transport requirements differ. VLESS does not encrypt traffic by itself; its security depends on transport settings such as TLS or REALITY. When importing a node, also check the transport type, server name, path, and other parameters. Simply renaming the node type will not make it work.

Trojan #TLS-based proxy protocol: Trojan typically carries proxy traffic over TLS and uses a password for authentication. Connections depend on the authentication parameters, server certificate, server name, and network reachability. If you encounter a certificate error, first check the domain, system time, and server certificate. Disabling certificate verification should not be a routine fix.

Hysteria2 #QUIC-based proxy protocol: Hysteria2 is a QUIC-based proxy protocol that relies on underlying UDP connectivity. Both client and server must support the second-generation protocol; first-generation settings should not be assumed to be compatible. Bandwidth parameters, congestion control, and network restrictions affect performance. Setting a higher bandwidth value does not increase the capacity of the actual link.

TUIC #QUIC transport: TUIC is a QUIC-based proxy protocol that can carry TCP and UDP traffic, using multiplexing to organize connections. Make sure the protocol version, authentication details, and server parameters match. The connection may fail if the underlying network restricts UDP. QUIC support does not mean it will be faster or more stable on every network.

Match Conditions and Target Policies

Rules and Routing

Rules determine how a connection is matched; policies determine where it goes. When troubleshooting routing, check the matched rule first, then the selected node.

Rule-Based Routing #Rule-based routing: Rule-based routing selects a policy for connections entering the core based on conditions such as domain, destination IP, port, or process. Rules are generally matched from top to bottom, and the first valid match determines where traffic goes. More specific conditions usually belong before broader ones. After adding a rule, check the connection log to confirm which rule actually matched; do not just check that the config was saved.

Proxy Group #proxy-groups: A proxy group combines multiple nodes or other proxy groups into a policy entry point, so rules do not need to target a single node directly. select lets you choose manually; url-test selects automatically based on test results. They make decisions differently. Referenced group names must exist, and group availability depends on its member nodes and test target.

GeoIP #IP geolocation database: GeoIP uses an IP geolocation database to match destination addresses. For example, GEOIP,CN,DIRECT sends matching addresses to the direct policy. The database may be out of date, and an IP's registered location does not identify where the service owner is based. IP-based rules may trigger DNS resolution for domain connections; no-resolve can prevent this kind of active lookup.

Rule Set #rule-providers / RULE-SET: Rule sets group domains, IPs, or classic rules for easier updates and reuse. Define one under rule-providers, then reference it in the rules list with RULE-SET and specify a target policy. The data format must match behavior. Check whether the rule set updated successfully; the main subscription's update time does not confirm this.

DIRECT, REJECT, and MATCH #Built-in policies / final rule: DIRECT and REJECT are built-in policies for direct connections and rejected connections, respectively. MATCH is a rule type that matches all remaining connections, not a node or proxy group. A common rule, MATCH,PROXY, sends the remaining connections to the policy named PROXY, which must exist in the config.

Traffic Capture and DNS Resolution

Network Modes

System proxy and TUN settings determine how traffic enters the core; rule and global modes determine how it is handled afterward. DNS needs to be checked separately.

System Proxy #System proxy: The system proxy exposes a local HTTP or SOCKS proxy to the operating system or apps. Only programs that honor this setting will use it. Some command-line tools read environment variables, while some apps use their own proxy options. If an app connects directly after system proxy is enabled, first check which network settings it uses; that alone does not mean the rules are failing.

TUN Mode #Virtual network interface: TUN mode uses a virtual network interface and routing configuration to send more IP traffic through the core. Whether a particular app is captured still depends on permissions, routes, exclusions, and DNS settings; enabling TUN does not guarantee that every connection will be captured. TUN can be used alongside rule mode. If it conflicts with another VPN, check the routes and interfaces before repeatedly switching nodes.

Rule, Global, and Direct Modes #rule / global / direct: Rule mode routes traffic according to rules; global mode sends traffic entering the core to the global selector; direct mode uses the direct policy. In global mode, the selector still needs an appropriate node or policy, or traffic may not exit through a proxy. These modes do not capture app traffic that never enters the core, and they cannot replace system proxy or TUN settings.

DNS Leak #DNS leak: A DNS leak generally means domain lookup requests are sent to a resolver over an unintended route, outside the configured resolution setup. System DNS, browser-based DoH, and app-level resolution can all change the route. A test site's reported resolver location is only a clue; check DNS settings, resolution methods, and connection logs rather than relying on a region label alone.

Fake-IP #Synthetic DNS address: Fake-IP assigns synthetic addresses to DNS queries, then maps them back to their original domain names when connections enter the core, helping identify domains and route traffic. These addresses are not the destination server's real IPs, so seeing one does not indicate a DNS failure. Apps that require real IP addresses may need an entry in fake-ip-filter. When troubleshooting, also check for stale DNS caches in the system and apps.

Common Fields in the Runtime Config

Config Fields

Keep field names unchanged. Before editing, distinguish the source subscription, client overrides, and final runtime config so you don't modify a file that isn't in use.

YAML #Configuration syntax: YAML is a structured text format. Clash config uses indentation to represent object hierarchy and hyphens for list items. Use spaces consistently for indentation; strings containing special characters may need quotes. A config that parses successfully may still be semantically wrong: misspelled fields, duplicate keys, or references to nonexistent policies can prevent loading or produce unexpected behavior.

mixed-port #Mixed HTTP / SOCKS listener: mixed-port sets a local listening port that accepts both HTTP and SOCKS proxy requests; it is not the remote node's service port. When configuring a browser, terminal, or other app manually, use the address and port in the active runtime config. If another process is using the port, the listener may fail to start. See Clash Port Settings for troubleshooting steps.

proxy-providers #Proxy node providers: proxy-providers defines collections of nodes loaded from a remote URL or local file. Proxy groups can reference these collections with use. It provides nodes only, not a complete config with rules, DNS, and proxy groups. Remote content must follow the structure supported by the provider. If an update fails, check the content format, network access, and cache file status.

nameserver #Upstream DNS resolvers: Under the dns config, nameserver specifies upstream resolvers for the built-in DNS. Other fields, such as nameserver-policy, may affect which resolver is selected. Proxy server hostnames can also use separate DNS settings. Providing a DoH URL does not mean every app's queries will go through that resolver; check how traffic is captured and whether apps bypass the built-in DNS.

external-controller #Controller API listener: external-controller sets the listening address for the core's control interface, which a client UI or dashboard can use to read connection status and switch policies. It serves a different purpose from mixed-port, which accepts proxy traffic, and cannot replace it. Usually, access should be limited to the local machine. If remote administration is necessary, configure authentication and network access restrictions; do not expose the interface directly to the public internet.