Clash Slow Speeds: Check Node Quality, Network Congestion and Local Settings

First distinguish high latency, slow downloads and slow page loads

The latency shown in a Clash client is usually a probe result from the core connecting to a test address through the selected proxy. It does not measure sustained download bandwidth. The test address, timeout and client implementation all affect the result. A node showing 80 ms may still download very slowly because its outbound connection is rate-limited; a distant node showing 220 ms may sustain a much higher throughput.

Before troubleshooting, describe “slow” in observable terms. Record the operating system, client name, core version, active configuration, proxy mode, selected node and network where the issue occurs. The client version and core version are separate details; check the version information or startup logs for each instead of just writing “latest version.”

Keep test conditions consistent and change one variable at a time

Pause background downloads, cloud sync and other speed tests first. Keep your Wi-Fi position consistent; if possible, run a comparison over a wired connection. Note any VPN, transparent proxy or traffic-routing service running on your router too, so you don't mistake a double-proxy setup for a single connection.

1. Measure your local baseline: Turn off the client's system proxy and TUN, and make sure your browser isn't using a separate proxy. Then test with a speed-test service directly reachable from your local network and record download, upload and latency. This checks your access connection, not the proxy exit's performance.
2. Keep the destination fixed: Choose an HTTPS download resource that permits testing. Use the same URL, download method and number of connections for every node. Don't introduce different speed-test servers as another variable.
3. Keep the exit fixed: Set the policy group actually handling the request to one manually selected node. This prevents automatic selection or failover from switching exits mid-test.
4. Run three rounds: Test for about 30 seconds each, with roughly 15 seconds between rounds. Record the median and note the time of day. Large downloads use subscription data, so shorten the tests if needed.

After switching nodes, stop the old download and start a new connection. Existing TCP connections usually won't move to a different exit just because you changed the policy group. If you need to clear connections, close only those belonging to the test app where possible, so other active tasks aren't interrupted.

For example, a log might read “Node A: 2.1, 2.4, 2.2 MB/s; median 2.2 MB/s.” This is just an example format, not a test performed by this site. Record failures as well: two timeouts in three attempts say more about reliability than a single peak speed.

Node quality: compare single-node throughput and destination performance

Node quality depends on reachability, server load, rate limits and the connection from the exit to the destination site. If a client's one-click test only probes latency, it can't tell you the node's bandwidth. Pick two or three candidate nodes from the same subscription, test each against the same fixed destination, then check how they perform in your actual use case.

Check connection logs to confirm the test used the intended node

1. Open the client's Connections page and start a new download request.
2. Filter by destination domain or process, then check the matched rule and full policy chain.
3. Confirm the final exit is the node you selected—not DIRECT or a different policy group.
4. If you use proxy-providers, check whether that proxy collection has updated and review its health-check status. This is separate from updating the full configuration file.

If node A is slow across several destinations while node B is clearly faster at the same time, suspect A's load, bandwidth limits or route first. If only one site is slow through the same node and other downloads are fine, the issue is more likely the route to that site or its CDN assignment—not a sign that the entire node is down.

Network congestion: compare times of day and access networks

A region in a node's name usually describes the exit location, not the full route from your device to the entry point and then to the exit. Nodes in different regions may share an entry point or relay, so switching regions and still seeing slow speeds doesn't rule out a route issue.

Compare across two dimensions

• Same network, different times: Test the same node and destination at, for example, 10:00 and 21:00. A clear slowdown on multiple evenings is stronger evidence of peak-hour congestion than one isolated slow test.
• Same time, different networks: Within a few minutes, compare your home broadband with a mobile hotspot. Keep the client, node and destination the same, and account for the hotspot's signal strength and data-plan limits.
• Same network, different entry routes: If the provider documents its routes, compare nodes with different entry points. Don't assume routes are independent based on node names alone.

If several nodes are slow on home broadband but recover on a hotspot, the issue is more likely with your home connection, ISP peering or local router. If the same node is slow on both networks while other nodes work normally, focus on that node and its exit. These results help narrow things down, but a single test isn't conclusive.

Check whether your router's latency spikes during heavy uploads. Upload saturation can cause queueing delays that affect web pages and interactive requests. If things recover when uploads pause, check bandwidth usage and the router's queue management first. Intermediate routers often ignore probe packets; packet loss at a single hop doesn't necessarily mean application traffic is being dropped.

Rules and DNS: trace the actual path of slow requests

For diagnosis, use rule mode and check which rules actually match. Clash and mihomo rules are generally evaluated in order, so an earlier rule can take precedence over a later domain rule. The final MATCH rule catches anything unmatched; adding a destination domain after it usually won't work as intended.

Use global mode briefly as a comparison, not as a permanent workaround

If you understand the active configuration, switch briefly to global mode and explicitly choose the node used by the global policy. If the same node works in global mode but not in rule mode, check whether rule mode selected a different policy group, a direct connection or a chained route. Restore the original mode afterward; global mode may route traffic that should go direct through the proxy.

Tell DNS delays apart from slow data transfers

• Only the first visit is slow, while later requests are fast: check lookup time, caching and connection reuse before changing every DNS setting.
• One domain fails while other sites work: check the logs for DNS timeouts and confirm the upstream DNS server is reachable.
• The browser behaves differently from other apps: check its Secure DNS settings, which may bypass the system's DNS resolution path.
• After enabling Fake-IP, you see an address in 198.18.0.0/16: this may be a normal virtual mapping. That address alone doesn't indicate a DNS failure; check the configured subnet.

In mihomo, dns.nameserver, dns.proxy-server-nameserver and dns.nameserver-policy cover regular DNS resolution, proxy-server hostname resolution and per-domain resolver selection, respectively. Their behavior also depends on the full configuration. Don't paste a DNS snippet from the web into an existing subscription without checking how it fits. Back up the configuration first, change one setting at a time, reload and start a fresh test connection. See the DNS chapter in the complete guide for field details.

System proxy and TUN: check app coverage and local overhead

A system proxy mainly serves apps that honor the system proxy settings. TUN uses a virtual network interface and routing to capture more IP traffic, but its actual coverage still depends on route exclusions, app-bound interfaces and the client implementation. TUN isn't a speed boost and can't bypass node rate limits.

Isolate the issue with an explicit proxy first

The commands below assume a local HTTP or mixed proxy is listening on 127.0.0.1:7890. Check the actual port in the client's settings first; 7890 isn't a universal default. On Windows, use curl.exe to avoid conflicts with a same-named alias in some PowerShell environments.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 \
  --output /dev/null --silent --show-error \
  --write-out "connect=%{time_connect}\nTLS=%{time_appconnect}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\n" \
  https://www.example.com/

This short-request diagnostic command is for macOS, Linux and similar environments; it isn't a bandwidth test. On Windows, replace curl with curl.exe, change the output target to NUL, and put the command on one line. Timings are in seconds and measured from the start of the request. With a local HTTP proxy, time_connect mostly measures the connection to the local proxy listener, not latency to the remote node.

If an explicit proxy request works but regular apps are still slow, check whether those apps honor the system proxy, whether a separate proxy extension is installed and whether the system proxy points to the current client port. If the request is refused, first check that the core is running, the listening address is correct and the port isn't in use. Don't switch DNS settings first.

Test the two traffic-capture methods separately

1. Save your current settings, turn off TUN and enable only the system proxy. Test the same destination in the same browser.
2. Then turn off the system proxy and enable only TUN. Confirm the test request appears in the connection log, then run the test again.
3. Watch core CPU usage in Task Manager or Activity Monitor, and check whether another VPN or virtual network interface is also changing routes.
4. If stuttering occurs only with TUN, check the client logs, route conflicts and compatibility with your current network. Then compare protocol-stack settings within the options supported by your client.

A sustained near-full load on one CPU core while throughput is limited can point to a local processing bottleneck. Don't change the TUN protocol stack, MTU and DNS all at once. Change MTU only when there is evidence such as large transfers getting stuck, and compare results rather than treating one value as a universal fix.

Narrow the results down to a reproducible issue

Change one setting at a time and save results from before and after. The patterns below can guide your next step, but check the logs and repeat the tests too:

When reporting an issue to a client maintainer or subscription provider, include your OS version, client and core versions, the time of the issue, access network, reproduction steps and redacted logs. Remove subscription URLs, tokens, credentials and any unnecessary visited domains. Upgrade the client or core only when you find a compatibility issue or a specific fix in the release notes, and keep a copy of the original configuration so you can roll back.

Follow this order: measure the local baseline, compare throughput with a fixed node, cross-check the network route, then review rules, DNS and traffic-capture settings. For subscription errors or unusual latency, see the latency troubleshooting guide. If you're not sure how to import and enable a subscription, start with the subscription setup tutorial.