A Layer-by-Layer Guide to Slow Clash Speeds: Diagnose Node Quality, Network Routes, and Local Settings

First, pinpoint what’s slow: page loads, data transfers, or connection stability

Slow speeds in Clash can have several causes. If a page takes seconds to open but downloads are fast, check DNS, connection setup, and the destination server’s response first. If a download starts quickly and then slows to a crawl, investigate network congestion, node limits, and packet loss. If only one app is slow, check whether its traffic is being proxied and which rule it matches. Identifying the symptom is more useful than immediately enabling TUN or changing DNS.

Here, Clash refers to the client and its proxy workflow; supported features depend on the core in use. Clients running mihomo may differ from older Clash clients in their support for DNS, TUN, and proxy protocols. Before troubleshooting, note the client and core versions from the About page or core information screen. Don’t infer feature support from the app’s name alone.

Create a repeatable test log

• Keep the network constant: Use the same computer and router. Start with Ethernet or Wi-Fi near the router, and pause cloud sync, system updates, and other downloads.
• Keep the destination constant: Use the same website and file source. Speed-test servers and connection counts vary, so results from different sites aren’t directly comparable.
• Keep the proxy policy constant: Record the rule mode, active proxy group, and node. Keep automatic groups from switching nodes during the test.
• Keep the test duration constant: Transfer data continuously for about 30 seconds, record the steady-state speed, and repeat three times. Don’t rely on the first second’s peak.
• Record the conditions: Note the test time, system proxy or TUN status, and the units used for latency and throughput.

Node layer: low latency doesn’t guarantee high download speeds

A client’s node latency usually measures how long the core takes to request a specified URL through that node. The result depends on the test destination, connection reuse, the node’s egress, and the server’s response. It’s not a bandwidth test and may not be equivalent to an ICMP ping. Labels such as “premium” or “high speed” in a subscription are no substitute for testing actual transfers.

Compare two or three nodes under the same conditions

1. Open the proxy group handling the request you’re testing, then manually select node A. If the current policy points to a nested proxy group, check which node the request ultimately uses.
2. Test the same latency-check URL three times. Look for variation and timeouts, not just the lowest result.
3. Transfer a file from the same source for about 30 seconds. Stop the previous download before testing node B.
4. Check the client’s connection list to confirm the requests are using the selected node. Make sure rules aren’t routing the test domain through a different policy.

In this example, A may suit frequent small requests, while B performs better for sustained downloads. Results may reverse on another service because the egress route to each destination differs. If only one node is slow while others work normally at the same time, investigate that node’s load, speed limits, or route to the destination before changing local settings.

What automatic testing groups can and can’t do

url-test selects nodes mainly by latency to a specified URL; fallback typically uses available nodes in order. Neither guarantees the highest throughput. Manually pin a node while troubleshooting, then restore the automatic policy once you’ve identified the issue. Don’t reduce the test interval to just a few seconds: frequent checks add requests and make results harder to relate to real-world use.

Network layer: peak-hour congestion, local networks, and destination routes

A proxy connection passes through your local network, ISP, node ingress, node egress, and destination service. A single latency figure in the client can’t tell you which segment is congested. If speeds drop every evening and recover during the day across several nodes, compare time slots and ingress routes instead of repeatedly refreshing your subscription.

Narrow it down with three comparisons

• Direct vs. proxy: Test a commonly used site that you can access directly. If both are slow, check Wi-Fi, router load, or your broadband connection first. If direct access is fine but proxy connections are generally slow, investigate the proxy ingress and ISP route.
• Broadband vs. mobile hotspot: Keep the device and node the same, but switch to a hotspot. A noticeable improvement points to your original network or ISP route, though cellular signal and hotspot performance can also fluctuate.
• Different destinations: Use the same node to access two services. If only one is slow, its CDN, egress route, speed limits, or account status may be involved. That alone doesn’t mean the entire node is unusable.

For example, the same node may hold steady at 7.5 MB/s at 10:00 but drop to 0.8 MB/s at 21:00, while direct downloads still reach 10 MB/s. That points to a closer look at the proxy route or node load during peak hours, but doesn’t prove that the ISP is throttling traffic. Results from another ingress node and a mobile hotspot will make the conclusion more reliable.

What packet-loss and route tools can tell you

Repeated pings to your gateway can reveal obvious instability on the local link. Pings or traceroutes to a remote IP can provide clues about parts of the route, but intermediate routers may deprioritize ICMP responses. A hop that doesn’t reply doesn’t necessarily mean it’s dropping application traffic. A standard traceroute also won’t show the full path from your device through a proxy node to the destination, so don’t treat it as a complete report on the proxy tunnel.

Local layer: check the system proxy, rules, and actual connections first

The system proxy generally affects only apps that honor the system proxy settings; it doesn’t automatically capture all TCP and UDP traffic. Terminals, games, and some standalone networking components may ignore it. TUN captures eligible traffic through a virtual network interface and routes, giving it broader coverage but adding routing, permissions, and DNS interactions to consider.

Trace traffic using connection records

1. Confirm that the client is in Rule mode, then open the website or app that’s having trouble.
2. Open the client’s connection list and check the destination domain or IP, matched rule, policy chain, and traffic volume. The section may be labeled “Connections” or “Connection.”
3. If the request matches DIRECT, check whether the preceding domain rules, rule sets, or LAN rules are behaving as expected.
4. If the request is proxied through a different node group, check the policy group specified by the rule instead of changing only the most prominent group on the main screen.
5. If there’s no matching connection, check the app’s own proxy settings, proxy bypass list, and whether its traffic is reaching the active core.

Rules are evaluated in order; once a rule matches, later rules generally aren’t checked. To troubleshoot, temporarily switch to Global mode and compare using the same node. If Global mode works normally, focus on rules and policy groups. Global mode changes where traffic from other apps goes, so restore your previous mode when testing is done.

Use an explicit proxy request to rule out app-specific settings

These commands assume the local HTTP mixed proxy listens on port 7890. Check mixed-port in the running configuration and change the port in the command if needed. Use curl on macOS or Linux. In Windows PowerShell, use curl.exe to avoid differences caused by aliases in older environments.

curl --proxy http://127.0.0.1:7890 --noproxy "" \
  --connect-timeout 10 --max-time 20 \
  -o /dev/null -sS \
  -w 'connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n' \
  https://www.gstatic.com/generate_204

curl.exe --proxy http://127.0.0.1:7890 --noproxy "" --connect-timeout 10 --max-time 20 -o NUL -sS -w "connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://www.gstatic.com/generate_204

This 204 request checks connection and response timing, not download bandwidth. Through a local HTTP proxy, time_connect mainly measures the time to connect to the local proxy port; it isn’t the node’s round-trip latency. TLS and time-to-first-byte are measured cumulatively from the start of the request, not as independent phase durations. If the command works normally but the browser is still slow, check its proxy settings, extensions, built-in Secure DNS, and cache.

DNS layer: slow lookups, Fake-IP, and browser Secure DNS

DNS most often affects the first page load and domain-based routing; it usually won’t directly improve throughput for a large file transfer that’s already underway. If a page takes three seconds to load the first time but opens quickly on refresh, DNS, connection reuse, or caching may be involved. That symptom alone doesn’t confirm a DNS problem. Check the logs for lookup timeouts and verify that the connection uses the expected domain.

Check the resolution path actually in use

• Check dns.enable, enhanced-mode, upstream resolvers, and related policies in the running configuration—not just the original subscription file.
• When DNS over HTTPS is enabled in the browser, lookups may go through the browser’s own resolver. Temporarily disable it for comparison, then decide which resolution path to use.
• Make sure upstream resolvers are reachable. Configuring an unreachable resolver can add delays or trigger a fallback.
• If a resolver is specified by domain name, check the bootstrap DNS settings used to resolve it. Otherwise, you may create a circular dependency.

Fake-IP maps addresses to domains and connections so the core can match domain-based rules. A common configuration range is 198.18.0.1/16; these aren’t real website server addresses. An app receiving one of these addresses doesn’t mean the node is faulty. Some LAN services or specialized apps may need to be handled with settings such as fake-ip-filter. Avoid excluding every domain, though, as that can change expected domain-matching behavior.

Don’t switch back and forth between Fake-IP and redir-host by default. Change one setting at a time, restart the affected connections, and clear the DNS cache using the client’s recommended steps if needed. Then repeat the same test. Results from system DNS tools may not reflect what the browser or proxy core sees: an explicit HTTP proxy request often sends the destination hostname to the proxy, so a local nslookup can’t verify the entire resolution path.

TUN layer: coverage, UDP, and routing conflicts

TUN is a way to capture traffic, not a bandwidth-boost switch. If regular webpages already work through the system proxy, enabling TUN won’t necessarily make them faster. Conversely, an app that ignores the system proxy may only use the proxy once TUN captures its traffic. Any improvement comes from changing the traffic path, not from increasing the node’s capacity.

Compare both modes using the same node

1. Save a copy of the configuration and note the node, rule mode, and DNS settings.
2. Turn off TUN first. Test a proxy-compatible browser or an explicit proxy command using the system proxy.
3. Then enable the service mode or grant the required permissions, as directed by the client, and turn on TUN. Confirm that the routes and connection records have changed as expected.
4. If the problem occurs only in TUN mode, check for conflicts with other VPNs, virtual network adapters, routing rules, or DNS interception.
5. Restore your usual settings after testing. Don’t change the TUN stack, DNS, and node protocol all at once before confirming the traffic path.

Browsers typically use QUIC over UDP for HTTP/3. How it’s handled can differ between the system proxy and TUN, and depends on the app, core, and node’s UDP support. If video stalls or some sites behave oddly, temporarily disable QUIC in the app and compare. If TCP works but UDP doesn’t, investigate the UDP route rather than assuming all downloads are affected.

Leave MTU changes until later

If small requests work but larger transfers repeatedly stall—and only with a particular tunnel setup—check the path MTU. Standard Ethernet MTU is often 1500, but encapsulation can reduce the available payload. If you have evidence pointing to an MTU issue, temporarily set the TUN MTU to 1400 for comparison and keep the original value so you can revert. 1400 isn’t a universal optimum. If it makes no difference, restore the original setting and continue checking packet loss and routing.

Also monitor local CPU, memory, and security software activity. If only this device is slow and one CPU core stays near full utilization during transfers, encryption, traffic inspection, or client overhead may be involved. Avoid running multiple speed tests while comparing protocols on older hardware. On managed devices, ask an administrator to review security policies; don’t disable protection just to test.

Narrow down the cause: change one variable at a time

A useful diagnosis identifies which layer and conditions caused a change in the comparison—not just a list of possible causes. Keep before-and-after notes for each configuration change. If you change three settings at once, you won’t know which one fixed the speed, even if performance improves.

When reporting an issue to the node provider or client maintainer, include the client and core versions, operating system, time of occurrence, network type, mode, destination service, three test results, and relevant error excerpts. Before sharing publicly, remove subscription URLs, credentials, node passwords, and access tokens. Full configurations and logs may contain sensitive information.

Recommended order: confirm that the request is actually proxied, compare fixed nodes, check the time of day and network, then investigate DNS, TUN, and local device load. For rule terminology, see the glossary. For specific error messages, see Troubleshooting. Updating a subscription fetches configuration and generally won’t resolve congestion on an existing node’s route.