Clash Slow Connection? Diagnose Nodes, Routes, and Local Settings

1. First, identify whether pages load slowly, downloads crawl, or connections drop

A normal latency reading in Clash and a video that keeps buffering are not contradictory. The latency shown on a node card usually comes from a single test request, reflecting the response time to that test destination at that moment. Sustained download speeds also depend on node load, cross-network routing, destination-side rate limits, and your local Wi-Fi. Before troubleshooting, pin down a symptom you can reproduce.

Establish a repeatable baseline

1. Pause cloud sync, game downloads, and system updates. Keep the device, location, and test file the same.
2. On the client's “Proxies” page, expand the active proxy group and manually select a node for now. This prevents an automatic group from switching exits during testing.
3. Test the same destination three times in a row. Record the start time, time to first screen, and sustained download speed each time. For a large file, observe the download for about 30 seconds and keep data usage in mind.
4. Change only one variable per round, comparing in this order: node → network connection → local settings.

2. Node checks: low latency doesn't mean plenty of bandwidth

Open the client's “Proxies” page, find the group used by the active rules, and select a specific node. In graphical clients such as Clash Verge Rev, common sidebar entries include “Proxies,” “Connections,” and “Logs”; names may differ in other clients, so follow the interface you have. Don't rely on the node card alone: check the “Connections” page to confirm the test request actually used the node you selected.

Use three comparisons to pinpoint node issues

• Try another node in the same region: Keep the destination the same and compare two nodes in the same region. If only one stays slow, the issue is more likely related to that node's load, rate limits, or exit.
• Switch to an exit in another region: If nodes in one region are generally slow but another region works well, investigate the route or the connection from that exit to the destination. This doesn't mean your local client configuration is broken.
• Try a different file or destination: If other sites work normally through the same node but one download source is slow, check for account-level rate limits, CDN routing, or single-connection limits on that site.

Don't run a full batch of speed tests and immediately compare download speeds. Batch testing can briefly increase traffic, and a “latency test” is not the same as a “download speed test” in some clients. Stop testing first, then compare nodes one at a time. Large throughput tests can also use up your allowance if your subscription has a data cap.

Check whether a subscription update changed your selection

Open the “Subscriptions” or “Profiles” page and confirm which Profile is active. Check when it was last updated and whether the update succeeded. Node names or group membership may change after an update, so your previous manual selection may no longer be valid. Recheck the selection on the “Proxies” page, then verify the actual route on “Connections.” Never paste a subscription URL containing an account token into a public website for testing.

3. Route checks: use network changes and time-of-day comparisons to spot congestion

A region in a node's name usually describes its exit location, not the full ingress, cross-network, or relay route. The same exit may perform differently across ISPs. If switching nodes has inconsistent results, compare network connections next rather than immediately rewriting DNS settings.

1. Rule out Wi-Fi first: Keep the node unchanged, move your computer closer to the router, and use Ethernet if possible. Check whether the same destination improves. This helps distinguish a weak signal or wireless interference from proxy route congestion.
2. Then compare with a phone hotspot: Connect the same computer to a hotspot, keeping the node and destination unchanged. If it is noticeably faster, the issue is more likely with your broadband route, router, or original network connection. Hotspot testing uses mobile data.
3. Compare peak and off-peak times: For example, run the same tests at 10:00, 20:30, and 23:30. A general slowdown only in the evening is consistent with increased load on a shared route, but the timing alone can't identify exactly where congestion occurs.

A regular ping usually sends ICMP packets and won't automatically go through a proxy node just because the system HTTP proxy is enabled. Its results therefore don't directly represent proxy download speed. Traceroutes may also encounter devices that don't respond; a timeout at one hop alone doesn't prove packet loss there. A more useful comparison is to test the same destination at the application layer on the same device across different networks.

4. DNS checks: confirm the resolution path before changing settings

DNS issues often show up as slow first loads, failures on some domains, or resolution to an unsuitable CDN address. They generally don't explain consistently low throughput once a connection is established. If a download is already running continuously but remains slow, prioritize the node and route comparisons first.

Check three DNS settings that may operate independently

• System DNS: This affects lookups the client doesn't intercept. On Windows, run ipconfig /all in a terminal to see the DNS servers for the active network adapter.
• Core DNS: Check the DNS section in the active configuration for dns.enable, enhanced-mode, and upstream addresses. Clients using mihomo may generate the final configuration through overrides, so inspect the running configuration—not just the original subscription file.
• Browser Secure DNS: A browser may use encrypted DNS independently. In Chrome, the usual path is “Settings” → “Privacy and security” → “Security” → “Use secure DNS.” Note the current setting, temporarily turn it off for comparison, then restore it if needed.

If fake-ip is enabled, an app receiving a synthetic address is normal for this mode; don't assume DNS is broken just because the address isn't a public IP. Conversely, a browser using its own resolver, an app caching an old address, or a domain excluded from interception can all make rule matching behave differently than expected.

Back up the configuration before making changes, and adjust only one setting at a time. If your client manages subscriptions, prefer its supported override feature so the next update doesn't overwrite your changes. The route to a DNS upstream must also be reachable; switching carelessly to an address that can only be reached through the current proxy can make troubleshooting harder. Refer to the documentation for your specific core, and don't assume mihomo settings work with every older Clash core.

Clear the cache before comparing again

After changing DNS on Windows, run the command below in Command Prompt, then fully quit and reopen the app you're testing. This clears the system DNS cache; it won't clear all browser caches or increase route bandwidth.

ipconfig /flushdns

5. Rule checks: verify the actual exit and connection mode

Open the client's “Connections” page, revisit the destination, filter new connections by domain, and check the matched rule, proxy group, and final node. Clash rules are typically evaluated from top to bottom. An overly broad rule near the top may send a service that should be direct through a remote exit, or send a service that needs a proxy direct instead.

1. Confirm the current mode is Rule, then note the rule and exit used by the target connection.
2. Temporarily switch to Global, select the same test node in the global proxy group, and revisit the same destination.
3. If Global works but Rule mode doesn't, focus on routing rules and group selection. If both modes are slow, revisit the node, route, and destination.
4. After testing, switch back to Rule to avoid routing local services or services in mainland China through a remote exit long term.

The minimal example below illustrates rule order only: specific domain rules first, followed by a catch-all. PROXY must be a proxy group that exists in your actual configuration; don't replace your entire subscription with this snippet.

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,DIRECT

After switching nodes or rules, existing long-lived connections may continue using the old exit. Pause and restart the download, or close only the target connection on the “Connections” page and check the next one. Closing all connections can interrupt meetings and transfers, so don't make it your default step.

6. Local interception: system proxy, TUN, and app protocols

The system proxy mainly serves apps that honor the system proxy settings; it doesn't automatically cover every program. TUN intercepts traffic through a virtual network interface, with coverage depending on routes, permissions, exclusions, and the core implementation. TUN is not a bandwidth booster: if your browser already uses the system proxy correctly, simply enabling TUN usually won't fix a congested node.

Use an explicit proxy to isolate interception issues

First, look for port settings in the client's “Settings” or running configuration and find mixed-port. The commands below assume the mixed port is 7890; replace it if your actual port is 7897 or another value. Use curl.exe on Windows and curl on macOS or Linux. The example only accesses a public test domain; it doesn't test large-file bandwidth.

curl --proxy http://127.0.0.1:7890 -o /dev/null -sS -w "connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/

On Windows, change curl in the command above to curl.exe, and replace /dev/null with NUL. These times are cumulative from the start of the request. When using a local proxy, time_connect mainly measures the time to connect to the local proxy; it isn't the node's round-trip latency. first_byte also includes processing time on the destination server.

• Explicit proxy works, but the app is slow: Check whether the app uses the system proxy or has its own proxy address, and whether its new requests appear on the “Connections” page.
• Only fails with TUN: Check service mode or administrator permissions, route conflicts, and DNS interception status. Restore the client's relevant defaults first, then compare one setting at a time.
• Only video or real-time apps fail: Some apps use QUIC or other UDP protocols. A successful HTTP proxy test doesn't prove the UDP route works; confirm that both the node and client support and allow the required traffic.

Don't start by randomly changing the MTU, disabling IPv6, or replacing the entire DNS setup. Investigate one of these only when you have reproducible evidence, such as large packets stalling on a specific network or a particular address family consistently failing. If you suspect device performance, check Task Manager or Activity Monitor: does the core process keep saturating a logical CPU core during downloads, or is the router handling a large number of connections at the same time?

7. Keep troubleshooting notes and let the evidence guide your next step

At the end of a troubleshooting round, keep the smallest set of conditions that reproduces the problem instead of saving dozens of speed-test screenshots without context. The details below are enough to narrow down where the issue occurs and describe it clearly to your subscription provider or client maintainer.

• Environment: Operating system, client name, and client and core versions. Copy the actual values from “About” or the startup log.
• Route: Broadband or hotspot, test time, node label, and destination domain. Don't share account information publicly.
• Settings: Rule or Global mode, system proxy or TUN, the rule matched by the destination, and the final exit.
• Results: Wait time and sustained speed for three tests in each group, and whether switching nodes or networks helped.

If you need to submit logs, temporarily increase the log level, reproduce the issue once, then restore your usual level. Before sharing, redact subscription tokens, node passwords, personal IP addresses, and browsing history. For more basics, see the proxy modes, rule routing, and TUN sections in the Clash Configuration Handbook. If you haven't made your first connection yet, follow the setup guide to confirm the configuration is active before comparing speeds.