Go from interface labels to core concepts. Each entry explains what a term means, where it is used, and what it is often confused with. Link directly to cards to share or revisit them.
For your first profile import, start with the getting started guide. To combine proxy groups, rule providers, and DNS settings, see Advanced configuration. Whether a field works depends on the core and client you are running.
Distinguish the management interface, traffic-processing engine, and system entry point. An interface toggle alone does not prove a connection is being handled.
Client
A client is the app used to manage profiles, proxies, connections, and logs. It often also handles the system proxy and service permissions. Similar-looking interfaces do not necessarily use the same core or support the same fields. When moving a profile, check both how the client processes it and what the core supports—not just the menu labels.
Core
The core is the networking engine that handles proxy connections, DNS, and rule matching. A graphical client can run it, or it can run independently. Client and core updates may be separate, so an option that the interface can save is not necessarily supported by the running core. If you see an unknown-field or unsupported-protocol error, first check the core name and version.
mihomo / Clash.Meta
mihomo is a proxy core from the Clash ecosystem, previously referred to in tutorials and client documentation as Clash.Meta. It is not a specific graphical client; the same core can work with different management interfaces. When following an older guide, check the current field documentation, especially for version differences in DNS, TUN, and sniffing options.
System proxy
The system proxy registers a local proxy address with the operating system for apps that honor the setting. It does not force every program to use the proxy: browsers, command-line tools, and games with their own proxy settings may take a different route. Check the local listening port, app proxy settings, and connection logs. Enabling the system proxy does not mean all traffic is going through the core.
External controller
The external controller is the interface a dashboard or client uses to access core status. Its configuration field is usually external-controller. It can show connections, change policies, and read runtime status, but it is not a proxy port to enter in a browser. It usually listens on localhost; if remote access is necessary, configure authentication and restrict network access.
A node describes the connection destination; a protocol describes how the connection is made. Test results reflect a specific target and network route at a specific time.
Proxy node
A proxy node is an outbound connection entry, typically containing a server address, port, protocol, authentication, and transport settings. A node is not a subscription: one subscription may provide multiple nodes and may also include a full set of rules. A successful node connection only shows that the outbound works; app access also depends on rules routing traffic to it.
Shadowsocks / SS
Shadowsocks carries proxy traffic between the client and server using an agreed encryption method and credentials. A configuration commonly uses type: ss; the cipher, password, and server settings must match. If a node requires a plugin or transport extension, confirm that the core supports it. Copying only the server address and port is not enough.
Trojan
Trojan typically carries proxy traffic over TLS. Its configuration includes details such as the server address, password, and server name. Authentication and certificate validation are separate steps; a hostname mismatch or incorrect system time can also cause a handshake failure. For certificate errors, check the name, certificate chain, and system time rather than disabling validation as a permanent fix.
SOCKS version 5
SOCKS5 lets an app negotiate a connection through a proxy. It supports TCP connections and UDP forwarding, but does not encrypt traffic by itself. After an app connects to the local SOCKS5 port, the core's rules still determine the outbound route. Whether domains are resolved locally or on the proxy side depends on the app, so check both the proxy address and DNS behavior.
Latency test / URL test
A client latency test usually sends a request to a specified address through a proxy and reports how long it took; it is not necessarily an ICMP ping. Results depend on the test site, DNS resolution, handshake, and network route. A lower number does not guarantee faster downloads. A timeout does not necessarily mean the node is unusable—check access to the intended destination and the core logs.
Rules decide where traffic goes; proxy groups decide which outbound is currently selected. Check the rule match first, then the selected proxy.
Rule-based routing
In rule mode, rule-based routing checks connection details such as the domain and destination IP, then sends traffic to a specified outbound. Rules are usually evaluated from top to bottom, and the first match wins, so specific exceptions should come before broad rules. In global mode, traffic routes should not be interpreted as though rule mode were active.
Proxy group
A proxy group combines multiple proxies or other groups into a logical outbound that rules can reference by name. select lets you choose manually, url-test selects based on test results, and fallback typically picks the first available member. Automatic selection still depends on the test address and interval; it cannot guarantee the best route for every destination.
Rule provider / Rule set
A rule provider stores domains, IPs, or other rule entries as a separate resource for easier categorization and scheduled updates. In mihomo, define it with rule-providers and reference it with RULE-SET. The resource format must match the declared behavior type. A successful update does not guarantee the rules are active: check the reference name, rule order, and target policy.
IP geolocation
GeoIP uses an IP geolocation database to determine the region associated with a destination address. A common rule is GEOIP,CN,DIRECT. It checks IP records; the result does not establish a company's place of registration or a user's actual location. CDN routing and database updates can change the result. Domain-based targets may also need to be resolved first; understand the limitations before using no-resolve.
Catch-all rule
MATCH is a catch-all rule for connections not matched by earlier entries, for example MATCH,Proxy. It usually belongs at the end of the list; if placed earlier, later rules will never be reached. If many connections hit MATCH in the logs, check domain data, rule provider loading, and rule coverage—not just the proxy node.
Traffic capture, DNS resolution, and proxy routing happen at different layers. Even with TUN enabled, check routes and DNS separately.
Domain Name System
DNS resolves domain names to records such as IP addresses. The core's dns section controls related resolution behavior. DNS requests and the app's eventual connection do not necessarily follow the same route. Before changing nameserver, check whether the app actually uses the core's DNS; a browser's encrypted DNS may take a separate path.
Fake-IP
Fake-IP returns a virtual address to the app and keeps a mapping between that address and the domain in the core, allowing domain-based rules to be applied later. The virtual address is not the destination server's real address, so seeing it in DNS results does not indicate a resolution failure. LAN services and apps that depend on real addresses may need exclusions. Handle specific domains rather than adding an overly broad range to a filter list.
TUN virtual network interface
TUN uses a virtual network interface to receive IP traffic routed by the system to the core, and can capture traffic from some apps that ignore the system proxy. Actual capture depends on permissions, routes, exclusions, and interference from other VPNs. TUN does not mean every connection must use a proxy. Connections reaching the core can still be routed directly by rules, and DNS capture requires its own settings.
DNS leak
A DNS leak occurs when resolution requests do not follow the intended path—for example, when the core is supposed to handle them but the system or an app sends them directly. Judge this against the intended policy and actual requests, not by whether a test site displays a familiar resolver name. Check IPv4, IPv6, encrypted DNS in browsers, and other networking software; changing a single setting may not be enough.
Domain sniffing
Domain sniffing extracts domain names from recognizable handshakes or application-layer fields, such as HTTP Host or TLS server names in some connections. It can help fill in domain information, but cannot decrypt arbitrary app traffic or identify every connection. If enabling it causes compatibility issues, check the protocols being sniffed, skipped domains, and destination overrides.
First distinguish full profiles, proxy lists, and rule resources, then choose the right import option. When updating a profile, also check whether local changes are preserved.
Subscription
A subscription distributes a profile or proxy list through a link. The response may be a complete YAML file or a proxy list in another format. The import option must support that format; a link opening in a browser does not mean the core can parse it. Subscription URLs often contain access credentials, so hide the full link when sharing logs, screenshots, or profiles.
YAML
YAML is a structured text format commonly used for Clash configuration. Indentation defines nested mappings and lists, so use spaces rather than tabs. Parsable syntax does not guarantee that field names, types, or references are valid. For an error, first check indentation, colons, and quotation marks near the reported line, then check group and rule references; the actual problem may be above the indicated line.
Configuration file / config.yaml
A configuration file defines settings such as listening ports, proxies, groups, rules, and DNS. A common filename is config.yaml. The filename does not determine its contents: a client may download a source profile, apply local overrides, and generate the running configuration. If the interface and file disagree, check the actual configuration shown by the client rather than only the original subscription.
Proxy provider
A proxy provider manages an updatable list of proxies with proxy-providers, which proxy groups can then reference. It is not a full profile subscription and does not provide rules. The returned content must match the proxy provider format. If an update succeeds but the proxies do not appear, check the group's use reference, filters, and resource parsing logs.
Local override / Merge
Local overrides add or replace settings on top of a subscription profile, commonly to set fixed ports, customize DNS, or add routing rules. Clients differ in how they merge lists, insert rules, and process scripts, so similarly named features may not behave the same way. After editing, check the final running configuration and test a subscription update to make sure the local settings are still applied as expected.