Clash and mihomo Terminology Guide

mihomo is a proxy core developed from Clash Meta. It establishes protocol connections, handles DNS, matches rules, and forwards traffic. Most GUI clients call on the core and add configuration management, system proxy controls, and log views.

When troubleshooting, first separate client-interface settings from core configuration. Rule matches, DNS queries, and connection errors shown in logs are usually generated directly by the core.

Clash Meta is an extended implementation in the Clash core ecosystem, adding more proxy protocols, rule capabilities, and network-processing options. In related documentation, Meta fields usually refer to this extended syntax or compatibility layer.

Current materials may use both Clash Meta and mihomo. When reading older configurations, check the fields and core version rather than inferring feature support from the name alone.

A GUI client is a desktop or mobile app with a graphical interface. Common features include subscription updates, policy switching, system proxy controls, TUN toggles, and log viewing. The client and proxy core can be updated separately, so their versions may not match.

A setting missing from the interface does not necessarily mean the core lacks support. Some advanced fields must be enabled through an override or by editing the YAML configuration directly.

YAML is a common data format for Clash configurations and expresses field hierarchy through indentation. It is sensitive to spaces, colon placement, and list markers; tabs, misaligned levels, or missing spaces can cause parsing failures.

Keep indentation consistent at the same level when editing a configuration. Strings containing special characters can be quoted to prevent them from being misread as booleans, numbers, or comments.

The configuration file stores settings such as ports, operating mode, DNS, nodes, proxy groups, and rule sets. It is the main input read when the core starts, and subscription content is also loaded as a configuration file.

A configuration that downloads successfully is not necessarily valid for the core. When loading fails, check YAML syntax first, then verify that the fields are supported by the current core.

Rule-based routing determines where a connection goes using its domain, IP, port, process, or a rule set. Rules are generally checked from top to bottom, and the first match determines the policy used.

Putting broad rules first can prevent later, more specific rules from ever matching. When editing a rule set, check both its order and the target policy name.

Rule Provider loads rule sets from a separate file or remote URL. The main configuration only needs to reference the collection name, while the rules can be updated independently at a defined interval.

A rule set must declare the correct behavior type and data format. Download failures, incorrect paths, or format mismatches can prevent the referenced rules from working properly.

A proxy group combines multiple nodes or other policies into one logical entry. Rules usually point to the group, while the user, latency testing, failover, or load balancing determines the actual route.

Proxy groups can reference other proxy groups, but names must match exactly. Circular references or missing names cause configuration errors.

DIRECT is a built-in direct-connection policy. It means the connection bypasses proxy nodes and reaches the destination directly from the current device. LAN addresses, device services, and connections suited to a local route commonly use it.

Direct connections are still affected by local routing, firewalls, and DNS results. A DIRECT match only means the core selected a direct route; it does not guarantee that the destination is reachable.

REJECT is a built-in action that rejects connections, commonly blocking specific domains, addresses, or request types. It stops the matching traffic at the rule layer instead of selecting a proxy node.

An overly broad reject rule can affect web resources, app APIs, or system services. When content loads incompletely, check the logs to see whether the request matched REJECT.

GeoIP matches traffic by the region associated with its destination IP and relies on a local geolocation database. It works well once the destination IP is known, but results depend on database coverage and freshness.

A domain’s server address can change with region, network conditions, and CDN routing. GeoIP is useful as one routing condition, not as a permanent statement of where an address belongs.

GeoSite is a collection of domains organized by purpose, service, or region. Rules can reference a category to match related domains in bulk, reducing the need to maintain domain suffixes individually.

GeoSite and GeoIP match different objects: GeoSite targets domains, while GeoIP targets IPs. When the database is outdated, new domains or category changes may not be reflected promptly.

A subscription is a server-provided collection of configurations or nodes that can be updated periodically. The client retrieves it from a subscription URL and parses it into usable nodes, proxy groups, rules, and other items.

Updating a subscription may overwrite earlier direct edits. Local rules or DNS settings that must persist are better placed in a client-supported override or merge configuration.

A node is the connection definition for one proxy server, usually containing the protocol, server address, port, and authentication parameters. Its name is only a display label and does not prove line quality or actual location.

The same node can be referenced by multiple proxy groups. After renaming or deleting a node, update every proxy group that references its name.

Latency usually means the response time measured after a client probes a specified test address. It helps assess reachability and make an initial speed comparison, but it is not the same as download speed or sustained stability.

Clients may use different test addresses, timeouts, and connection reuse methods, so latency values should not be compared directly across clients. Consider occasional results alongside repeated tests.

TUN mode takes over traffic through a system virtual network interface, allowing apps without manual proxy support to enter the core’s rule-processing flow. It usually covers more traffic than system proxy settings alone.

Enabling TUN may require system permissions and can conflict with other VPNs, virtual adapters, or security software. If the network goes offline, check the default route, DNS hijacking, and other network tools.

An override adds, replaces, or removes configuration fields without directly editing the original subscription. Common uses include fixing the port, adjusting DNS, adding rules, and modifying proxy groups.

Clients may differ in how they name and order overrides, merges, and scripts. After making changes, inspect the final generated configuration rather than checking only the override fragment.