How to Troubleshoot Slow Clash for Android Speeds: A Three-Layer Check of Nodes, Routes, and Local Settings

Establish a repeatable speed-test baseline first

A “Connected” status in Clash only means that the Android VPN interface or local proxy has started. It does not mean the current node can deliver stable throughput. Before troubleshooting, keep the test conditions fixed. Otherwise, changes in Wi-Fi, mobile data, nodes, and target sites make it difficult to identify where the slowdown occurs.

Use four sets of results to narrow down the fault

Turn off Clash and run one speed test on the current Wi-Fi network. Record download speed, upload speed, and idle latency.
Stay on the same Wi-Fi network, start Clash, select the current node, and run the test again.
Keep Clash enabled, switch only to a node in another region, a different protocol, or another route, and test again.
Turn off Wi-Fi, switch to 4G or 5G, and repeat the tests with the current and backup nodes.

Run each test at least twice, with each run lasting 20 to 30 seconds. Keep the test server, time of day, and target file consistent. Use the same unit for download speeds: 100 Mbps is about 12.5 MB/s. A browser speed of 8 MB/s corresponds to roughly 64 Mbps, so MB/s cannot be compared directly with the Mbps shown by an ISP.

Test scenario	Example result	What to check first
Clash off, Wi-Fi test	286 Mbps, 18 ms latency	Local broadband baseline is normal
Clash on, Node A	22 Mbps, 96 ms latency	The node or relay route may be constrained
Clash on, Node B	173 Mbps, 72 ms latency	Client settings are generally fine; Node A is abnormal
Mobile network, Node A	118 Mbps, 88 ms latency	The route from the home broadband connection to Node A may be congested

Layer 1: Check node quality and proxy-group selection

If only a few nodes are slow on the same network, the problem is usually at the node layer. Common causes include overloaded nodes, insufficient exit bandwidth, repeated retransmissions during the protocol handshake, expired subscription nodes, or a proxy group selecting a different node than expected.

Confirm the actual exit from the Proxy page

In common Clash Meta Android clients, open the 「Proxy」 page, expand the proxy group referenced by the active rules, and identify the specific node with the selection marker. Do not rely only on the top-level group name. For example, a rule may point to 「Node Selection」, which in turn references 「Auto」. The final exit may be switched automatically by URL Test rather than being the region you selected manually.

Open 「Proxy」 → the current proxy group and record the name of the node actually selected.
Tap the speed-test option in the upper-right corner, or run a latency test for the proxy group.
Select three nodes from different regions or with different route labels, and test their actual download speeds one by one.
Disable automatic switching during testing so the exit does not change midway through a test.
Open 「Logs」 and confirm that the target domain matched the expected rule and proxy group.

When latency tests return nearby values such as 80 ms, 95 ms, and 110 ms, do not simply choose the lowest result. Run three consecutive rounds. If one node returns 72 ms, 310 ms, and a timeout, it has obvious jitter. Another node consistently ranging from 105 to 118 ms may provide a more reliable experience for websites and video.

Identify node load and speed limits

A node that slows during the evening peak and recovers overnight is usually affected by concurrency or upstream congestion. Record the speed of the same node at 08:00, 20:00, and 23:30. If it drops from 160 Mbps to 18 Mbps while other nodes remain above 120 Mbps, switch nodes first instead of repeatedly changing Android settings.

Another typical pattern is that small files open normally while large downloads settle at a fixed speed. For example, the first screen of a webpage loads quickly, but downloads stay around 2.0 MB/s. This may indicate bandwidth allocation on the node, a subscription speed limit, or a per-connection cap. Test large files from two different sources, then try a download task that supports multiple connections to distinguish a target-site limit from insufficient overall node throughput.

Update the subscription and remove expired entries

Open the 「Configuration」 page, update the current subscription, and select the configuration again. If the provider has replaced its server addresses while the phone is still using a cached configuration, old nodes may connect intermittently, complete handshakes slowly, or deliver extremely low speeds. After updating, check the proxy groups again: changed node names may cause a previous manual selection to fall back to the first entry.

Layer 2: Check ISP routes and cross-network congestion

If the node itself is normal but is clearly slower on home Wi-Fi and recovers on mobile data, the problem may lie between the local ISP and the proxy entry point. Even when two nodes are in the same region, their upstream providers, relay arrangements, and return paths may be completely different.

Use network switching to locate the entry path

The most useful comparison is not repeatedly restarting Clash, but keeping the node unchanged while switching the access network. Suppose Node C delivers 14 Mbps on home broadband and 126 Mbps on 5G, while both networks reach around 200 Mbps with Clash off. In that case, phone performance and the node exit are usually not the main limits; the path from home broadband to the node entry point deserves closer attention.

Slow on Wi-Fi, fast on mobile data: check the broadband cross-network route, router, and IPv6.
Slow on both Wi-Fi and mobile data: check node load, protocol, and client settings.
Slow only for one target website: check rule matching, target-site exit limits, and DNS results.
All nodes slow together in the evening: there may be time-based congestion on the local access link or upstream relay.

Compare DIRECT and proxy rules

Open the 「Logs」 page, visit the slow website, and inspect the rule name and final policy in the connection records. If a domain that should use the proxy matches DIRECT, traffic goes straight through the local ISP. If a large download site that should be direct is sent through a distant node, detouring also adds latency and consumes bandwidth.

For example, if a ruleset incorrectly places a software mirror in the proxy group, a local path that normally takes 20 ms may become a round trip of “phone → node outside mainland China → mirror in mainland China.” The node test can remain normal while downloads from that site stay slow. Temporarily add the domain to a direct rule and test again to verify whether traffic routing is the cause.

rules:
  - DOMAIN-SUFFIX,example-download.com,DIRECT
  - DOMAIN-SUFFIX,example-video.com,PROXY
  - MATCH,Node Selection

When editing rules, prefer the client’s override feature or a separate rules provider so local changes are not lost after every subscription update. After testing, review the logs to confirm that the domain matched the new rule rather than being intercepted earlier by a higher-priority rule.

Check differences between IPv4 and IPv6 routes

On some networks, direct IPv6 is fast while the proxy node supports only IPv4 reliably. In other cases, DNS returns an AAAA record, the IPv6 connection attempt times out, and the client falls back to IPv4. The usual symptom is a 2- to 5-second pause before a webpage starts loading, followed by normal speed once the download begins.

Check the IPv6 switch under 「Settings」 → 「Network」 or 「Settings」 → 「DNS」, disable it temporarily, and test again. Menu names vary slightly between client versions; the key is to keep DNS resolution consistent with the IPv6 capabilities of the mihomo core. If the first response improves after disabling IPv6, check the router’s IPv6 prefix, DNS responses, and protocol support on the node instead of relying on repeated reconnects.

Layer 3: Verify local Android settings

When several nodes show similarly low speeds on both Wi-Fi and mobile data, inspect the phone’s local layer. Android power-saving policies, VPN conflicts, TUN parameters, DNS, MTU, and other network tools can all affect data transfer through the mihomo core.

Remove background and battery restrictions

Go to Android 「Settings」 → 「Apps」 → the current Clash client → 「Battery」, then choose Allow background activity or Unrestricted. Next, open 「Mobile data & Wi-Fi」 and confirm that background data is allowed. On some device brands, the path is 「Settings」 → 「Battery」 → 「App battery management」. Battery Saver limits background CPU and network activity, especially after the screen is locked.

During testing, keep the screen on for five minutes, then lock it for five minutes, and compare the same continuous download task. If the speed is 90 Mbps with the screen on, drops to 6 Mbps when locked, and recovers after waking the screen, background scheduling is almost certainly contributing to the limit.

Rule out VPN and network-tool conflicts

Within the same Android user space, usually only one system VPN interface can be active at a time. Ad blockers, corporate VPNs, Private DNS tools, and other proxy clients may compete with Clash for the interface. Go to system 「Settings」 → 「Network & internet」 → 「VPN」, confirm that only the target client is active, and check whether another always-on VPN is enabled.

Private DNS does not necessarily reduce throughput, but an unreachable server can delay domain resolution. Go to 「Settings」 → 「Network & internet」 → 「Private DNS」, temporarily switch it to Automatic, and compare the time needed to open a webpage for the first time. If download speed stays the same but the initial wait drops from four seconds to under one, the issue is mainly DNS rather than node bandwidth.

Compare system proxy and TUN mode

System proxy mode handles only apps that follow Android’s proxy settings. Some games, QUIC traffic, and apps with their own network stacks may bypass it. TUN mode uses the Android VPN interface to capture a broader range of traffic, but adds another virtual network-device layer. During troubleshooting, do not change the node, DNS, and TUN at the same time; change only one variable.

Record the current status under 「Settings」 → 「Network」 or 「Settings」 → 「TUN」.
Using the same node, run a 30-second speed test with the standard VPN interception method.
Enable TUN, reauthorize the Android VPN, and run the same test again.
Compare download speed, upload speed, latency, and whether the target app is being captured correctly.

If standard mode reaches 140 Mbps but TUN mode reaches only 38 Mbps, continue checking MTU, the protocol stack, and DNS interception instead of immediately blaming the node. Conversely, if the browser works normally but one app does not use the proxy, TUN mode may solve traffic coverage rather than route speed.

Adjust MTU to address fragmentation

An MTU mismatch can fragment or drop packets. Common symptoms include small webpages loading normally while images and video stall, or unusually low upload speeds. A typical TUN MTU test can start at 1500; on mobile networks, with extra tunnels, or on some broadband connections, test 1480, 1420, and 1400 in sequence. Change only one value at a time, and fully stop and restart the core after each change.

If upload speed is only 0.8 Mbps at MTU 1500 but stabilizes at 18 Mbps after changing to 1400, while download speed changes little, keep the more stable value. An MTU that is too low also increases header overhead, so do not drop it excessively; narrow it down in 20- to 40-byte steps.

tun:
  enable: true
  stack: mixed
  mtu: 1400
  auto-route: true
  strict-route: false

Whether a configuration field works depends on the mihomo core version integrated into the client. Before applying an override, record the version under 「About」 or 「Settings」 → 「Core」, such as client 2.11.15 and mihomo 1.19.12. After editing, check the logs for unknown field, parse error, or TUN create failed.

Treat slow DNS and low bandwidth as separate issues

DNS problems are often described as “slow internet,” but they mainly affect resolution before a connection is established. A typical symptom is waiting several seconds after entering a URL, followed by fast loading once the page starts. Video streams and large downloads with an established connection are usually unaffected.

Compare initial response time with sustained downloads

Every new domain is slow the first time but fast after refreshing: check the DNS cache and upstream resolver first.
Domain resolution is fast, but large files remain slow: check node and route throughput first.
Some domains return incorrect addresses: check fake-ip, rulesets, and DNS routing.
Resolution timeouts appear only after enabling TUN: check DNS interception and port conflicts.

Common local mixed-proxy ports in mihomo configurations include 7890, while the SOCKS port may be 7891 and the DNS listening port is often 1053. These values are not mandatory, but a single port cannot be occupied by two services at once. If the logs show address already in use, check other proxies, DNS forwarders, or an old core process.

mixed-port: 7890

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

The addresses above only illustrate the configuration structure. When choosing an upstream DNS server, consider reachability from your network and whether queries need to go through the proxy. If DNS requests themselves are routed to an unstable node, resolution time will also increase with node congestion.

Check the protocol, core, and device performance

On older or low-power devices, high-throughput encryption, rule matching, and TUN forwarding can consume significant CPU. During a speed test, check the system battery page or a performance monitor. If one core stays near full utilization, speed remains capped at a fixed level, and the device heats up, processing capacity may be the limiting factor.

Compare protocols, not just regions

Different nodes in the same service may use different transport protocols. To reduce variables, test nodes with similar entry regions and route tiers but different protocols. If one protocol frequently loses packets on the current mobile network while another remains stable, keep the node suited to that network instead of choosing solely by latency.

UDP and QUIC also need separate testing. Normal TCP-based webpages do not guarantee that games or HTTP/3 will work well. Temporarily disable browser QUIC or route the target domain through another node for comparison. If disabling QUIC restores video startup but does not change ordinary downloads, check the node’s UDP support and the ISP’s UDP quality.

Keep test records before updating the core

The client version and mihomo core version affect protocol implementation, the TUN stack, and DNS behavior. Before updating, record four items: Android version, client version, core version, and the last configuration update time. After updating, retest with the same node and test conditions so you can tell whether the change came from the software or the network period.

If everything slows down immediately after an update, open 「Logs」 and check for configuration compatibility errors, then temporarily disable custom overrides. Deprecated fields in an old configuration may be ignored or may prevent a module from starting as expected. If speed returns with the basic subscription configuration, add DNS, TUN, and rule overrides back one at a time to quickly identify the conflicting field.

Final troubleshooting order based on the results

You do not need to change every setting at once. Work in the order “node → route → local,” changing only one variable at each step. This usually narrows down the cause within 15 to 30 minutes.

Record the direct-connection baseline: Turn off Clash and run two speed tests on both Wi-Fi and mobile data.
Confirm the actual node: Open 「Proxy」 and check the proxy group and selected node actually referenced by the rules.
Compare nodes side by side: Test at least three entry points and record latency, download speed, upload speed, and test time.
Update the subscription: Open 「Configuration」, update the current subscription, and confirm the proxy-group selection again.
Switch access networks: Keep the node unchanged and compare Wi-Fi with 4G and 5G.
Check the rule logs: Confirm that the slow target matched the expected DIRECT or proxy policy.
Check Android restrictions: Remove background battery limits and stop other VPNs and network tools.
Separate DNS from throughput: Compare initial response time with sustained downloads instead of mistaking slow resolution for low bandwidth.
Compare TUN: Switch modes under identical conditions and, if necessary, test MTU values of 1500, 1480, 1420, and 1400.
Check versions and overrides: Record the client and mihomo versions, disable custom settings, and test again.

The final diagnosis usually falls into three categories: if only individual nodes are slow, address node quality; if the same node performs very differently on different networks, focus on the ISP route and router; if every node is slow on every network, check Android background limits, TUN, DNS, MTU, the core version, and device performance. Keeping a test table is more effective than repeatedly reconnecting, and makes it easier to verify the result after the subscription or network environment changes.