Clash Meta for Android Interface Guide: Proxies, Profiles, Overrides, and Logs Explained

Understand the client’s navigation hierarchy first

Clash Meta for Android typically consists of three parts: the graphical interface, the mihomo core, and configuration files. The interface imports subscriptions, selects policies, and displays status; the mihomo core handles DNS resolution, rule matching, and connection forwarding; configuration files store proxy nodes, proxy groups, rules, and runtime parameters. Every tap in the interface ultimately changes the core state or configuration.

This guide uses the common Clash Meta for Android 2.11.x interface as a reference. Depending on the build, Overrides may appear in the top-right corner of the Profiles page, in the sidebar, or under Settings. Logs and Connections may also be separate entries, but their functions are largely the same. After installation, use this order: Profiles → Proxies → start from Home → verify in Logs.

What the five main sections do

Home: start the core and verify mode and status

Home is the runtime control area. After importing and selecting a profile, tap Start and Android will request permission to create a VPN connection. A key or VPN indicator in the status bar only confirms that the local VPN interface exists; access to a target website still depends on node availability, proxy-group selection, DNS, and rule matching.

Check these three items before starting

1. Current profile: Make sure the profile name shown on Home matches the subscription you just imported, so you do not continue using an old profile.
2. Runtime mode: For everyday use, choose Rule, which lets rules decide whether traffic goes direct or through a proxy. Global mode sends most connections to the selected policy, while Direct bypasses the proxy.
3. VPN permission: Allow the system VPN request on first launch. Android normally allows only one app to occupy the VPN interface at a time.

Some versions show upload speed, download speed, total traffic, and active connections on Home. These speeds are real-time traffic passing through the core, not the node’s maximum bandwidth. A display of 2.4 MB/s means about 2.4 MB of data is passing each second right now; it does not mean the connection is limited to that speed.

Rule, Global, and Direct modes

• Rule mode: Matches rules from top to bottom. Work websites can go direct, while selected domains can be sent to a proxy group.
• Global mode: Sends connections through the global proxy group. It is useful for briefly checking whether a node works, but is not a good long-term replacement for precise traffic splitting.
• Direct mode: Connects straight to the destination. Use it to determine whether a problem comes from the local network or the proxy path.

Proxies: understand groups, nodes, and latency results

The Proxies page is not simply a list of servers. The items at the top or on group cards are proxy groups; nodes and other groups appear inside them. Rules send different connections to designated groups such as PROXY, Streaming, or Final. The item selected inside a group determines which route that group uses for a connection.

Common proxy-group types

How to interpret latency values

After you tap the latency test button, the client usually requests the test URL specified in the profile. A common URL is https://www.gstatic.com/generate_204; a successful response returns a status code without downloading a full webpage. A result of 86 ms means the probe took about 86 milliseconds; a timeout means the request did not finish within the test limit. A one-off difference between 120 ms and 135 ms is usually not worth chasing. Persistent timeouts, results above 800 ms, or swings of several hundred milliseconds deserve closer attention.

A successful latency test does not prove that every website is reachable. The test URL, target website, and node exit may use different paths. Select a node first, then check Logs or Connections while opening the actual target domain to see which rule and policy handled it.

Standard steps for switching nodes

1. Open Proxies and find the proxy group referenced by the rule, such as PROXY.
2. Run one latency test within the group and exclude nodes that consistently time out.
3. Choose a node with stable latency and confirm that the selection indicator moves to it.
4. Return to Home, keep the service running, and reopen the target app.
5. If the app reuses an old connection, force-stop it and test again.

Profiles: import, update, and switch subscriptions

The Profiles page stores remote subscriptions and local files. A remote subscription usually fetches YAML from a URL; updating it downloads the proxy nodes, groups, and rules again. A local profile reads a file directly from the device. Regardless of the source, keep exactly one active profile clearly selected at a time.

Import via a subscription URL

1. Open the Profiles page and tap the add button.
2. Choose URL or Import from link.
3. Enter a recognizable name, then paste the complete subscription URL.
4. Save it, wait for the download to finish, and confirm that the profile has no error indicator.
5. Tap the profile to make it active.
6. Return to Home to start the service, then open Proxies to choose a policy.

Updating a subscription and switching profiles are two separate actions. Updating replaces the locally stored contents of that subscription; switching determines which contents the core loads next. If the Proxies page still shows old nodes after an update, verify the active profile, then stop and restart the core.

Common actions in the profile list

• Update: Requests the subscription URL again. An expired subscription, failed authentication, or unreachable network may produce an HTTP error.
• Edit: Changes the profile name, subscription URL, or automatic update interval. The editable fields depend on the client version.
• Switch: Makes the selected item the active profile. After switching, check the profile name shown on Home.
• Delete: Removes the locally stored item. Before deleting the current profile, switch to another working profile.

How to set the automatic update interval

When nodes change infrequently, set the interval to 1,440 minutes—once a day. Frequent updates do not improve connection speed and may create false alarms when the subscription service is temporarily unreachable. If the provider announces changes, manually refresh via Profiles → Current subscription → Update.

Overrides: adjust local parameters without editing the subscription

Overrides layer additional parameters onto a profile when it loads locally. They are useful for changing ports, DNS, IPv6, routing interfaces, or TUN options without editing the original YAML after every subscription update. Supported override fields vary by version; read each option’s description before enabling it, and change one parameter group at a time.

Common configuration fields

mixed-port: 7890
mode: rule
log-level: info
ipv6: false
external-controller: 127.0.0.1:9090

• mixed-port: 7890: Shares port 7890 between HTTP and SOCKS proxies. Most Android traffic is normally handled by the VPN interface, but LAN tools or manual proxy settings may still use this port.
• mode: rule: Uses Rule mode by default. A temporary mode change in the interface may override this initial value in the actual runtime state.
• log-level: info: Records normal runtime information. For complex troubleshooting, temporarily change it to debug, then restore it to reduce log volume.
• ipv6: false: Disables IPv6 handling in the core. Enable it alongside the appropriate DNS settings only when both the network and subscription properly support IPv6.
• external-controller: The core control interface. Binding it to 127.0.0.1 restricts access to the local device; 9090 is a commonly used control port.

A safe order for applying overrides

1. On the Profiles page, confirm that the original subscription starts normally.
2. Go to Settings → Overrides and enable only the item you are testing.
3. Stop and restart the service so the core reloads the configuration.
4. Check the logs for field-type errors, port conflicts, or DNS initialization failures.
5. After testing, record the working settings and remove overrides you no longer need.

If the client stops immediately after an override is enabled, disable the override you just added instead of deleting the subscription. Common causes include incorrect YAML indentation, an invalid field type, a port already in use, or a field unsupported by the current core version. For example, a port should be written as the number 7890, not as a value containing explanatory text.

Logs: troubleshoot issues from connection records

Logs are where you confirm the core’s actual behavior. If Home says the service is running but webpages do not open, do not simply keep toggling the switch. Open Logs, revisit the target website once, and inspect recent records by time, level, domain, rule, and outbound policy. This usually distinguishes DNS, rule, and node problems quickly.

What log levels mean

• Info: Normal records such as startup, established connections, and matched rules. Check this level first for everyday troubleshooting.
• Warning: Request retries, degraded features, or non-fatal configuration issues. The service may still be running.
• Error: Issues that require attention, such as failed profile loading, failed DNS requests, or failed node connections.
• Debug: Detailed internal processing. Use it briefly to reproduce a problem; it generates considerably more records.

Which fields to inspect in a connection record

TCP 192.168.0.2:53142 → example.com:443
match DomainSuffix(example.com)
using PROXY[Node-A]

This type of record indicates a TCP connection to port 443 on a target domain, matched a domain-suffix rule, and was then sent to Node-A in the PROXY group. If you expected a proxy but see DIRECT, check rule order. If the policy is correct but the connection times out, test the node or route. If the log contains only an IP address and no domain, continue by checking DNS and sniffing settings.

How to narrow down four common error types

When troubleshooting, first clear or pause scrolling, note the current time, and reproduce the issue only once. This avoids searching through background connections for the relevant record. Logs may contain domains, LAN addresses, and node names; redact subscription URLs, authentication details, and private access records before sharing screenshots.

Settings and parameter pages: DNS, TUN, and per-app routing

Settings controls client-specific and core runtime parameters. Common paths include Settings → Parameters, Settings → Network, and Settings → App routing. Menu names vary by version, but the functions remain recognizable.

TUN and the system VPN interface

Android clients generally use the system VPN API to create a virtual network interface and send app traffic into the mihomo core. With TUN enabled, supported TCP and UDP traffic can be handled through the same entry point. VPN permission is required on first launch. If another VPN, network filter, or local firewall is running, stop it first because Android generally permits only one conventional VPN service to be active.

What to check in DNS settings

• Confirm that DNS is enabled for the current profile and that the nameserver addresses are reachable from the existing network.
• With fake-ip mode, domains may map to a reserved address range; the core then restores the domain and matches it against the rules.
• Some LAN devices, banking apps, and games do not work well with fake-ip. Exclude them through the filter options, using the logs to determine the specific entries.
• If a domain fails to open while its IP address works, check for DNS timeouts in the logs before replacing all your nodes.

Two approaches to per-app routing

Per-app routing determines which apps enter the VPN by package name. Allowlist mode handles only selected apps, while blocklist mode excludes them. After switching modes, fully exit and reopen the target app because an old connection may still use the previous network path. System components, WebView, and the target app may issue separate requests, so selecting only the main app package can send the login page and content over different paths.

A reusable first-use workflow

Once the interface is familiar, you can reduce initial setup to a fixed sequence. This prevents missed steps and makes it easier to verify every stage after changing phones or reinstalling.

1. Go to Profiles → Add → URL, import the subscription, and make it active.
2. Update the subscription once and confirm there are no download or YAML parsing errors.
3. Open Proxies, test latency for the main proxy groups, and select a working node.
4. Return to Home, set the runtime mode to Rule, tap Start, and allow the VPN request.
5. Open a target webpage, then check Logs for the domain, matched rule, and outbound policy.
6. If a specific app must bypass the VPN, go to Settings → App routing and adjust its scope.
7. Add DNS, TUN, or port overrides only after the basic connection is stable.

Troubleshoot connection failures layer by layer

• All nodes time out: switch between Wi-Fi and mobile data, then verify the subscription and basic network.
• Only one node fails: switch to another node in the same group on the Proxies page; there is no need to rebuild the entire profile.
• Only one website fails: inspect its matched rule and DNS records, and check whether it was incorrectly routed direct.
• Only one app fails: check per-app routing, stale connections, IPv6, and system battery restrictions.
• Failure after enabling an override: disable the override added most recently, restart the core, and compare the log changes.

The core relationships are simple: Profiles determines what is loaded, Proxies determines the current choice in each group, Home controls whether the core runs, Overrides applies local changes, and Logs verifies where traffic ultimately goes. Following this sequence is more effective than repeatedly restarting the service or blindly replacing nodes.