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

Keep test conditions consistent: record latency, time to first byte, and download speed separately

The latency shown in the Clash dashboard is not bandwidth. A URL latency test measures how long it takes to get a response from a specific test address through a given node; the exact timing depends on the client and core implementation. It does not indicate how fast large files will download or how every website will perform. If a node reports 80 ms but video keeps buffering, check connection setup, time to first byte, and sustained transfer separately instead of sorting by latency alone.

This guide applies to clients using Clash or the mihomo core. Clash Meta is the former name of mihomo. Supported protocols, DNS fields, and TUN options vary between core versions. Before you start, note your client and core versions and back up your current configuration. Keep the subscription, test addresses, and client version unchanged while troubleshooting; don't update the core, change DNS, and switch nodes all at once.

Create a reproducible test log

• Keep the environment constant: Use the same device, network, and download URL. Pause cloud sync, system updates, and other bandwidth-intensive tasks.
• Keep the routing strategy constant: Select one node in the proxy group actually handling the traffic. Avoid automatic testing or load-balancing groups that may switch nodes mid-test.
• Keep the number of tests constant: Run each test three times in a row and record the median. Observe sustained downloads for at least 30 seconds. Tests may use a significant amount of data.
• Track the same metrics: Record the test time, target domain, rule, proxy chain, latency, download speed, and any interruptions.

The figures are examples showing how to log and interpret results; they are not measurements from this site. Watch the units: 8 MB/s is about 64 Mbps, before protocol overhead. A broadband plan rated at 100 Mbps does not mean a download manager will show 100 MB/s.

Layer 1: Node quality — distinguish node-specific issues from limits at the destination

Test the same destination using two or three nodes from the same subscription. A location in a node's name doesn't necessarily indicate its entry point or guarantee that its exit route matches the label. When choosing a backup, compare nodes with different entry points or routes, not just different names that may share the same entry point.

A timed-out latency test doesn't mean the node is unusable

An unreachable test address, a rejected request, or a failed TLS handshake can all cause a timeout. Check the test URL first, then try the actual site in a browser. Conversely, a quick response from a speed-test address only confirms that this particular request succeeded; it doesn't prove that video segments, download domains, and login endpoints are working properly.

1. Select a node manually on the client's “Proxies” page, then check the “Connections” page to confirm that new requests are actually using it. Page names vary by client version.
2. Test the same HTTPS file URL three times, then try a second, unrelated site. If only one site is slow, suspect site throttling, its CDN, or peering from the node's exit network first.
3. Record results during peak and off-peak hours. If the same node slows down consistently only in the evening, node capacity or congestion on a shared link is more likely than a local configuration issue.
4. Re-establish the test connection after switching nodes. Existing HTTP/2, HTTP/3, or download connections may keep using the previous route; if needed, close only the test connection.

Use an explicit proxy request to rule out browser issues

The Windows PowerShell command below accesses an example site through a local HTTP proxy and measures time to first byte and total time. 7890 is an example port. Before running the command, replace it with the HTTP or mixed listening port shown by your client; it is not a default shared by all clients. This small-page request checks the connection process, not peak bandwidth.

curl.exe --proxy http://127.0.0.1:7890 --output NUL --silent --show-error --connect-timeout 10 --max-time 30 --write-out "connect=%{time_connect}s tls=%{time_appconnect}s first=%{time_starttransfer}s total=%{time_total}s bytes_per_second=%{speed_download}\n" https://example.com/

Here, time_connect mainly measures the connection to the local proxy; it is not the latency to the remote node. When accessing HTTPS through an HTTP proxy, later timings also include stages such as setting up the proxy tunnel and the target's TLS handshake. On macOS and Linux, you can use curl and replace NUL with /dev/null. If the command works but the browser is sluggish, check browser extensions, cache, and Secure DNS instead of immediately changing your subscription.

Layer 2: Network routes — verify rules first, then compare network entry points

Selecting a node doesn't mean every app will use it. In rule mode, connections are matched against rules before being sent to the relevant policy or proxy group. Choosing a node in the main selector won't make the test comparable if the target request actually matches a different group. In particular, download domains, video segment domains, and the main page domain may each match different rules.

Check these three fields in the connection log

• Target: Make sure the domain, destination IP, and app process match the test you're running; don't mistake a background update request for your test.
• Rule: Check the matched rule type and value, such as DOMAIN-SUFFIX, GEOIP, or the final MATCH rule.
• Proxy chain: Confirm that the request uses the intended node, not DIRECT, another policy group, or a different node just selected by an automatic group.

You can briefly switch to Global mode and manually select the same node in the global group for comparison. If performance improves markedly in Global mode but remains slow in Rule mode, check group selection and rule order first. Global mode only changes routing decisions for traffic that reaches the core; it doesn't automatically capture apps that don't use the system proxy, and it isn't a substitute for TUN. Switch back to Rule mode after testing to restore your usual routing.

Compare home broadband with a mobile hotspot

Keep the node and test destination unchanged while switching your computer from home broadband to a mobile hotspot. If the hotspot is stable but home broadband is slow, look at the local Wi-Fi link, router, access network, or route from your ISP to the node's entry point. Then replace Wi-Fi with Ethernet. If Ethernet restores performance but Wi-Fi remains slow, focus on wireless interference and signal strength rather than changing proxy rules.

On Windows, run ipconfig to find your current default gateway, then run ping -n 30 192.168.1.1. This address is only an example; replace it with your actual gateway. If the local gateway shows noticeable packet loss or repeated jitter of tens of milliseconds, stop adjusting the proxy for now. However, some routers give ICMP replies a lower priority, so don't diagnose a faulty link from a single ping test.

Layer 3: Local settings — check the system proxy, TUN, and ports

The system proxy relies on apps using the operating system's proxy settings. Some command-line tools, games, and apps with their own network stacks don't follow those settings. TUN uses a virtual network interface and routing to capture matching IP traffic, but can still be affected by route exclusions, permissions, and other VPNs. Supported clients may allow both to run at once. If something goes wrong, disable them one at a time to isolate the cause rather than assuming they always conflict.

Test traffic capture methods one variable at a time

1. Test the explicit proxy first: Use the curl command above to connect directly to the local proxy port, ruling out whether the system proxy toggle is working.
2. Then test the system proxy: Temporarily disable TUN, enable the system proxy, and use a proxy-aware browser to visit the same destination. In Windows 11, check the manual proxy address and port under “Settings” → “Network & internet” → “Proxy.”
3. Test TUN last: Temporarily disable the system proxy, then enable TUN after installing the required service or granting permissions as directed by your client. Confirm that the test connection appears in the core's connection list before comparing speeds.
4. Isolate other traffic-capture software: Exit other VPNs, proxy clients, and network acceleration tools one at a time. If the device is managed by your organization, check with your administrator before removing drivers or disabling security protections.

Port conflicts and resource usage

If the client log reports that a listener failed to start, first check whether another process is using the port. In Windows, run netstat -ano | findstr :7890 and look for a LISTENING entry whose local address ends in port 7890. Then use the PID to identify the process in Task Manager. Don't terminate a process just because its line matches; it may be another connection or a similar port. If you change the client's listening port, update the system proxy and explicit proxy commands too.

While downloading, watch CPU, memory, and network usage in Task Manager. If one logical processor stays close to 100%, local processing may be limiting throughput; a low average across all CPUs doesn't rule out a single-thread bottleneck. Leaving the log level at debug for extended periods creates more log data; restore the usual level after troubleshooting. Before comparing core versions or TUN network stacks, keep the original configuration and a way to roll back.

DNS and protocol details: troubleshoot slow first loads, slow video, and intermittent stalls separately

DNS issues often make the first visit take a long time, while downloads work normally once connected. Sustained low throughput isn't necessarily related to DNS. Check the connection log for repeated resolution timeouts, and distinguish DNS lookup from connecting to the remote server and completing the TLS handshake. Switching to a different public DNS server doesn't guarantee that requests will use the proxy or take a faster route.

What to check with Fake-IP and nameserver-policy

In mihomo, dns.enhanced-mode: fake-ip maps virtual addresses to help the core recover domain names; it isn't a bandwidth optimization. nameserver-policy assigns resolvers to matching domains. It controls DNS resolution policy, not the proxy rules for application traffic. If your upstream DNS server is specified by domain name, also consider how that hostname is resolved and whether the server is reachable to avoid creating a dependency loop.

• When Secure DNS is enabled in a browser, its requests may take a different route from system DNS. Temporarily turn off Secure DNS in the browser to compare, record the result, then restore the original setting.
• DNS hijacking in TUN only captures DNS traffic covered by its rules. Common port 53 interception does not mean that all in-app DoH requests can be redirected.
• Re-establish test connections after changing DNS. Windows ipconfig /flushdns clears only the system DNS cache; it doesn't clear every cache in your browser, apps, or core.
• Check IPv6 DNS records, system routes, and proxy support together. Changing one setting in the configuration doesn't prove that an app's IPv6 traffic is being captured.

Check UDP, QUIC, and MTU later

Browsers may use HTTP/3 over UDP. If UDP support is incomplete on the current node, protocol, or traffic-capture path, some sites may repeatedly fall back or fail to load properly. Confirm this in the client log and browser network details first. Then temporarily compare using TCP for that browser or destination; don't block UDP globally just to fix one site.

If small pages work but large files, certain HTTPS requests, or TUN mode frequently stall—and you've ruled out the node and rules—investigate path MTU or tunnel encapsulation. Only then consider temporarily changing the TUN MTU from its current value to 1400 for comparison. This is a diagnostic value to try, not a universal best setting. Restore the original value if there's no improvement; don't lower MTU at random as a routine speed tweak. Check the current core documentation for supported fields and behavior, and refer to the protocol guide if needed.

Narrow down the cause: choose the next step based on the symptoms instead of piling on configuration changes

Change one condition at a time. After each test, note what changed, the result, and whether you restored the original setting. Once you've identified the cause, undo temporary Global mode, DNS tests, and experimental MTU changes, keeping only the smallest change that addresses the issue. When asking for help, include the client and core versions, OS version, traffic-capture mode, test time, and redacted error logs. Don't share subscription URLs, node passwords, or controller API keys.

If your old client no longer works well with your system, use the client comparison to check platform and core compatibility, then follow the getting started guide to create a minimal working configuration. Switching clients may resolve some compatibility issues, but it doesn't replace cross-checking nodes, routes, and local settings.