How to Fix Slow Clash Connections: Check Nodes, Routes, and Local Settings

The Clash node list shows 80 ms, but videos still buffer. Switch to a 180 ms node, and downloads get faster. There’s no contradiction: latency checks, sustained transfers, and app load times measure different things. First pinpoint where the slowdown occurs, then check the node, route, and local setup in turn. This is usually more effective than changing DNS, rules, and TUN settings all at once.

1. Tell high latency, low throughput, and slow page loads apart

In Clash clients, “latency” usually comes from a request to a test URL through a node. It is not the same as an ICMP ping and does not directly indicate available bandwidth. The test URL, timeout, and connection reuse can all affect the result. Switching from one test site to another may change the number without improving how a particular video service performs.

Set up a repeatable speed test

1. Pause cloud sync, game updates, and large downloads on other devices. Plug in your laptop and use a stable Wi-Fi or wired connection.
2. Use the same device, download source, and connection method each time. Choose a test file large enough for a sustained transfer, and run it for at least 30 seconds.
3. Run each test three times and record the median. Don’t rely on a brief cache-driven speed spike at the start, and don’t test a dozen nodes at once.
4. Record direct and proxied results separately. If the destination is unreachable directly, use a reachable comparison site instead; don’t treat a failed connection as zero bandwidth.

Watch the units: 100 Mbps has a theoretical maximum transfer rate of about 12.5 MB/s, before protocol overhead. A download speed of 10 MB/s doesn’t mean a 100 Mbps connection is running at one-tenth speed. Browser downloads using multiple connections can also differ substantially from single-connection downloads, so record them separately.

2. First layer: Check node quality and the active policy

On the client’s Connections page, find the domain you’re testing and check its matched rule, policy group, and final node. In Rule mode, switching a proxy group in the UI may not affect the current request. Nested policy groups may also point to another automatic selection group. Existing connections usually won’t reconnect immediately when you change a selection. Stop the download and start a new request before testing; if needed, close only the relevant existing connection.

Compare three nodes; don’t just pick the one with the lowest latency

• Different nodes in the same region: Check whether a single node is congested. If possible, choose nodes with different entry points or route identifiers.
• Nodes in different regions: Check whether the destination service has issues with a particular egress region or carrier peering route.
• Same node, different times: Test once during the day and again in the evening. A clear evening slowdown points more toward capacity or peering congestion; don’t start by changing your local MTU.

For example, node A might show 65 ms and sustain 1.2 MB/s, while node B shows 145 ms and sustains 8.0 MB/s. This only indicates that B worked better for that large-file transfer; it doesn’t mean B is better for every game or website. Save the test URL, time, and node together so you don’t compare results from different conditions.

Updating a subscription refreshes configuration and node information; it won’t increase route capacity. First check that the subscription hasn’t expired, your traffic allowance isn’t exhausted, and the service hasn’t reported throttling. Then update it once manually. If the update fails, keep the configuration that still works and check the error instead of repeatedly deleting and recreating the subscription.

3. Second layer: Check the access network, outbound route, and destination separately

A proxied connection involves at least two route segments: from your device to the node’s entry point, and from the node to the destination. Switching nodes changes several variables at once, so “it got faster after I switched” doesn’t confirm the root cause. For a useful comparison, keep the node the same, switch your computer from home broadband to a mobile hotspot, and repeat the same task.

For packet-loss tests, focus on the destination, not just intermediate hops

On Windows, use the command below to check basic connectivity to a public IP address. This is only a probe target, not a DNS server to add to your configuration, and it doesn’t represent the node’s route. With TUN enabled, whether the probe passes through the core depends on routing and ICMP support. To establish a direct-connection baseline, pause TUN first and confirm that the system routes have been restored.

ping -n 30 1.1.1.1
tracert -d 1.1.1.1

Intermediate routers may limit ICMP replies. A timeout at one hop doesn’t prove packet loss if the destination responds. And no reply from the destination doesn’t necessarily mean a website is unavailable. If your upload is saturated, download acknowledgments and web requests can get queued; pause upload tasks and test again. This usually doesn’t require changing the proxy protocol.

4. Third layer: Check for conflicts with system proxy, TUN, and app settings

System proxy and TUN are different ways of routing traffic. System proxy mainly serves apps that follow the system proxy settings; TUN uses a virtual network interface to capture traffic that matches its routes. Having both enabled doesn’t always cause a conflict, but during troubleshooting, using one at a time makes it easier to see where traffic is going.

Test with system proxy only first

1. Quit other VPN and proxy tools, turn off TUN in the current client, and leave system proxy enabled.
2. On Windows 11, go to Settings → Network & internet → Proxy and check that the manual proxy or setup script matches your intended settings. On macOS, go to System Settings → Network → your current network → Details → Proxies and check for addresses left behind by other tools.
3. Confirm which port the client is listening on. The example below uses the local HTTP or mixed port 7890. This is a common example, not a fixed default for every client.
4. Compare an explicit proxy request with the browser result. In Windows PowerShell, use curl.exe to avoid differences in how older environments handle the curl alias.

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} start=%{time_starttransfer} total=%{time_total}\n" https://www.example.com/

This quick check shows whether a request completes and whether the wait for the first byte is unusually long; it does not measure maximum download bandwidth. With an HTTP proxy, time_connect mainly reflects establishing a connection to the local proxy, not latency to the remote node. time_starttransfer also includes subsequent negotiation and server wait time. On macOS or Linux, use curl and replace NUL with /dev/null.

Test TUN separately

Turn off system proxy and enable TUN, keeping the same node and destination, then start a new connection. If only TUN is slow, check client permissions, the virtual interface, routing, and remnants of other VPNs. If explicit proxy requests are fast but the browser is slow, check browser proxy extensions, Secure DNS, and cache before considering a new node subscription.

Games, voice calls, and some video connections may use UDP. A successful HTTP proxy test only confirms that the corresponding TCP request works; it doesn’t prove the UDP route is working. Check that the app is being captured, the node protocol supports the required forwarding, and the server allows UDP. Then confirm the actual traffic in the connection log. Disabling all UDP is not a general-purpose way to improve speed.

5. DNS and MTU: Change them only when symptoms point there

For slow first loads, check the DNS resolution path

If a page is slow to open the first time but loads normally after a refresh, check the logs for repeated DNS timeouts and confirm that the upstream DNS server is reachable. With mihomo in fake-ip mode, returning a virtual IP can be normal. Don’t assume DNS is broken just because you see an address in the 198.18.0.0/16 range. Browser Secure DNS, OS resolution, and core DNS may follow different paths; consider how traffic is actually being captured.

• Keep a known-working DNS configuration as your baseline. Don’t add a large number of unfamiliar upstream servers at once.
• Check that routing rules aren’t creating a DNS loop, especially for proxy connections that need a domain resolved before they can connect.
• After changing DNS or fake-ip settings, reload as required by the client and close existing connections before retesting. On Windows, ipconfig /flushdns clears the system DNS cache, but not every app or core cache.

Check MTU only if large transfers stall or the issue occurs only in TUN

MTU is the largest packet size a link can carry. Encapsulation overhead or blocked path MTU discovery can cause small requests to work while large transfers or some TLS connections stall. But 1500, 1480, and 1400 aren’t universal settings, and lowering MTU won’t automatically increase node bandwidth.

On Windows, use Command Prompt to test IPv4 packets with fragmentation disabled. With an Ethernet MTU of 1500, 1472 bytes of ICMP data plus the usual 28-byte IPv4 and ICMP headers add up to 1500 bytes. If that fails, try 1400 bytes of data for comparison:

ping -4 -f -l 1472 -n 4 1.1.1.1
ping -4 -f -l 1400 -n 4 1.1.1.1
netsh interface ipv4 show subinterfaces

The destination may block ICMP, and these two ping tests may not cover the actual proxy tunnel route, so treat the results as clues only. If there’s a confirmed TUN-related issue with large packets, note the current TUN MTU and temporarily set it to 1400 only in the current client or mihomo TUN configuration. Restart the relevant connections and test again; restore the original value if there’s no improvement. Don’t change every physical network adapter, and don’t apply this IPv4 test formula to IPv6.

6. Record your results and avoid repeated guesswork

After comparing all three layers, you can usually narrow the problem down to one area. When contacting your service provider or client maintainer, include repeatable steps rather than just saying “it’s very slow.” This checklist is enough to create a useful report:

• Environment: OS and client versions, core name and version, whether TUN is enabled, and the actual listening port.
• Test conditions: Date and time, home broadband or mobile hotspot, destination service, and single- or multi-connection download.
• Comparison results: Median of three sustained speed tests on the same node, results before and after switching nodes, and time to first byte.
• Traffic path: Matched rule, final policy node, and relevant log lines around failed requests. Remove credentials.

If your current client or core is no longer maintained, back up your subscription and custom rules before switching to a maintained client for your platform. After migrating, start with a minimal configuration and confirm the connection works before adding overrides, rules, and TUN settings one by one. This helps prevent old conflicts from carrying over. For basic setup, see the Clash Setup Guide. For connection failures and speed-test timeouts, see Common latency check issues.