Clash Slow Download Speed? Troubleshoot Nodes, Routes, and Local Settings

Slow speeds in Clash don’t always mean a node lacks bandwidth. A long wait for the first page load, video buffering after playback starts, and consistently slow downloads can point to DNS resolution, route congestion, or local traffic-routing issues. Identify the symptom first, then check one layer at a time. That’s more effective than changing DNS, nodes, and TUN settings all at once.

Before you start: establish a repeatable speed test baseline

Pause cloud syncing, system updates, and other large downloads. Use the same device, network, and test destination throughout. In rule mode, check the connection details to see which rule, policy group, and node handled the traffic. A test that didn’t use the intended node can’t tell you how that node performs.

1. Record your setup: Note the client and core versions, operating system, network type, node name, and whether system proxy and TUN are enabled. Find the core version in the client’s About page or startup logs.
2. Fix the policy: Select a node manually from the client’s proxy or policy group page so an automatic group doesn’t switch routes mid-test. If your configuration doesn’t allow manual selection, note which node handled each connection.
3. Measure separately: Record initial page response time, sustained download speed, and failed requests. Repeat each test three times, about 30 seconds apart. Don’t treat a one-off peak as your steady speed.
4. Use consistent units: 100 Mbps works out to about 12.5 MB/s in theory, before protocol overhead. Don’t compare the client’s MB/s readout directly with your broadband plan’s Mbps figure.

Layer 1: Node quality and real-world throughput

Node latency doesn’t equal download speed

A client’s latency test usually sends a request to a specific URL. It measures the response along that probe path, not sustained transfer capacity. A node showing 60 ms may download slowly if its exit bandwidth is shared; one showing 160 ms may deliver more consistent throughput. A url-test policy group isn’t an automatic bandwidth tester either.

Choose two or three nodes in the same region and download the same file through each one. Run three tests per node, keeping the test URL, connection count, and duration consistent. If just one node is much slower, start by investigating that node. If all are slow, check whether they share an entry point or relay.

Retest using an explicit proxy port

On desktop, use curl with an explicitly specified HTTP proxy to rule out command-line apps that don’t read system proxy settings. The example below uses local HTTP or mixed port 7890, confirmed to be listening. Port 7890 isn’t the default for every client, so check your current port first. The command downloads about 10 MB from a public test endpoint and uses that much data.

# macOS / Linux; curl must be installed locally
curl --proxy http://127.0.0.1:7890 --output /dev/null --silent --show-error --max-time 60 --write-out 'connect=%{time_connect}s tls=%{time_appconnect}s first=%{time_starttransfer}s total=%{time_total}s speed=%{speed_download}B/s\n' 'https://speed.cloudflare.com/__down?bytes=10000000'

# Windows PowerShell; explicitly call curl.exe
curl.exe --proxy http://127.0.0.1:7890 --output NUL --silent --show-error --max-time 60 --write-out "connect=%{time_connect}s tls=%{time_appconnect}s first=%{time_starttransfer}s total=%{time_total}s speed=%{speed_download}B/s\n" "https://speed.cloudflare.com/__down?bytes=10000000"

speed_download is measured in bytes per second. For example, 2500000 B/s is about 2.5 MB/s. This is an example reading, not a measurement from this site. Short downloads can be affected by the handshake, so use the result only for a rough comparison. Also retest the site you’re actually having trouble with; one speed test service can’t represent every type of traffic.

Layer 2: Entry points, relays, and exit routes

Different node names don’t necessarily mean completely independent network routes. Nodes labeled with different regions may still share an entry point or relay resources. If several nodes slow down at the same time, switching regions alone may not help.

Compare times and networks

• Compare times: Test the same node and file at, for example, 10:00 and 21:00. If speeds consistently drop only in the evening, suspect peak-hour congestion before changing local DNS.
• Compare networks: Connect the same device to your home broadband and a mobile hotspot. Check your data allowance before using the hotspot, and pause background downloads. If only your home connection is affected, investigate your router, ISP routing, and Wi-Fi.
• Compare entry points: If your provider clearly identifies different entry points or route types, compare them while keeping the destination region the same. Don’t assume a label such as “dedicated line” guarantees better performance.
• Compare destinations: Visit two different sites through the same node. If only one is slow, the cause could be the destination’s CDN, account throttling, exit region, or server load.

Pinging a node server from your device offers only limited clues about reachability. Some servers don’t respond to ICMP, and some intermediate routers deprioritize ICMP traffic. Packet loss shown at an intermediate hop doesn’t prove that application traffic is also being dropped there if later hops and the final destination are fine. Use actual HTTPS requests and sustained transfer results to assess the connection.

If the same node is slow on two different networks while another independent route works normally, switch to the stable route for now. Send your provider the test time, ISP, node name, and results. Don’t share your full subscription URL, node password, or configuration containing credentials.

Layer 3: Local DNS and TUN settings

Tell slow DNS lookups apart from slow transfers

DNS problems often show up as a delay on the first visit, intermittent lookup failures, or a domain resolving to an unsuitable address. They usually don’t explain a download connection that’s already established but stays very slow. Check client logs for repeated DNS timeouts, unreachable upstream servers, or lookup failures before changing DNS settings.

When using mihomo, check the effective configuration for dns.enable, dns.enhanced-mode, and dns.nameserver, as well as tun.dns-hijack when TUN is enabled. These are fields to inspect, not settings that should all be changed to specific values. GUI clients may generate runtime files by merging or overriding configuration. Editing a cached subscription file directly may have no effect after the next update.

• Check upstream reachability: Encrypted DNS still needs a working network route. If it depends on a proxy, but the proxy server’s hostname relies on the same DNS route, startup can get stuck in a dependency loop. Follow the core’s documentation to configure lookups for regular domains and proxy server hostnames separately.
• Understand the mode: fake-ip returns virtual addresses for mapping; that doesn’t mean DNS is broken. Don’t change DNS just because you see an address in the 198.18.0.0/16 range. The effective configuration determines the actual address pool.
• Check browser behavior: A browser’s Secure DNS may send its own HTTPS-based DNS requests and might not be affected by traditional port 53 interception. Temporarily turn off Secure DNS in the browser for a comparison, then restore the original setting.
• Change one thing at a time: Adjust just one DNS source, reconnect, and compare the time to first load. Don’t change DNS in the system, browser, router, and client all at once.

Compare system proxy and TUN one at a time

System proxy works only with apps that support and read proxy settings. TUN routes traffic through a virtual network interface, so the two modes don’t cover the same apps. Choose a browser known to support HTTP proxies or use the curl command above. First turn off TUN and confirm the explicit proxy request works, then test TUN. Check the connection details to make sure both tests used the same node.

1. Save your current configuration, then disconnect other VPNs, game boosters, and network filtering tools to prevent multiple virtual adapters from competing for routes.
2. Turn off TUN and test the same HTTPS resource through your confirmed local proxy port. Record the speed and any errors.
3. Turn on TUN and retest with a normal network request. Check the connection details to confirm the traffic is being routed through TUN; an explicit proxy command alone can’t confirm that TUN is working correctly.
4. If only TUN is affected, check permissions, routes, DNS interception, and client logs. Don’t start by replacing every node.

Layer 4: System load and local network

Check whether your device is running out of resources

On Windows, press Ctrl + Shift + Esc to open Task Manager and check CPU, network, and disk use under Processes and Performance. On macOS, open Activity Monitor and check CPU and Network. Watch the client’s core process during the test, not just its interface process. A single core can be close to maxed out even when overall CPU usage looks low.

Low-powered routers, older phones, and virtual machines can hit performance limits during encrypted transfers or when handling many connections. Pause multithreaded downloads and retest with a single connection. If speeds improve as CPU usage drops, reduce concurrency or switch to a more capable device instead of piling on more rules and features.

Rule out Wi-Fi, background traffic, and port conflicts

• Wi-Fi: Retest near the router, or use Ethernet if possible. A 5 GHz network is generally better for high-throughput testing when the signal is strong, but compare results in your actual setup, especially if there are walls in the way.
• Background tasks: Pause cloud drives, backups, updates, and game downloads. Check whether your upload bandwidth is saturated; congestion upstream can slow page loads and download acknowledgements.
• Local listening ports: If logs show address already in use, resolve the port conflict first. On Windows, run netstat -ano | findstr :7890 to see related connections and listeners, then check the PID. A port conflict affects startup or traffic interception; it isn’t node throttling.
• Security software: Check whether HTTPS scanning, network filtering, or traffic inspection is enabled. Temporarily test the relevant feature only as documented by the software vendor. Don’t leave your firewall disabled or add broad allow rules covering every app.

If sites that normally connect directly are still slow after you quit the client, troubleshoot your local network first. Conversely, a normal direct speed test doesn’t prove the proxy route is working properly: the two types of traffic may use different servers and ISP peering routes.

Final checks: verify changes and keep a record

After making an adjustment, establish a fresh test connection. Switching modes or policy groups doesn’t necessarily move existing long-lived TCP connections right away. If your browser reuses an old connection, results may still reflect the previous node. Stop the current download and start a new request. If needed, close only the connection you’re testing rather than clearing every app session.

1. Retest under the same conditions: Use the same device, network, destination, and test method for three runs. Compare the typical result and its variation, not just the highest speed.
2. Check the app you’re actually using: Confirm that the video, website, or download that was stalling has improved. If the speed test endpoint is faster but the app isn’t, check its routing rules, destination, or protocol path.
3. Keep only changes that help: Revert DNS, MTU, or policy group changes that made no difference. That way, you won’t have a pile of unexplained variables to deal with next time.
4. Prepare useful details: Note when the issue occurred, client and core versions, network type, whether TUN was enabled, results from both comparison tests, and a concise error log. Before sharing logs, remove subscription URLs, credentials, and personal browsing history.

To troubleshoot slow Clash speeds, first standardize your test conditions, then check node throughput, route changes, local DNS and TUN, and finally your system. Latency is only one clue. Make changes based on tests you can reproduce, compare, and roll back. For configuration fields and rules, see the Protocol Reference. For basic connection issues, check the FAQ.