How to Fix Slow Clash Speeds: A Three-Layer Checklist for Nodes, Routes, and Local Settings

Break “slow speeds” into measurable problems first

The latency shown in Clash, webpage load time, and file download speed are different metrics. A latency test usually requests only a small HTTP resource to measure connection setup and response time. Download speed is also affected by the destination server’s bandwidth, international routing, TCP congestion control, protocol overhead, and local Wi-Fi. A node showing 68 ms is not guaranteed to saturate your connection; a node showing 145 ms may still stream video without buffering.

Lock down your variables before troubleshooting. Do not switch nodes, change DNS, and enable TUN at the same time, then draw conclusions from a single speed test. Record your current network, proxy mode, node name, and test time. Test in this order: direct-connection baseline, single-node latency, single-connection download, and multi-connection download. Run each test at least three times and use the median instead of looking only at the highest result.

Build a reproducible baseline

Pause Clash’s system proxy and TUN mode, then test the direct connection on the same device. If a 500 Mbps broadband connection reaches only 35 Mbps directly, check the Wi-Fi, Ethernet cable, or ISP network first.
Enable Clash again, select Rule mode, and pin one node. Do not use a proxy group that automatically switches between members.
Pause cloud-drive sync, system updates, game downloads, and background browser video so they do not consume bandwidth.
Test at 09:00, 20:00, and 23:00. A sharp drop during the evening peak is more likely to indicate route congestion than an incorrect client setting.
Record latency, download speed, upload speed, packet-loss behavior, and the target site. Only results from the same test target are suitable for comparison.

Test	Sample result	What it helps determine
Direct download	468 Mbps	Whether the local access network is working normally
Node latency	82 / 86 / 80 ms	Connection stability and baseline round-trip time
Proxy single-connection download	6.8 MB/s	Route quality for a single connection
Proxy multi-connection download	22.4 MB/s	Total node bandwidth and concurrency capacity

Layer 1: Check node quality and protocol overhead

Once the baseline is complete, start with the easiest layer to replace: the node. Region labels in a subscription are only labels. “Hong Kong 01” and “Japan 02” do not directly reveal the entry location, egress carrier, or evening capacity. What matters is consistent testing across different times and the actual route used to reach the target site.

Judge latency by stability, not just the minimum

Run three to five consecutive latency tests from the client’s proxy or policy page. Results of 75, 79, and 81 ms are generally more stable than 42, 180, timeout, and 96 ms. Although the latter produced 42 ms once, real-world use may involve frequent retransmissions or stream drops. The test URL also affects results. Keep the client’s default URL or use a fixed HTTPS URL that reliably returns a small file; do not change it repeatedly during comparison.

Below 80 ms: Usually suitable for webpages, instant messaging, and latency-sensitive interactions, but bandwidth still needs to be verified.
80 to 180 ms: A common range for international connections. Video and downloads mainly depend on route stability.
Above 250 ms: Initial webpage responses, remote terminals, and real-time operations may feel noticeably sluggish.
Frequent timeouts: Treat this first as an unreachable node, unreachable test target, or unstable link—not simply “high latency.”

Traffic multipliers affect billing, not speed directly

“0.5×,” “1×,” and “2×” in node names usually refer to the subscription service’s traffic multiplier. Downloading 1 GB through a 2× node may count as 2 GB of usage, but the multiplier itself does not guarantee higher speed. A high-multiplier node may use a more expensive route, or simply belong to a different resource group. Compare real results at the same time and against the same target.

Protocols and encryption consume CPU

On modern desktop processors, common proxy protocols are usually not the first bottleneck. Older routers, low-power mini PCs, and entry-level Android devices can hit a single-core limit during high-speed transfers. Open Task Manager or Activity Monitor while testing. If mihomo, Clash, or the client core stays near one CPU core’s maximum while speed stops increasing, investigate device performance, protocol parameters, and encryption overhead.

Stop duplicate proxy cores and make sure only the active client is listening on the proxy port.
On desktop, prefer the stable mihomo core version supported by the current client. Do not mix in old core files from unknown sources.
If Clash runs on a router, import the same subscription into the desktop client for comparison. If desktop is fast but the router is slow, the bottleneck is usually the router’s CPU, memory, or network interface.
Do not casually modify protocol fields supplied by the subscription for the sake of testing, such as the transport layer, server name, or Reality parameters. They must match the server side.

Layer 2: Identify entry, egress, and evening peak congestion

A usable node does not mean the route from your ISP to its entry point is always clear. The home broadband-to-entry route, entry-to-egress route, and egress-to-target route are three separate links. Congestion anywhere along the path can appear as normal latency with poor download speed, or as normal daytime performance that deteriorates at night.

Use time and network comparisons to locate congestion

The most effective approach is not cycling through dozens of nodes, but running a small controlled comparison. Choose two nodes in the same region and two in different regions, then record results against a fixed target. Switch the computer from home Wi-Fi to a mobile hotspot and test the same node again. If home broadband reaches only 3 MB/s while the hotspot reaches 14 MB/s, the issue is more likely the path from your local ISP to the entry point. If both networks are slow, continue investigating node capacity or egress quality.

Symptom	Most likely cause	Next step
18 MB/s during the day, 2 MB/s at night	Evening peak congestion on the route or at the node	Try a different entry route or retest outside peak hours
Stable latency, slow on one connection, fast on multiple connections	Single-connection limits or packet loss on the international route	Change routes and test with the actual application
All nodes slow down at the same time	Local network, subscription entry point, or upstream outage	Test direct access and a mobile hotspot
Only one target site is slow	The target site’s egress, routing, or CDN path	Check the matched rule and egress region

Geographic distance is not the only factor

Shorter physical distance usually helps reduce latency, but route quality can change the outcome. A user in Shanghai may not always get better performance from a Hong Kong node than from a Tokyo node. A Tokyo route with stronger carrier interconnection may perform better during the evening peak. Also consider the target service’s CDN routing and access restrictions. The best node for software repositories, video streaming, and remote work may differ, so create separate proxy groups instead of sending all traffic through one node.

Layer 3: Check routing rules, proxy ports, and TUN mode

After nodes and routes show no obvious problems, inspect the local configuration. The common issue is not that the proxy core is “throttling” traffic, but that traffic is not following the intended policy, an application is bypassing the system proxy, multiple proxy programs are overriding one another, or TUN and security software are processing the same packets.

Check rule matches in the connection log first

Open the client’s Connections or Logs page, visit a slow site, and confirm its domain, matched rule, and final policy. Menu names vary by client. Common paths include Connections → select a request → view Rule and Proxy Chain, or Logs → set the level to Info and send the request again. If the target matches DIRECT, it is not using the proxy. If it matches an automatic proxy group, also check which node the group currently selected.

Clash rules are matched from top to bottom, and the first match takes effect. An overly broad rule placed first can override a more specific rule below it. For example, putting LAN and mainland-China rules before proxy rules is usually sensible, but a custom DOMAIN-SUFFIX in the wrong position can send a target domain through the wrong policy.

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - DOMAIN-KEYWORD,example,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

After changing rules, reload the configuration, close old connections from the Connections page, and test again. Existing TCP connections usually do not migrate automatically when the policy changes. Browser keep-alive connections, HTTP/2, and HTTP/3 can keep the old path alive, so fully quit and reopen the browser if necessary.

Make sure ports are not being forwarded twice

Common local ports include HTTP proxy 7890, SOCKS5 proxy 7891, and the combined mixed-port: 7890. Use the port specified by the active configuration. Browser extensions, download tools, and terminal environment variables should point to the port that is actually listening. Avoid chained proxying where an application points to an old client and that old client forwards traffic to the new one.

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

In the client, look under Settings → Preferences for mixed-port, system proxy, and LAN access options. If the menu path differs, check the active configuration for mixed-port directly. Enable LAN access only when other devices genuinely need to connect, and make sure the operating system firewall rules match the listening address.

Enable TUN mode only when broader traffic interception is needed

The system proxy mainly affects applications that follow the operating system’s proxy settings. Some games, command-line programs, and apps with their own network stack bypass it. TUN mode uses a virtual network interface to capture more traffic and can fix the problem of a browser working while other apps connect directly, but it does not inherently make a node faster. Driver conflicts, incorrect routes, an unsuitable MTU, or duplicate interception can instead reduce throughput.

Turn TUN off and test with only the system proxy enabled. Then turn the system proxy off and retest with only TUN enabled, so the two paths remain distinguishable.
If webpages work after enabling TUN but large files stall, check the MTU. A common test range is 1280 to 1500, but adjust it gradually for the access network instead of copying someone else’s value.
Temporarily exit other VPNs, network accelerators, packet-capture tools, and virtual network adapter software to rule out routing-priority conflicts.
After changing TUN settings, restart the core and confirm that the system routing table and DNS hijacking features are active as indicated by the client.

DNS settings: Fix slow resolution, poisoning, and incorrect routing

DNS usually does not determine sustained large-file transfer speed, but it affects initial page-load time, CDN address selection, and domain-based routing. Typical symptoms include a site taking several seconds to open the first time and loading faster after refresh; a domain being slow through the same node while a known IP works normally; or connection logs showing only an IP with no domain rule match.

Keep system DNS and proxy DNS from conflicting

With the mihomo core, DNS settings may include nameserver, proxy-server-nameserver, fallback, and fake-ip. nameserver handles regular lookups, while the proxy server’s domain must first be resolved by an available resolver. If that step depends on a proxy that has not been established, it can create a resolution loop. When a subscription already provides a complete DNS configuration, validate the original configuration first instead of adding many public resolvers at once.

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  proxy-server-nameserver:
    - 223.5.5.5

This configuration is only a structural example and should not replace every subscription. If the network supports IPv6 but the proxy node or rules do not handle it correctly, an application may prefer an unusable address and wait for a timeout. For comparison, temporarily set ipv6: false. Once the cause is confirmed, decide whether to restore IPv6 based on the actual network instead of relying on a trial-and-error switch indefinitely.

Check exclusions in Fake-IP mode

fake-ip returns reserved addresses for domains and restores the domain during connection handling, improving rule matching. LAN device discovery, printers, some game sign-ins, and apps that require real DNS answers may need to be added to the exclusion list. If only one app starts slowly, check the logs for repeated DNS queries, connection retries, or LAN domains being proxied, then add precise exclusions instead of excluding an entire top-level domain.

Local device and network: Rule out Wi-Fi, browsers, and background tasks

If no node reaches the direct-connection baseline, return to the device layer. In a crowded environment, 2.4 GHz Wi-Fi may provide only a few dozen Mbps of stable throughput; full signal bars do not mean low interference. When possible, compare Ethernet with 5 GHz or 6 GHz Wi-Fi and move the device closer to the router. If Ethernet reaches 460 Mbps while Wi-Fi at the original location reaches only 72 Mbps, changing nodes will not solve the problem.

Use system monitoring to locate the bottleneck

CPU: If the proxy core keeps one CPU core saturated and speed levels off with CPU usage, check device performance and protocol processing first.
Memory: Frequent memory swapping can cause pauses in the browser, download tool, and proxy core.
Disk: When downloading to a mechanical drive, encrypted container, or actively synchronized folder, write speed may become the bottleneck.
Background traffic: Operating system updates, photo backups, and game platforms can saturate the upstream connection, slowing download acknowledgments and webpage responses.
Browser extensions: A proxy extension with its own rules or port can override the system proxy. Use a fresh browser profile for one comparison test.

During speed tests, also disable browser parallel-download experiments and third-party download extensions. Establish a baseline with default settings first. If only one browser is slow while the system download tool and other browsers work normally, the issue is usually an extension, cache, HTTP/3, or browser-level proxy override—not the Clash core.

A ten-minute troubleshooting sequence by symptom

Minute 1: Disable the system proxy and TUN, test direct speed, and confirm the local broadband baseline.
Minute 2: Exit other VPNs, proxy clients, and network acceleration tools, leaving only one Clash client running.
Minute 3: Enable Rule mode, pin a single node, run three consecutive latency tests, and record the variation.
Minute 4: Test single-connection and multi-connection downloads against the same target to separate latency from throughput issues.
Minute 5: Retest with a node from another region and another entry route; do not simply switch to the next numbered node in the same group.
Minute 6: Open the connection log and confirm the target domain’s matched rule, proxy group, and actual node.
Minute 7: Check the application’s proxy port and mixed-port, then remove proxy settings left by old clients.
Minute 8: Test the system proxy and TUN separately to see whether only the TUN path is slow.
Minute 9: Check DNS logs, IPv6, and Fake-IP exclusions, paying attention to unusually long waits on the first connection.
Minute 10: Retest over a mobile hotspot or wired network. Use a different access network to distinguish ISP routing from Wi-Fi issues.

Your final record should include at least the test date, time, access network, client core, proxy mode, node, latency, download speed, and matched rule. If performance is stable during the day but drops at night, prioritize the route. If every node is slow, prioritize the local network and configuration. If only one app is slow, check that app’s proxy method, DNS, and connection protocol first. Keeping comparison data in the three-layer order makes the real bottleneck easier to find than repeatedly refreshing subscriptions or switching nodes at random.