Configuration Guide · Settings Reference

Clash Glossary

A subscription on the configuration screen, a proxy group on the proxy screen, and a VPN request in Android settings refer to different layers. Use the five categories below to find a term, then return to the relevant settings.

Follow the setup steps Read the guide, from beginner to advanced

Cores and Clients

Start with the app, configuration, and connection details. After importing a configuration, make sure it is selected and active.

Client: The configuration, proxy, logs, and service controls you see in the app are provided by the client interface. The core typically handles protocol connections, DNS, and rule matching, so apps with similar interfaces may not support the same configurations. To find a feature, check the client name and core details in the app's About or Settings screen, then consult the relevant documentation.

mihomo: mihomo is a proxy core evolved from Clash Meta. It handles protocols, DNS, and traffic routing, and is not a specific Android app; different clients can use the same core. If a configuration field is reported as unsupported, check the core actually in use and its version rather than relying on whether the app name includes Clash.

Configuration File: A configuration file stores settings such as proxy nodes, proxy groups, DNS, and routing rules. Common extensions include .yaml and .yml. After importing it on the configuration screen, select it to make the client use it. Keep a working copy before editing. For remote configurations, check whether updates overwrite local changes.

YAML: YAML is a text format that uses indentation to define hierarchy and is commonly used for Clash configurations. Indent with spaces, align fields at the same level, and keep the hyphens before list items. If parsing fails after saving, check the reported line for indentation and quotation mark errors, then verify the field contents. Changing the font or filename will not fix syntax errors.

Subscription: A subscription is usually a link for fetching and updating proxy nodes or a complete configuration. In the client's configuration screen, choose the option to import from a URL. A subscription may include more than nodes; the provider may also supply proxy groups and rules. If custom settings disappear after an update, check whether you edited a remotely managed file and use the client's override feature if available. Keep subscription links secure.

Proxy Node: A proxy node is a set of remote connection details, usually including an address, port, protocol, and authentication parameters. Select it on the proxy or proxy group screen. Its display name is only a label and does not tell you the server's location or connection quality. If a node fails, check the connection error in the logs, then verify the subscription, server status, and local network.

Proxy Protocols

A protocol defines how the client connects to a server. The server determines the required settings; renaming an incompatible node will not make it work.

Shadowsocks: Shadowsocks is an encrypted proxy protocol. In a YAML node, its type is usually written as ss. When adding one manually, match the server address, port, encryption method, and password to the provider's details; some nodes also require plugin settings. If an encryption method is unsupported, check the core's capabilities rather than switching methods while keeping the same server.

VMess and VLESS: VMess and VLESS are distinct protocols, configured as vmess and vless, respectively. Along with a user identifier such as a UUID, settings may include the transport, TLS, and server name. If importing or the handshake fails, verify every detail against the provider's instructions. Simply changing the type field does not turn one protocol's node into another.

Trojan: Trojan typically uses TLS for proxy connections and is configured with the type trojan. If the password is correct but the connection still fails, check the server name, device time, and certificate verification settings. For certificate errors in the logs, verify the address and server configuration; do not routinely bypass certificate verification as a fix.

Rules and Routing

Choose rule-based routing or a single route in the mode selector, then choose a node in a proxy group. To find the route a connection actually took, check its match result in the connection log.

Rule Mode: Rule mode routes connections that reach the core according to conditions in the current configuration, choosing policies such as direct, proxy, or reject. Rules are usually checked in order; once a connection matches an earlier rule, later rules do not handle it. For everyday use, select Rule and check the matched rule and route in the connection log rather than judging routing by whether a website loads.

Global Mode: Global mode routes all connections that reach the core through a global policy, which usually requires selecting a node for that policy. It changes routing decisions within the core; it does not automatically send traffic from every app to the core. If a browser works but other apps do not, check traffic capture and app exclusions instead of repeatedly switching global mode.

Direct Mode: Direct mode connects to destinations directly for connections that reach the core, without using a remote proxy node. DIRECT in a configuration rule is also a direct policy, but applies only to connections matching that rule; it is not the same as switching the entire operating mode. The client may still handle DNS in direct mode, so this does not necessarily stop the proxy service completely.

Traffic Routing: Traffic routing assigns different routes to connections based on conditions such as domain, IP, port, or rule set. When editing custom rules, first make sure the referenced proxy group exists, then place the rule where it will be matched—usually before the final catch-all rule. Check that rules persist after remote configuration updates. Editing options vary by client; see the advanced guide for details.

Proxy Group: A proxy group combines multiple nodes or policies into a set of routes for manual selection, automatic latency testing, or failover. When a rule targets a group, the group's selection or test results determine the actual route. An automatic test group does not mean every connection always uses the lowest-latency node; whether existing connections switch also depends on the core and client.

GeoIP and GEOSITE: GeoIP matches against IP address location data, while GEOSITE uses categorized domain data; they are separate datasets. With CDN-hosted domains, resolved IP addresses can change, so IP location results may not align with how you would categorize a website. If a rule matches unexpectedly, check which dataset was used and whether it is up to date. These categories do not prove a server's physical location.

Android System Features

VPN permission, traffic capture, and background operation are handled separately. Menu names vary by device, so start with the app info screen and Android's VPN settings.

VpnService: VpnService is Android's built-in VPN interface, which clients use to receive and process device network traffic. The first time you start the service, Android usually displays a VPN connection request. Check the app name before allowing it. Permission does not provide a remote server; typically, only one app can use the VPN service at a time for a given user or profile, so other VPN apps may conflict.

TUN Mode: TUN captures IP packets through a virtual network interface and can handle traffic from apps that do not follow system proxy settings. It is a different settings layer from Rule, Global, and Direct, and can be enabled alongside rule-based routing. On Android, clients usually create the interface through VpnService. Desktop platforms may require additional permissions, so the setup and implementation are not interchangeable with Android settings.

Battery Optimization and Background Restrictions: Android manages background apps to reduce power use, and strict restrictions can interrupt a proxy service. If the connection drops after the screen locks, open the app's system settings and check its battery options; allow background activity or set battery use to unrestricted as needed. Some manufacturers also have separate auto-start controls. These settings do not improve the proxy node's network quality.

Always-on VPN: Always-on VPN is an Android system option that tries to keep a selected app's VPN service running, usually from that app's settings in the system VPN list. It is different from starting the client at boot and from blocking connections without a VPN. Enabling the latter can leave the device offline if the service stops or its configuration fails, so make sure the connection is stable and know how to return here to disable the restriction.

Networking and DNS

Successful DNS resolution, a successful proxy connection, and a response from the destination website are separate steps. When troubleshooting, check the DNS route, actual connection route, and test target independently.

DNS: DNS resolves domain names to the IP addresses needed to connect. Client DNS settings, Android Private DNS, and a browser's Secure DNS may each affect the query route, so changing one setting may not cover every app. If a domain will not load, check the logs for resolution errors, then find which resolver the app actually uses to avoid mistaking a DNS failure for a proxy node problem.

Fake-IP: Fake-IP is a DNS method that first returns a mapped address for a domain, then lets the core map the connection back to the domain and handle it. An address within a configured range such as 198.18.0.0/16 is not necessarily the destination server's real address. Some apps that rely on real DNS results may need an exception. Identify the conflicting domain and adjust the filter range rather than disabling domain-based routing altogether.

DNS Leak: A DNS leak usually means queries were sent to a resolver by a route other than the one expected. A test page showing a resolver in a different region from the proxy node does not prove a leak on its own; also consider direct rules, how the resolver is hosted, and browser settings. First determine which domains should use proxy DNS, then verify the route in the client logs and connection records.

DoH: DoH stands for DNS over HTTPS, which sends DNS queries and responses over HTTPS. Supported clients can use it as an upstream resolver, and browsers may enable it independently. Encrypting queries does not mean the connection goes through a proxy; check the resolver's actual route. If the resolver is specified by domain, a working bootstrap DNS path is also needed to establish the initial connection.

Latency and Timeouts: Latency in a client usually measures the time taken to reach a specific test target. It is not download speed or a measure of how quickly every website responds. A timeout means the test did not finish within the allotted time and could involve the local network, DNS resolution, the proxy connection, or the target itself. Keep the test conditions consistent and use logs to narrow down the cause. See the troubleshooting FAQ; do not delete a configuration based on a single speed test.