Clash Running Slow? A Three-Layer Checklist: Nodes, Routes, Local Settings
Diagnose slowdowns layer by layer — node quality, cross-border routes, and local configuration. Test latency and packet loss, spot peak-hour congestion, and check DNS and rule matching, each with actionable steps.
Why check three layers instead of jumping straight to switching nodes
Slowdowns are one of the most common complaints when using Clash / Clash Meta (mihomo core), but "slow" can stem from any of three layers — a degraded node, a congested cross-border route, or a misconfigured local client. Most people's first instinct is to switch nodes; when a few switches don't help, they suspect the subscription and keep fiddling without finding the root cause. The problem is a lack of layered testing: all three issues look identical on the surface (lag, slowness, pages that won't load), but the diagnostic steps are completely different, and mixing them up just wastes time.
This article breaks the process down from far to near: first confirm whether the node itself is healthy (latency, packet loss, traffic ratio), then check whether the cross-border route is congested (peak hours, egress bandwidth), and finally examine whether local settings are dragging things down (DNS, rule matching, conflicts between TUN mode and the system proxy). Each layer comes with a concrete action you can take, rather than a vague "try a different node."
Make sure both the client and the core are on a reasonably recent version. Older mihomo cores can carry protocol-parsing or connection-reuse performance issues that have since been fixed. Ruling out the version factor first can save a lot of wasted troubleshooting.
Layer 1: Node quality — latency, packet loss, and traffic ratio
Node quality is the easiest layer to verify and the one you should check first. The latency figure shown next to a node in the client UI comes from the proxy group's url-test probe, reflecting the round-trip time from your machine through the node to the test URL. The raw number is only a rough reference — what matters more is whether it stays stable.
| Latency pattern | Likely meaning | Suggested action |
|---|---|---|
| Consistently <150ms with little variance | Node is healthy | No action needed |
| 150–400ms but stable | Long physical distance or inherently higher-latency route | Fine for non-real-time use; pick a lower-latency node for real-time apps |
| Fluctuates wildly, repeated timeouts | Node overloaded or unstable | Switch to another node in the same region to compare |
| Consistently over 1000ms or tests fail outright | Node likely dead or throttled | Switch nodes and report it to the subscription provider |
Besides latency, keep an eye on packet loss and the traffic multiplier. High packet loss causes repeated TCP retransmission — pages stall and video buffers constantly — even though the latency number itself may look fine. That's why relying on the latency figure alone often leads people to conclude a node is "great" when it's actually laggy in practice. The traffic multiplier directly affects perceived available bandwidth: among a batch of shared nodes, a lower multiplier usually means fewer people competing for the same bandwidth, and the gap becomes more obvious during peak hours.
A simple way to verify node stability is to shorten the probe interval on the url-test group, point the test URL at a site closer to your actual target service, and watch the latency curve over several minutes instead of looking at a single snapshot value:
proxy-groups:
- name: Auto Select
type: url-test
proxies: [NodeA, NodeB, NodeC]
url: "https://www.gstatic.com/generate_204"
interval: 300
tolerance: 50tolerance defines a margin within which latency differences won't trigger a switch, preventing nodes from flapping back and forth near a threshold. interval controls how often probing happens — too short adds extra load on the node side, too long fails to reflect latency changes promptly. Somewhere between 180 and 300 seconds is generally a good balance.
Layer 2: Cross-border routes and peak-hour congestion
If a given node shows low latency and minimal packet loss but still feels noticeably slower at certain times of day, the problem is usually the cross-border transit route itself, not the node server. International egress bandwidth is a finite resource — during peak hours (roughly 8 PM to 11 PM local time), a large number of users hitting the same egress simultaneously can drag down effective speed even when the node server's own load is perfectly normal.
Identifying this is straightforward: run repeated speed tests on the same node at different times of day and log the results. If latency and throughput show a clear "day-night pattern" — normal in the early morning, consistently slower in the evening — that's a strong sign of route congestion rather than a node problem. If it's slow at every hour of the day, go back to Layer 1 and re-check the node itself.
Peak-hour congestion on cross-border routes isn't specific to any one client or subscription — it's a structural limitation of international bandwidth capacity. A slowdown during peak hours doesn't necessarily mean the node or client is faulty; re-testing during off-peak hours is usually enough to confirm this.
It's also worth distinguishing between "relayed" and "direct-exit" route structures: the former forwards traffic through an intermediate hop, while the latter reaches the target site directly from the exit server. Relay structures add hops and can introduce additional congestion points. If multiple nodes are available in the same region, test them individually and pick the one with fewer hops and a flatter latency curve as your everyday node, keeping a higher-latency node in reserve for occasional use. Distinguish between the two using the proxy group's manual selection mode, rather than letting auto-test switch back and forth between them.
Layer 3: Local configuration — DNS, rule matching, and mode conflicts
If the slowdown persists after ruling out both the node and the route, it's almost certainly a local client configuration issue. This layer is the most commonly overlooked, yet it's also the most frequent source of "hidden" slowdowns.
DNS resolution mode
Misconfigured DNS can send domain resolution down the wrong path — even if the proxy rules themselves are correct, browsing will feel sluggish, or you'll see "some sites load, others don't." The mihomo core recommends fake-ip mode paired with a dedicated DNS server, to avoid leaking resolution requests to the local ISP's DNS or having them tampered with:
dns:
enable: true
ipv6: false
default-nameserver: [223.5.5.5, 119.29.29.29]
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- "https://doh.pub/dns-query"
- "https://dns.alidns.com/dns-query"
fallback:
- "https://1.1.1.1/dns-query"If you're using redir-host mode, resolution results depend on the local network environment and are more vulnerable to ISP DNS pollution or hijacking. Unless you have a specific reason not to, switch to fake-ip.
Rule matching and proxy group selection
Incorrect rule ordering or outdated rule sets can cause traffic that should go through the proxy to be classified as DIRECT, or conversely, send local-service traffic into a proxy group by mistake — both show up as "the network feels slow." Check the client's connection log or traffic panel to see exactly which rule a given connection matched and which proxy group it was routed through, rather than relying on a subjective impression.
TUN mode vs. system proxy conflicts
Running TUN mode and the system proxy at the same time, or setting the MTU too high under TUN mode (causing fragmentation and retransmission), both lead to a noticeable drop in speed. As a rule of thumb, pick one: use TUN mode when you need to capture global traffic, including non-browser apps; use the system proxy when only a handful of apps like the browser need to go through the proxy. Avoid stacking both, which creates a confusing dual-path setup.
Temporarily disable TUN mode and run a speed test with only the system proxy active. If speed noticeably improves, the issue most likely lies in TUN mode's process rules or MTU setting — you can address that directly instead of second-guessing the node or route.
Summary: the three-layer workflow and a self-check list
Chaining the three layers together into a repeatable diagnostic sequence can dramatically cut down the time it takes to find the real cause, instead of switching nodes over and over without getting anywhere.
Test the node first
Cycle through 2–3 nodes in the same region and watch the latency curve and packet loss over several minutes, ruling out a dead or overloaded node.
Then test the route
Using a node you've confirmed is healthy, run one test during peak hours and one during off-peak hours, and check for an obvious day-night slowdown pattern.
Finally, check local settings
Confirm DNS is set to fake-ip mode, check the connection log to verify rule matching behaves as expected, and make sure TUN mode and the system proxy aren't both enabled.
Log results before drawing conclusions
Record the outcome from each layer separately, then decide whether to switch nodes, switch time windows, or adjust local settings — changing multiple things at once makes it impossible to tell which change actually fixed the problem.
Most recurring "slow speed" complaints ultimately trace back to one of these three layers — and often it's not a single cause but several layers compounding to amplify the perceived lag. Working through them in order, one at a time, is far more time-efficient than switching nodes on a hunch, and it also makes it much easier to describe the exact symptom when reporting it to a subscription provider or a community.
Get the Clash client
If the issue turns out to be a resolution or forwarding inefficiency caused by an outdated client version, head to the download page for the latest actively maintained release, or check the quickstart guide to re-verify your basic configuration.