Configuration Quick Reference
From the mihomo core to TUN, Fake-IP, policy groups, and subscription overrides, this glossary explains common terms along the configuration chain. Each entry covers the concept, its role, and important limitations.
Foundation
Start by separating the client, core, configuration, and nodes. Once these objects are clear, rules, DNS, and TUN settings are easier to locate.
Clash is a rule-based proxy configuration and traffic-routing system. In everyday use, Clash for Android typically consists of a graphical client and a proxy core: the client imports, switches, and displays configurations, while the core establishes connections, matches rules, handles DNS, and forwards traffic. Interfaces vary across clients, but the underlying configuration structure is broadly similar.
mihomo is an open-source proxy core evolved from Clash Meta. It supports rule-based routing, TUN, Fake-IP, rule-provider subscriptions, and multiple proxy protocols, and serves as the component that performs network operations in many newer clients. The client version and core version are separate concepts; updating the interface does not necessarily update the core.
A configuration file is a YAML document that describes proxy behavior. Common sections include nodes, policy groups, rules, DNS, listening ports, and TUN parameters. A complete configuration can be imported directly into a client or retrieved remotely from a subscription URL. Whether it loads successfully depends on field names, indentation, data types, and core compatibility.
A node is a proxy-server connection entry in a configuration file, typically containing the server address, port, protocol, authentication details, and transport parameters. A node is only a connection path, not a policy group. Rules generally reference a policy group, which then chooses the actual node. Node availability also depends on server status, line congestion, and the local network.
Latency is the time required for a test request to make a round trip, usually measured in milliseconds. Lower latency often means faster interactive responses, but it does not by itself show download bandwidth, packet loss, or long-term stability. Client latency results are also affected by the test address, DNS resolution, and current network conditions.
Connection Layer
A proxy protocol determines how the client communicates with the server. Local proxy interfaces and remote node protocols serve different purposes, so first identify which layer a configuration field belongs to.
An HTTP proxy is an application-layer proxy interface for HTTP and HTTPS requests. Browsers and apps that support manual proxy settings can connect to Clash’s local HTTP listening port, after which the core selects an exit according to the rules. Because the app must actively use the proxy settings, this does not automatically cover all Android traffic.
SOCKS5 is a general-purpose proxy interface that can forward various types of TCP traffic and, depending on the client implementation, UDP. Unlike an HTTP proxy, it does not need to understand the format of a specific web request, giving it broader applicability. The app must still explicitly connect to the SOCKS5 listening address; otherwise, consider the Android VPN interface or TUN interception.
Shadowsocks is an encrypted proxy protocol. A node configuration usually requires the server address, port, encryption method, and password; any mismatch can cause the handshake to fail. It describes the connection between the client and remote server, not which domains should use the proxy.
VLESS is a lightweight proxy protocol commonly combined with TLS, REALITY, WebSocket, or gRPC transport and security layers. In addition to the user identifier, verify the server name, transport type, path, public key, and other parameters. The same protocol name does not mean every transport combination is interchangeable.
Decision Layer
Rules determine where a connection belongs, while policy groups decide which exit to use. Together they form the main traffic-routing logic in a Clash configuration.
Rule-based routing assigns connections to a specified policy group according to conditions such as the domain, IP, network type, or process. Rules are usually checked from top to bottom, and matching stops at the first hit. Put specific rules before broad ones to prevent an earlier general condition from intercepting them.
A policy group is a logical container for nodes and other policy groups. Common types include manual select, periodic testing with url-test, failover with fallback, and connection distribution with load-balance. Rules reference the policy group name, which then selects the actual exit.
A rule provider is a set of rules that can be maintained independently and referenced by the main configuration. It is useful for separating service domains, regional IP ranges, and ad domains from the main file. Remote rule providers require a source, refresh interval, and behavior type; when an update fails, the existing cache is usually retained.
GEOIP matches the region associated with the destination IP in a geographic database. It is usually evaluated after the domain has resolved, so results depend on the DNS response and database version. For services using globally distributed addresses, GEOIP alone may not accurately represent the service’s region.
MATCH is the final fallback in a rule list, receiving connections that matched none of the preceding conditions. It is usually placed at the end and points to a catch-all policy group, direct connection, or reject action. Without a sensible fallback, unclassified traffic may be handled differently from what you expect.
Resolution and Interception
DNS determines how a domain is resolved, while TUN determines which connections enter the core. Both need to be considered together; changing only one can create inconsistencies between resolution and routing.
A DNS leak occurs when application traffic goes through the proxy but domain lookups are handled by an unintended resolver. This may expose the lookup path or return an address that does not match the proxy exit region. Troubleshooting should cover Android Private DNS, the Clash DNS module, TUN DNS hijacking, and the browser’s own encrypted DNS settings.
Fake-IP mode returns a temporary mapped address from a reserved pool for each domain. When an app connects to that address, the core can restore the original domain and use domain rules to choose an exit. This helps preserve domain information, but some LAN services, games, or apps with strict validation may need to be added to a filter list.
nameserver is the upstream resolver list used by the Clash DNS module for ordinary queries. Upstreams may use traditional UDP or TCP, or encrypted DNS where supported by the core. Choose resolvers based on reachability, returned results, and rule requirements rather than comparing a single query speed.
TUN mode intercepts system traffic through a virtual network interface, making it suitable for apps that do not support HTTP or SOCKS5 settings. On Android, it usually runs through the system VPN interface and can work with auto-route, strict-route, and DNS hijacking. Normally, only one tool can occupy this type of VPN interface at a time.
Device Layer
Android has separate management mechanisms for background execution, VPN interfaces, and app scope. Even with a correct client configuration, system permissions and restrictions can affect the actual connection state.
Android VPN permission allows an app to create a local virtual network interface and hand device connections to the proxy core. The system displays a confirmation prompt the first time traffic interception is enabled. This permission does not mean traffic must pass through a remote VPN service; it can also support local TUN forwarding on the device.
Per-app routing lets you choose which Android apps fall within the proxy’s interception scope. A whitelist approach handles only selected apps, while a blacklist approach intercepts most apps and excludes specified ones. Re-establish connections after changing the scope so existing connections do not continue using the previous path.
Battery optimization refers to Android’s power-saving restrictions on background apps. After the screen turns off or an app remains in the background for a long time, the system may pause the client, leaving its notification visible while new connections fail, or restart the proxy service. For reliable background operation, check the client’s background activity and battery-management settings.
Runtime logs record configuration loading, rule matching, DNS queries, node connections, and errors. When troubleshooting, first check when the error occurred, the connection target, the matched policy, and the error type. A single failure does not necessarily mean the service is unusable; consider its frequency and the affected app.
Configuration Sources
Subscriptions handle remote content updates, YAML defines the local configuration structure, and overrides preserve device-side adjustments between the two.
A subscription is a way to retrieve an updated node list or complete configuration from a remote URL. A successful import only means the client could read the content returned at that time; it does not mean every node is usable. After the subscription URL changes, the client must fetch and load the configuration again, and existing connections typically do not move to a new node automatically.
The automatic update interval is the period between client refreshes of a subscription or rule provider, usually measured in minutes or hours. A shorter interval picks up remote changes faster but increases request frequency and background activity. After setting it, confirm that Android allows the client to run on schedule in the background.
YAML is a common data-serialization format for Clash configurations, using indentation to express object and list hierarchy. Tabs, incorrect indentation, duplicate keys, and unclosed quotes can all prevent parsing. Keep indentation consistent at each level and include a space after colons when editing.
Overrides and merging apply local settings on top of a remote subscription, such as adding DNS servers, changing rule order, or modifying policy groups. This preserves subscription updates while reducing repetitive manual edits after each refresh. Override syntax and merge order vary by client, so review them again when migrating a configuration.