Clash Running Slow: A Three-Layer Diagnosis for Nodes, Routes and Local Settings

Why "it's slow" needs a layered diagnosis

"Clash feels slow" is a vague complaint that can hide completely different causes: insufficient node bandwidth, upstream route congestion during peak hours, high protocol encryption overhead, or simply a misconfigured local network stack (like a wrong MTU causing fragmentation and retransmission). Skip the layered approach and you'll end up with the classic misdiagnosis: "I tried ten nodes and they're all equally slow, so it must be the client" — when switching nodes never actually bypassed the real bottleneck.

This article walks through diagnosis in the order of node → route → local settings, with a repeatable, comparable test action for each layer instead of guesswork. The order matters: confirm the node is fine, then the route, and only then move to local settings — doing it backwards means you'll keep circling the wrong layer.

Layer one: the node itself — latency, packet loss and bandwidth

The node is the first link in the chain, and the one most often misjudged. Many people only look at the "latency" number in the client UI, but that figure usually just reflects the round-trip time of a TCP handshake or a simple probe packet — it says nothing about actual throughput. A node with very low latency can still have terrible download speed if its bandwidth is shared across too many users.

Start with a basic latency and packet loss check

Run a latency test across the same group of nodes in the client's node list, note the numbers, then switch to a suspicious node and run a continuous ping with the OS's built-in tool to check for obvious packet loss or latency jitter:

ping -c 20 8.8.8.8
# Watch packet loss and avg latency — loss above 5% usually means an unstable link

If packet loss is high and latency jitters wildly (say, bouncing between 80ms and 400ms), the problem is almost certainly the node or its upstream route, not local settings.

Then run a real bandwidth test

Normal latency doesn't mean bandwidth is adequate — you need a separate real download speed test. A common approach is to use a command-line tool to download a fixed-size test file and convert elapsed time to a rate:

curl -o /dev/null -w "%{speed_download} bytes/s\n" http://speedtest.example/testfile

Run the same test on two or three different nodes. If the results differ significantly (say, 5MB/s on one node versus 300KB/s on another), the issue lies with that specific node's bandwidth allocation — switching to a better-performing node solves it, and there's no need to dig into route or local settings.

Layer two: route and protocol — peak congestion and protocol overhead

If the same set of nodes test fine during the day but slow down together during the evening peak, it's likely that the outbound route or exit datacenter has its bandwidth thinned out during congestion — not that a specific node is broken. The verification here is straightforward: repeat the same speed test during an off-peak window. If speed clearly recovers, this confirms time-based congestion rather than a configuration issue — switching nodes or changing settings won't help; you just have to wait out the peak or pick a route with a lighter load.

The extra overhead from protocol choice

Different proxy protocols have different handshake methods and encryption overhead, and on mediocre networks, protocol choice alone can cause noticeable speed differences. Some protocols layered heavily on TLS have higher retransmission cost on weak connections, while lighter protocols have less overhead but may be easier to fingerprint and throttle. If you suspect a protocol-level issue, test different protocol nodes offered by the same exit datacenter at the same time (if your provider offers multiple options) and compare the difference.

Routing overhead under the mihomo core

When using the mihomo (Clash Meta) core, too many rule sets or overly deep GeoIP/GeoSite matching adds extra evaluation time to every connection — especially when rule sets aren't sorted well and frequently-hit rules sit at the bottom of the list. As a quick fix, move your most-visited rules (e.g., direct-connect domains within mainland China) toward the top of the rule list to cut down matching passes per connection. This is a minor optimization outside the route/protocol layer proper, but it has a noticeably direct impact for high-frequency access patterns.

Layer three: local settings — MTU, routing rules and system proxy

If you've tested the first two layers and found nothing, but every node at every hour is slow, the problem is likely in your local network stack or client configuration. This layer is the easiest to overlook because it never shows up in node latency tests.

Check the MTU setting under TUN mode

When TUN mode takes over global traffic, if the MTU (maximum transmission unit) doesn't match your actual network interface, large packets get force-fragmented, adding reassembly overhead that shows up as noticeable slowdowns or occasional stutters on high-latency links. Try setting the TUN MTU to the common value of 1500, or lower it toward 1400 if your carrier recommends it, then rerun your speed test for comparison:

tun:
  enable: true
  stack: system
  mtu: 1500

If speed noticeably improves after the MTU change, fragmentation was indeed the culprit; if nothing changes, you can rule this factor out and keep checking.

Check whether routing rules are sending traffic the long way

Misconfigured custom rule sets can route traffic that should go direct through a proxy node instead, or vice versa — showing up as "some sites are slow, others are fine." Open the client's connections panel and check which rule and outbound node each active connection actually matched, to confirm traffic is flowing as expected.

Check for duplicate proxy layering between system and browser proxies

If you have both a system proxy and a browser extension proxy enabled at the same time, or manually entered a proxy address in the browser while also running TUN mode, traffic may get routed through two proxy layers, adding unnecessary latency. Stick to one proxy method at a time: either let TUN mode handle everything globally, or use the system proxy — don't stack a manually configured browser extension proxy on top.

1. Confirm the TUN mode MTU value matches your local network interface setting.
2. Use the connections panel to verify the actual routing path for frequently-visited domains matches expectations.
3. Disable any manually entered proxy address in browser extensions to avoid stacking with the system proxy or TUN mode.
4. Restart the client and rerun a bandwidth test to confirm the change took effect.

Common misdiagnoses at a glance

The two most common misjudgments during troubleshooting are "switching nodes didn't fix it, so it must be the software" and "a low latency number means it's fast." Cross-reference the patterns below to quickly locate the issue based on the three-layer framework above:

• Every node is slow, and switching time windows doesn't help → check local MTU and proxy stacking first.
• Fine during the day, slow together at night → route peak congestion; wait it out or switch to a lighter-load route.
• One node consistently slow, others fine → that node's bandwidth or upstream route has a problem.
• Low latency number but poor download speed → latency only reflects handshake speed; run a separate bandwidth test.

Going through these four patterns can usually pin down the affected layer within ten minutes, saving you from repeatedly switching nodes or reinstalling the client with no result.