How to Troubleshoot Slow Clash Speeds: Identify Whether the Node, Route, or Local Settings Are at Fault

Start with a baseline: latency, bandwidth, and stability are different metrics

Latency in the Clash panel is usually the time taken by a single HTTP connectivity check. It shows whether a node is reachable and roughly how long it takes to establish a connection, but it does not directly represent download speed. A node with 85 ms latency may deliver only 8 Mbps, while another at 160 ms may consistently reach 90 Mbps. The first responds quickly but has a congested exit; the second is farther away but has ample bandwidth.

Before troubleshooting, keep the test conditions fixed. Do not switch nodes, change DNS, and enable TUN at the same time. If the speed improves after several variables change, you will not know which setting helped. Keep the current configuration and record the test time, node name, proxy mode, download speed, and latency.

Four baseline measurements

1. Direct-connection baseline: Turn off Clash system proxy and TUN, then visit your ISP's speed-test page. If the direct connection reaches only 20 Mbps, the proxy cannot reliably deliver 100 Mbps.
2. Mainland download baseline: Download a mainland mirror file of at least 200 MB and observe the steady speed after 30 seconds to rule out Wi-Fi and local broadband issues.
3. Node latency: Test three to five nodes in the same region three times each. Ignore the first result and record the range from the second and third tests.
4. Proxy throughput: Download the same test file through one node, keeping each test running for at least 60 seconds. Do not mistake the initial burst for sustained speed.

Watch the units when comparing results. Speed-test sites usually use Mbps, while download tools use MB/s—a difference of about eight times. 80 Mbps corresponds to a theoretical download rate of about 10 MB/s; after protocol, TCP, and encryption overhead, an actual 8–9.5 MB/s is usually normal.

Layer 1: determine whether the node itself is slow

Node-level issues occur on the proxy server or at the provider's exit. Typical signs include only a few nodes in the same subscription being slow and recovering immediately after switching to another node in the same region, or one node staying slow all day while others are unaffected.

Do not sort by latency alone

An automatic proxy group typically selects a node based on the response time of a test URL. That works for checking availability, but it cannot measure sustained transfer capacity. Because the test response is tiny, a node with very little bandwidth left may still produce an impressive latency number.

For example, node A records 72, 81, and 76 ms, but downloads steadily at 2.1 MB/s. Node B records 145, 151, and 148 ms, yet sustains 11.4 MB/s. A may feel faster for web browsing, where first-byte response matters; B is better for large downloads or high-bitrate video.

Recognizing an overloaded node

• Speed is normal in the morning but drops below one-third of the daytime rate during the same evening hours.
• Latency repeatedly jumps from around 100 ms to over 500 ms, accompanied by connection resets.
• Only one node remains consistently slow among several nodes in the same region.
• Short web requests still work, but speed keeps falling after a download runs for several dozen seconds.
• Speed returns after switching to another protocol or entry point, while local settings remain unchanged.

The “multiplier” in a node name usually calculates subscription traffic usage; it does not indicate a speed tier. A 0.5× node is not necessarily slow, and a 2× node does not mean double the speed. Evaluate latency, sustained throughput, packet loss, and traffic cost separately.

What to do at the node layer

1. Switch between nodes in the same region first, keeping the proxy mode and test file unchanged.
2. Turn off automatic selection and temporarily pin a single node so the proxy group cannot switch during testing.
3. Update the subscription once to confirm that the provider has not changed the node address, port, or protocol parameters.
4. If only one node is affected, record the test time and sustained speed before reporting it to the node provider.

Layer 2: determine whether the cross-border route or ISP path is congested

The route layer lies between your local broadband connection and the proxy node. The node server may have plenty of capacity, but detours, packet loss, or peak-hour congestion between your ISP and the entry point can still reduce real-world speed. In this case, several nodes in the same data center often perform similarly poorly.

Three clear signs of a route problem

• Time-related: The connection reaches 70 Mbps on a weekday morning but only 10 Mbps from 20:00 to 23:00.
• ISP-related: The same node is slow on home broadband but recovers noticeably when you switch to a mobile hotspot.
• Region-related: An entire group of nodes in one region is slow, while throughput returns after switching to another region.

Standard ping uses ICMP packets, which some servers deprioritize or ignore. Therefore, “100% ping packet loss” does not necessarily mean the proxy is unusable, and “40 ms ping” does not guarantee smooth TCP or UDP transfer. Clash's HTTP latency test is closer to a real proxy connection, but it is still only a small-traffic probe.

Use a comparison test to identify the ISP path

1. Pin one node and one download URL of at least 200 MB, then test for 60 seconds over home broadband.
2. Keep the node unchanged, switch to a 4G or 5G mobile hotspot, and test for another 60 seconds.
3. Repeat the tests in the morning and during peak hours, recording sustained speed rather than the peak.
4. If the hotspot reaches 8 MB/s while home broadband manages only 900 KB/s, the local Clash configuration is usually not the primary suspect.

If nodes in the same region are generally congested, switch regions instead of trying them one by one. Shorter physical distance often means lower latency, but route quality matters more than straight-line distance. Choose based on tests from your current ISP.

Layer 3: check the Clash client and local network settings

When every node slows down at once and changing networks makes little difference, inspect the local layer. Common causes include the system proxy port, proxy mode, TUN, DNS, browser proxy extensions, security software, and virtual network adapters. The rule remains: change one thing at a time.

Check the proxy mode and port first

Using Clash Verge Rev 2.3.x with mihomo 1.19.x as an example, open “Settings” → “Clash Settings” to view the mixed port. 7890 is common, but the configuration may use 7897, 7899, or another port. The port used by the system proxy must match the port listened to by the current core.

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

A port mismatch usually makes everything inaccessible. However, when a browser extension, system proxy, and in-app proxy are enabled together, requests may take a detour, be proxied twice, or run slowly in only some applications. During testing, keep one entry point only: either enable the client's system proxy or explicitly configure the target app to use the HTTP/SOCKS port.

Make sure the rules send test requests to the intended proxy group

Rule mode matches rules from top to bottom and stops at the first match. A speed-test homepage, download domain, and analytics domain may match different policies. If the download domain goes DIRECT while the page itself uses the proxy, the result does not represent node speed.

Open the client's connection log, find the domain currently transferring data, and check its rule and proxy group. The log should show which rule matched and which node was ultimately used. For a pure node test, temporarily switch to Global mode and pin one node; switch back to Rule afterward so everyday traffic does not all use the proxy.

How to isolate slow TUN mode

TUN takes over more system traffic, making it useful for apps that do not read the system proxy and for some games. It also adds virtual-network-adapter, routing, and DNS processing steps. If system proxy mode is normal but speed drops noticeably after enabling TUN, test in this order:

1. Disable TUN, keep the system proxy enabled, and repeat the same download test.
2. Enable TUN again and make sure no other VPN, accelerator, or legacy virtual network adapter is running.
3. In the client's TUN settings, switch between available stacks such as system and mixed, restarting the core after each change.
4. Check the MTU. If the default value causes some sites to stall, test 1500, 1400, and 1280 in sequence and record the changes.
5. If only UDP applications are affected, check separately whether the node protocol supports reliable UDP forwarding.

Do not keep the MTU unusually low based on guesswork. A value that is too high may cause fragmentation or stalls on specific connections, while a value that is too low adds packet-header overhead. Test different values only for symptoms such as “web pages open but large files stop” or “some images never finish loading.”

Slow DNS does not mean slow node bandwidth

DNS problems mainly delay the first page load and domain resolution. If a page reaches full bandwidth once downloading begins, node throughput is usually normal. If every new site takes 3–5 seconds to start but loads quickly afterward, check DNS before switching nodes.

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

This configuration is for troubleshooting only and should not directly overwrite an existing subscription. With fake-ip enabled, LAN devices, corporate intranets, and some apps that require real addresses may need filter rules. Choose DNS upstreams according to the current network; mainland resolution and proxy-side resolution serve different purposes.

Rule out browser and background-program interference

• Disable browser proxy extensions to prevent their ports from stacking with the system proxy.
• Pause cloud-drive sync, system updates, and game updates, then check real-time network usage in Task Manager.
• Temporarily disable HTTP/3 and repeat the test to determine whether the UDP path is abnormal; restore the original setting afterward.
• Use a wired connection or 5 GHz/6 GHz Wi-Fi, and avoid testing on the congested 2.4 GHz band.
• Keep the log level set to info. Running debug for long periods creates large logs and is unsuitable for everyday use.

Follow a fixed troubleshooting flow based on the symptoms

You do not need to change every setting. Choose the shortest path based on the symptoms, then confirm the result with a comparison test.

Scenario 1: low latency but only a few hundred KB/s for downloads

1. Pin the current node and test a sustained download for 60 seconds instead of focusing on the latency number.
2. Switch to another node in the same region. If speed returns, the original node is likely overloaded.
3. If the same region is still slow, switch to another region to determine whether the route is congested.
4. If every region is slow, disable TUN, browser extensions, and background downloads, then test the local layer.

Scenario 2: fast during the day, consistently slow at night

Keep one daytime and one evening data set first. For example, 11:00 may reach 78 Mbps, while 21:30 drops to 14 Mbps and the same node still reaches 55 Mbps through a mobile hotspot. This points more strongly to the home broadband route during peak hours than to a Clash client failure. Consider changing the entry region, route type, or testing outside congested hours.

Scenario 3: fast in the browser but slow in games or download tools

First check whether the app reads the system proxy. Many games and some download tools do not use the HTTP system proxy and require TUN or an in-app SOCKS5 setting. If manual proxy settings are supported, enter 127.0.0.1 and the current SOCKS/mixed port, such as 7890. Then confirm in the connection log that the traffic is actually reaching mihomo.

Scenario 4: mainland websites also become slow after enabling Clash

Check the connection log to confirm that mainland domains match DIRECT. If they were sent to a proxy group by mistake, inspect rule order and the update status of the rule set. Do not hide the problem by routing all traffic directly; find the incorrectly matched rule and confirm that the rule set loaded successfully.

Priority order: start with low-risk actions, then change underlying parameters

Recommended order: update the subscription, pin a node, switch to another node in the same region, switch regions, compare another network, compare with TUN disabled, check rules and ports, and adjust DNS and MTU last. This moves from external variables toward local low-level settings, keeping rollback costs low.

Keep at least 60 seconds of stable data for each test and restart the core after changes. Do not change the configuration file, DNS, TUN stack, and node at the same time, or the conclusion will not be reusable. When finished, restore Rule mode, disable temporary debug logging, and remove unused manual proxy settings.

To understand DIRECT, PROXY, proxy groups, rule matching, and fake-ip, see the glossary and advanced configuration. For a first-time setup, use the Getting Started guide to review your subscription, system proxy, and mode.