Break slow speeds into three layers: node quality, transit route, and local client settings. Follow the test steps and pass/fail criteria for each layer to find the bottleneck in 10 minutes instead of randomly switching nodes.
Slow speed is one of the most common complaints with any proxy tool, but the root cause can sit in three completely different places: the node itself, the transit route between your device and the node, or the local client configuration. Many people switch nodes the moment things feel sluggish, and after trying three or four with no improvement, they conclude "this subscription is bad." In reality the problem might be stuck in a local DNS setting or rule matching the whole time, with nothing to do with the node at all.
Randomly swapping nodes has two costs: it burns through your high-multiplier paid node quota, and it hides the actual point of failure, so the same issue keeps coming back. Checking layer by layer works better because each layer has clear test steps and criteria — once you finish a layer, you can either rule out or confirm a category of causes, narrowing things down to a specific step in about 10 minutes.
Node quality refers to the proxy server's own response speed, load, and line bandwidth — it has nothing to do with your local setup. This layer is the easiest to verify and should be the first one you rule out.
Most Clash clients (including those built on the Clash Meta kernel, mihomo) have a latency test button in the node list — click it and each node shows a number in milliseconds. Rough guidelines:
| Latency Range | What It Means for You |
|---|---|
| Under 200ms | Normal — browsing and video loading should feel fine |
| 200ms ~ 500ms | Usable, but pages may load with a slight delay; not ideal for latency-sensitive use |
| Above 500ms or timing out | This node is likely overloaded or has a line issue — best to avoid it |
A latency test measures connection response time, not download speed, but the two are closely linked: a node with consistently high latency will almost never give you good download speeds. If latency looks fine but downloads are still slow, the problem isn't at this layer — move on to Layer 2.
Don't draw conclusions from a single node. Pick 2–3 nodes from different servers or regions within the same subscription and test each one. If all of them are slow, the issue is likely the route or your local settings; if only one or two specific nodes are slow, it's a node-side load issue — just switch to a healthy one and you're done, no need to dig further.
Some providers throttle high-multiplier nodes, or automatically slow things down once your account is close to its data cap. In these cases, the latency test may still look normal while actual download speed is clearly capped. Check the remaining data and expiration date in your client's subscription info to rule out plan-level limits.
The route is the entire path your data takes from your device, through your local network and your ISP's backbone, all the way to the proxy server. Issues at this layer usually can't be fixed by the proxy software itself, but testing helps you confirm the real culprit instead of blaming the app.
Turn off the proxy and run a plain download speed test on your local network (use your ISP's speed test tool, or just time a large file download). If the direct connection is already slow, the issue is your broadband or Wi-Fi signal — completely unrelated to Clash. Fix the network itself first.
If the direct connection is fine but things slow down through the proxy, use a route tracing tool to see what happens along the path. On Windows, run this in the command line:
tracert target_server_IPOn macOS or Linux, run:
traceroute target_server_IPWatch for two things: which hop is where latency suddenly spikes, and whether there's heavy packet loss (shown as asterisks *). If latency climbs gradually across the international hops, that's just normal distance-related delay. If one hop suddenly jumps by hundreds of milliseconds and stays high for the rest of the trace, that carrier's node is congested.
The same provider often offers nodes on multiple protocols (Shadowsocks, VMess, Trojan, Hysteria2, etc.). Different protocols behave differently depending on the carrier's network — some ISPs throttle UDP traffic heavily, so a QUIC/UDP-based protocol like Hysteria2 can actually get throttled harder than TCP-based protocols on certain networks. If your subscription has nodes in the same region on different protocols, compare them directly.
Between 8 PM and 11 PM, outbound bandwidth from mainland China tends to get most congested. It's common for the same node to be fast during the day and much slower at night — that's a normal route-level fluctuation, not a config issue. Test again at a different time to confirm.
Once the first two layers are ruled out, what's left is almost always a client-side configuration issue. Problems here can be hard to spot, but once found, the fix is usually as simple as flipping one setting.
If enhanced-mode is misconfigured, or the system DNS conflicts with Clash's own DNS settings, the same domain might get resolved twice — sometimes even falling back to your local ISP's DNS — adding unnecessary latency. Check the dns section of your config, make sure nameserver points to fast-responding resolvers, and confirm fallback isn't being triggered frequently (frequent fallback triggers mean your primary resolver is unstable).
In Rule mode, a request can get misrouted to a throttled node — or sent direct and then throttled by the ISP — because it matched the wrong rule. This shows up as "pages load slowly" even though the client reports the node as healthy. Open the connection details panel (usually under the "Logs" or "Connections" tab) and check which rule and policy group the domain actually matched, to confirm it isn't hitting an unexpected rule.
TUN mode intercepts traffic at the network adapter level, while system proxy sets an HTTP/SOCKS proxy at the application level. They work on different layers, and if both are active at once, some traffic can get processed twice or take a detour, causing unexplained lag. Make sure only one mode is enabled — keeping TUN mode alone is usually enough to cover all traffic.
Local firewalls, security software, or a misbehaving virtual network adapter can sometimes do deep packet inspection on Clash's mixed port (default 7890), slowing down forwarding. Try temporarily disabling third-party security software to test — if speed clearly improves, that software's traffic inspection is the bottleneck, and you'll need to whitelist Clash's processes.
Older client versions may lack optimizations for kernel forwarding efficiency, especially if the kernel hasn't been updated in a while alongside the Clash Meta / mihomo mainline — forwarding performance falls noticeably behind. Check whether your client and kernel are on a recent release; if not, update to the current maintained version.
| Symptom | Likely Cause |
|---|---|
| Latency test looks fine, but pages load slowly | DNS resolution or rule matching error |
| Switching nodes doesn't help | Local settings or route issue, not a node problem |
| Speed returns to normal once the proxy app is closed | The client itself is hogging resources or has a port conflict |
| Only slows down at certain times | ISP route congestion during peak hours |
If you took a wrong turn, just back up one step — the 3-layer check is essentially a process of narrowing things down step by step. You don't need to memorize every detail; just follow the test steps in order, and the answer usually shows up partway through.