How to Fix Slow Clash Speeds: Check Nodes, Routes, and Local Settings

First, distinguish high latency, low throughput, and stalled connections

Slow speeds in Clash can have several causes. A webpage that takes a long time to load initially may be stuck on DNS resolution or connection setup. A download that stays at a few hundred KB/s points more toward a throughput bottleneck. If video starts smoothly but buffers after a few minutes, check for route instability, congestion at the exit, and which connection the app is actually using. Note the symptoms before changing settings so you don't introduce more variables.

Clash is a proxy core, while mihomo is a compatible core developed along the Clash Meta line. Desktop and mobile clients also handle the interface, system proxy, and configuration management. Settings with the same name may be in different places in different clients, so note the client name and version as well as the core version when troubleshooting. “Latest version installed” isn't enough detail.

Set a baseline: keep the target, time, and connection method consistent

A speed-test button usually measures response time to one specific URL. It doesn't show whether every site is reachable, and it isn't a bandwidth test. An auto-select policy group may switch nodes during the test. For a meaningful comparison, use a group that allows manual selection, pin a node, pause background downloads and cloud sync, then test again.

1. Record the initial state. Back up your configuration and note the rule mode, system proxy, TUN setting, and current exit node. Make sure only one proxy client is running.
2. Test your local network. Run a test from a trusted site that you can access directly. If direct access is slow too, compare a wired connection, Wi-Fi near the router, and a mobile hotspot.
3. Use a fixed proxy test target. Choose a sufficiently large HTTPS download from a source that permits speed testing. Run each test for about 30 seconds, ignore fluctuations in the first 5 seconds, and repeat three times.
4. Check the app's actual route. Find the target domain on the client's Connections page and confirm it uses the expected policy group. Don't rely only on the node name shown on the main screen.
5. Change one variable per round. When switching nodes, don't also change DNS. When testing TUN, don't also switch to a mobile hotspot. At the end of each round, stop the old download and start a new connection.

The table below is an example of how to record results, not a test conducted by this site. Use your own data and keep the test file, device, and time period consistent. Don't use a single peak reading to represent the whole test.

Layer 1: Node quality and policy group selection

The lowest-latency node isn't always the fastest for downloads

A latency test measures the round-trip time of a small request. A node may respond quickly but have limited exit bandwidth, strict concurrency limits, or a poor route to the target site. Conversely, a more distant node may have slightly higher latency but deliver steadier throughput over time. Test web browsing and large downloads separately; don't draw conclusions from latency rankings alone.

• Choose two or three nodes from the same subscription. Compare different entry points or routes where possible, rather than nodes with similar names.
• Check your subscription's remaining traffic, speed limits, and expiration date. Updating a subscription can refresh node information, but it won't increase server-side bandwidth.
• Check nested policy groups. A rule may point to Proxy, which in turn may point to another automatic group. Expand the groups and verify the final node.
• After switching nodes, stop the old download before trying again. Existing connections may keep using the previous exit, so don't treat an old connection's result as a test of the new node.

Avoid interference from automatic switching

url-test primarily selects a route based on latency to a specified URL; fallback focuses on choosing an available option in order; and load-balance may distribute different connections across nodes. None of these proves a node's sustained download performance. If you're using one of these groups, pin an exit through an existing manual-selection group, then test the same resource.

If one node is slow while others perform normally under the same conditions, you've narrowed down the issue. Reinstalling the client or wiping all configuration is unlikely to help. Instead, check that node's entry and exit routes, or send the subscription provider a specific test log.

Layer 2: Access routes, exit paths, and peak-time congestion

A proxied connection involves several segments: your device to the node's entry point, forwarding through the node, and the exit route to the target site. The region in a node's name usually doesn't tell you its entry provider or transit route. Nodes with different names may share an entry point, so a name change alone may not bypass congestion.

Narrow it down with three comparisons

1. Same node, different network. Compare your home broadband with a mobile hotspot. A clear improvement on the hotspot makes your access network or its route to the node more suspect, but doesn't by itself prove your ISP is throttling traffic.
2. Same network, different times. For example, run three tests at 10:00 and three at 21:00. Similar slowdowns on multiple evenings provide stronger evidence of peak-time congestion.
3. Same exit, different targets. Compare legitimate download resources from two different services. If only one site is slow, consider its CDN assignment, per-connection limits, or policies for proxy exits.

Speed-test sites often use multiple connections, while a browser download may use only one or a few, so different results are common. If a speed test is fast but a single-file download is slow, compare single-connection performance instead of assuming the client is “losing speed.” Video sites also adjust download rates based on buffering and bitrate, so they aren't a reliable bandwidth benchmark on their own.

Layer 3: System proxy, rules, and local listening ports

First, check whether the app is going through the client

A system proxy doesn't route traffic from every app on a device. Some apps ignore it, and command-line tools may use their own flags or environment variables. TUN mode uses a virtual network interface to capture traffic that matches routing rules, but behavior still depends on the platform, routes, and exclusions. If a browser works but a game or command-line app is slow, check how its traffic is handled before blaming the node.

On Windows 11, check the manual proxy address and port under Settings → Network & internet → Proxy. On macOS 13 and later, check System Settings → Network → select the current network service → Details → Proxies. Enabling the system proxy in a client usually fills these values in automatically; note the original values before changing them manually.

The following is a partial listener settings snippet, not a complete configuration. 7890 is only an example; use the port actually active in your client when testing. Some clients generate configuration through the interface, so direct edits to a subscription file may be overwritten the next time it's updated.

mixed-port: 7890
allow-lan: false
log-level: info

mixed-port accepts both HTTP and SOCKS proxy requests on the same port. If an app still points to an old port, connections may fail or fall back to a direct connection. allow-lan: false restricts access from the local network; changing it won't improve speeds on the local device.

Check the rule that actually matched in rule mode

On the client's Connections page, check the domain, destination IP, matched rule, and outbound route. A download site in mainland China may be slower through a proxy; a site that should use the proxy may also stall if it matches DIRECT. Rules are generally matched in order, so a broad rule near the top can override more specific rules below it. Policy group names in the subscription must match the names referenced by the rules.

You can briefly use Global mode for comparison, but treat it as a diagnostic tool. If Global mode works and rule mode is slow, check the rules and policy groups rather than using Global mode indefinitely to mask the issue. For details on these settings, see Proxy modes and Ports.

Targeted checks for DNS, TUN, and device load

DNS can explain slow page starts, but not every slow download

DNS resolution happens before a connection is established, and caching or connection reuse can make a second visit faster. If a page takes several seconds to start loading but downloads normally once it begins, check the timing of DNS resolution and connection setup. By contrast, changing DNS usually won't fix a long-running connection that remains slow.

• Check whether the system, browser's secure DNS, and client each have separate DNS settings. A browser's built-in encrypted DNS may bypass the resolution path expected by the client.
• With fake-ip enabled, a mapped address returned by the system doesn't mean DNS failed. For example, the 198.18.0.0/16 range may be used as a fake-ip address pool; check the active configuration to confirm.
• If you suspect an IPv6 routing issue, temporarily compare IPv4 and IPv6 and note how to restore the original settings. Don't permanently disable IPv6 across the system just because one site is slow.

Test the TUN setting by changing one variable at a time

First, test with the system proxy using a browser known to support HTTP proxies. Then test TUN without changing the node or target. If performance drops only in TUN mode, check for other VPNs, virtual machine networking, route conflicts, and client logs. After switching traffic interception methods, confirm the target still uses the same exit; otherwise, the results aren't directly comparable.

An MTU mismatch can make small requests work while large responses stall, but that symptom alone isn't conclusive. Don't copy a supposedly “universal best MTU.” To test it, record the original value, change one setting at a time in a client that supports it, reconnect, and retest; restore the original value if there's no improvement. TUN stack support and behavior also vary by platform and core version, so no single stack should be assumed to be faster in every case.

High CPU load and log writing can also reduce throughput

In Windows Task Manager, go to Performance → CPU and switch the graph to logical processors. In macOS Activity Monitor, open CPU and check the client and core processes. Even when total usage is low, one core may be close to maxed out. Older devices, complex rules, and many concurrent connections can all increase processing load.

For routine diagnostics, start with the info log level. Switch to debug briefly if you need more detail, reproduce the issue once, then switch it back. Writing large amounts of debug logs continuously adds overhead and may expose sensitive browsing information. Redact subscription links, tokens, node passwords, and personal domains before sharing logs.

Wrap up with evidence, then restore temporary settings

By the end of troubleshooting, you should have a reproducible finding, such as “same file and network: node A averaged about 1 MB/s over three runs, while node B averaged about 7 MB/s,” rather than simply “it gets really slow at night.” These figures are examples; what matters is recording the conditions and getting repeatable results. When contacting your provider, include the time with its time zone, access ISP, node identifier, and client and core versions. Don't send your full subscription.

Finally, restore any temporary Global mode, debug logging, and network settings, then confirm they still work as expected after a subscription update. Speed tests use real data; keep them brief on mobile hotspots and metered plans. If you still can't identify the cause, continue with the connection troubleshooting guide or return to the setup guide to review the basic configuration steps.