Why Is Clash Slow? Check Your Node, Network Route, and Local Settings

First, determine whether pages load slowly or downloads stay slow

A normal latency reading in Clash doesn't guarantee fast downloads. Node tests typically send a request through the node to a test URL. Results depend on connection setup, the target server's response, connection reuse, and how the client runs the test. This isn't a bandwidth test, and it doesn't necessarily reflect your experience with video sites or file servers.

Before troubleshooting, choose one affected website, one device, and one node. Pause cloud sync, system updates, and other downloads. Use Rule mode, then check the connection list to confirm the request is using the expected policy group. If it actually matches DIRECT, changing proxy nodes won't test that connection.

Set a speed-test baseline: keep the proxy, node, and target constant

Check the proxy port and actual exit node

The examples below use local mixed port 7890. This isn't a universal default, so first check the client's port settings or active configuration for mixed-port. Use this port for HTTP proxy requests. The dashboard API port is not a proxy port and can't be used in its place.

Run this command in Windows PowerShell. It explicitly uses your local proxy to fetch a small page, making it useful for comparing connection setup and response times, but not for measuring maximum download bandwidth. On macOS or Linux, replace curl.exe with curl.

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 --output NUL --silent --show-error --write-out "connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n" https://example.com/

On macOS and Linux, also replace NUL with /dev/null. Times are in seconds and measured from the start of the request. With an HTTP proxy, time_connect mainly measures the time to connect to the local proxy. time_appconnect also includes waiting for the proxy tunnel and TLS handshake; it isn't a direct measure of node latency. The proxy chain typically resolves the domain, so this command alone can't tell you how fast local DNS is.

Use a sustained transfer to test bandwidth

1. Choose a fixed file you have permission to access, ideally at least 100 MB, and use the same file for every test.
2. Start with a single-connection download. Check the speed after 30–60 seconds of steady transfer, then test your download manager's multi-connection mode.
3. Keep the same node selected. If the policy group switches nodes automatically, select one manually for the test and start a new connection.
4. Record the test time, network, matched rule, node, speed units, and client core details.

Keep the units in mind: 8 Mbps ≈ 1 MB/s. A 100 Mbps broadband connection has a theoretical maximum of about 12.5 MB/s, before protocol overhead. Don't compare a speed test's Mbps directly with a download manager's MB/s.

Layer 1: Check node quality and compatibility with the target

First, find out whether the problem is limited to one node. Choose two nodes in the same region and test each three times against the same target. Keep the region consistent where possible so distance, exit location, and content delivery don't all change at once. If your subscription lists nodes on different routes, compare those too; different names don't guarantee different entry points, servers, or exits.

Low latency doesn't always mean higher throughput

These figures are illustrative, not results from this site or node recommendations. Suppose the same file is tested at the same time: Node A has 65 ms latency and downloads at 0.8 MB/s; Node B has 140 ms latency and downloads at 8 MB/s. For sustained downloads, Node B may be the better choice. For interactive use, also compare time to first byte and consistency. Sorting by latency alone can miss node throttling and load.

• Several sites are slow on one node: Suspect node load, rate limits, or the route to the entry point first.
• Only one site is slow on the same node: Check for server-side throttling, exit location, and CDN routing. This alone doesn't mean the node is generally unreliable.
• All nodes are slow: Check the network route and device, especially home network usage and whether the nodes actually use different exits.

Existing download connections may keep using the old node after you switch policies. Cancel and restart the test, or close only the relevant test connection in the connection list, then verify the new route. Don't compare speeds from the same long-lived connection before and after switching.

Automatic policy groups can also affect results. url-test selects a node based on the configured test target; fallback selects the first available node in order; load-balance distributes connections but doesn't combine bandwidth for a single file download. To evaluate one node, first rule out automatic selection.

Layer 2: Separate network congestion from local access issues

Compare two networks at two times. Keep the computer, client configuration, node, and target unchanged. Test on your home broadband, then on a mobile hotspot, and repeat off-peak. A hotspot changes the ISP route and may also change IPv4, IPv6, and NAT conditions. Use the results to narrow down the cause, not as proof that a particular ISP is imposing a specific restriction.

Rule out saturated uploads and Wi-Fi issues first

When backups, livestreams, or sync tasks saturate your upload bandwidth, download acknowledgments and interactive requests may also get queued. In Windows 11, open Task Manager → Performance → the active Ethernet or Wi-Fi adapter and check send and receive rates. Then sort by network usage on the Processes tab. Pause high-usage tasks, wait about 30 seconds, and test again.

For Wi-Fi, move closer to the router, then compare with a wired connection. 5 GHz isn't always better than 2.4 GHz through walls; actual signal strength and interference matter more. If Ethernet fixes the issue, changing Clash DNS usually isn't the first thing to try.

Treat traceroute as supporting evidence only. Routers along the way may deprioritize ICMP responses, so a timeout or packet loss at one hop doesn't mean forwarded traffic is also being dropped. Consider the final destination, sustained download behavior, and results across different networks together.

Layer 3: Check system proxy, rules, and TUN routing

First, check whether the slow app is going through Clash

The system proxy affects apps that honor system proxy settings; it doesn't automatically capture all traffic. In Windows 11, go to Settings → Network & Internet → Proxy. After enabling the system proxy in your client, check that the address and port shown there match. Browser extensions and app-specific proxy settings may override the system settings.

Open the client's connection list and make a new request. Check the destination domain or IP, matched rule, policy chain, and traffic counters. If there's no matching entry, check traffic interception first. If the connection shows direct, check the rule order. Rules are generally evaluated from top to bottom; an overly broad rule or MATCH placed too early can change what later rules do.

Keep TUN comparison tests to one variable

1. Back up your current configuration and quit other VPNs or proxy tools that create virtual network adapters.
2. Turn off TUN and enable only the system proxy. Test the same target in your browser and record the result.
3. Turn off the system proxy, then enable TUN. Make sure the client has the required permissions and that traffic appears in the connection list.
4. Compare results with the same node and check the logs for routing, DNS, and connection errors.

These steps are for comparing behavior while troubleshooting; they don't mean you must choose one mode for everyday use. TUN routing and DNS interception vary by client, so check the settings for your current version. Enabling TUN doesn't increase a node's bandwidth; its main purpose is to capture traffic transparently.

DNS changes: useful for lookup delays, not a substitute for bandwidth troubleshooting

DNS mainly affects domain lookups, address selection, and some routing decisions. If downloads are fast and stable once connected but the first visit to a domain is consistently slow, check DNS first. By contrast, changing DNS servers usually won't fix a sustained low transfer rate.

Check the active configuration, not just the original subscription

• Check whether the client has modified dns through overrides or merging; the active configuration may differ from the subscription file.
• Make sure the upstream DNS server is reachable. If you're using encrypted DNS, check for connection timeouts too.
• If you're using mihomo options such as respect-rules, check how DNS requests are routed and whether the proxy server's domain can be resolved independently to avoid a dependency loop.
• With fake-ip, some apps receiving mapped addresses is expected. After switching modes, restart the test app to avoid interference from stale cache.

On Windows, run ipconfig /flushdns in a terminal to clear the system DNS cache. It won't clear browser or core DNS caches. The first request after flushing may be slower because it has to resolve the domain again, so don't judge the change by that request alone.

Test IPv6 before disabling it permanently. If logs show repeated IPv6 connection timeouts while IPv4 works, temporarily restrict IPv6 lookups or connections to test. The relevant switches in the operating system, client, and DNS settings aren't the same. Restore the original settings after testing, then fix the configuration based on what you found.

Concurrency settings: distinguish connection racing from multi-threaded downloads

mihomo's tcp-concurrent races TCP connections to multiple addresses returned by DNS. It may reduce connection delays for some destinations, but it won't multiply a node's bandwidth or add download threads. Older Clash versions and other cores may not support the same option, so check the client-reported core and its documentation first.

# mihomo top-level config snippet; merge into your existing configuration
tcp-concurrent: true

This isn't a complete configuration. A/B test this only if you know your core supports it and suspect delays when connecting to multiple addresses. If your subscription is managed remotely, use the client's persistent override feature where available; editing the subscription cache directly may be undone by the next update. After applying the change, check the logs to confirm the field was accepted, then compare time to first response.

Increase download manager connections gradually

For resources that allow segmented downloads, try 1, 4, and then 8 connections. If one connection gets 1 MB/s and four total about 4 MB/s, concurrency is helping with a per-connection limit, but this doesn't tell you whether the limit comes from the server, route, or node. If eight connections are slower than four or make page loads noticeably worse, scale back instead of adding more threads.

Keep an eye on device resources too. In Windows 11, find the proxy core process under Task Manager → Details. On macOS, check CPU and network usage in Activity Monitor. A core pegged at full CPU during a speed test, an overheating device, or a heavily loaded router can limit throughput. Low CPU usage alone doesn't prove the network route is fine.

Narrow down the cause and keep only repeatable changes

State your conclusion in terms of specific conditions, such as “the same node works on a hotspot but slows down on home Ethernet in the evening,” rather than “Clash is unstable.” The first points to a route for further investigation; the second doesn't suggest what to try next.

1. Only some nodes are slow: Keep your results for the same target, switch to a consistently fast node, and report the time and route name to your subscription provider.
2. Everything is slow on the same network: Check upload usage, Wi-Fi, and router load before investigating the ISP route.
3. Only TUN is slow: Test routing conflicts, DNS interception, and MTU one at a time.
4. Only the first page load is slow: Check DNS and connection setup first. For slow sustained downloads, compare nodes, routes, and the origin server.
5. Configuration changes don't produce consistent gains: Restore the original values, remove temporary debugging options, and keep only changes you can explain.

When reporting the issue, include the client version, core name and version, operating system, network type, time of day, proxy mode, and results from three tests. Include only the relevant log excerpts, and redact subscription URLs, access tokens, node passwords, and other credentials. For ports and traffic interception, see the port troubleshooting guide. If you're setting things up for the first time, start with the system proxy setup steps.