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

Start with consistent test conditions: distinguish latency, throughput, and time to first load

Check traffic routing first, then compare nodes and routes, and finally adjust local traffic capture and DNS. The milliseconds shown in the Clash dashboard are not download speeds. Node latency usually measures a single request to a specific test address. Results can also vary with connection reuse, the target site, and the test method, so they do not directly indicate how fast large files will transfer.

Turn “slow” into a repeatable observation. For example: “The same video often buffers at 1080p,” “A webpage takes 5 seconds to load the first time but opens quickly on refresh,” or “Downloads start at a normal speed, then keep slowing down.” Each pattern calls for different checks. Avoid changing rules, DNS, and TUN settings all at once.

Keep a repeatable test log

• Record the client version and the actual core name and version. The version shown in the client interface is not the same as the mihomo core version.
• Use one download, one webpage, and one node for every test. Pause cloud sync, system updates, and other speed tests.
• Run each test for 30–60 seconds and repeat it three times. Record the time, network type, node, matched rule, and sustained speed.
• Keep the units straight: 100 Mbps converts to a theoretical 12.5 MB/s. Actual application throughput is lower due to protocol overhead.

Layer 1: Check whether the node can sustain transfers

Open the client's “Proxies” or “Proxy Groups” page and select a specific node. An automatic selection group may switch members during a test, making two results look like they came from the same group when they actually used different egress nodes. Record the final node name; “Auto” alone isn't enough.

Low-latency nodes aren't always faster for downloads

Suppose node A reports 45 ms and node B reports 120 ms. That alone doesn't mean A will deliver a better video experience. A may have bandwidth limits or congested egress, while B may sustain a steadier throughput. These figures illustrate how to compare nodes; they are not results measured by this site.

1. Select node A in the same manually controlled group, visit a fixed target, and record sustained speed across three tests.
2. Switch only to node B. Keep the mode and DNS unchanged, then repeat the same tests.
3. Try another download source. If only one site is slow, consider its CDN, account-level speed limits, or the route between that site and your egress node.
4. Check your subscription's remaining data, expiration date, and device limits. Being able to import a configuration doesn't mean the service still allows it to work.

Don't run high-volume speed tests on every node at once. Concurrent tests compete for local bandwidth and may use up subscription data. Connectivity checks in the node list are useful for quickly ruling out failed nodes; test nodes one at a time to compare throughput and get results you can interpret.

Compare protocols under similar server conditions

Protocol support depends on the core, node configuration, and server. You can compare protocols only when the provider offers the corresponding endpoints; don't arbitrarily change a protocol field in your subscription. For a fair comparison, use the same provider, similar locations, the same target, and the same time window, then test the different endpoints they offer.

If a UDP-based endpoint performs poorly on your current network while a TCP endpoint is stable, that suggests the network paths differ. The original Clash, Clash Meta, and mihomo don't support exactly the same protocols. If you see “unsupported proxy type,” check the core first instead of repeatedly changing the password or node name.

Layer 2: Separate local access issues from route and egress congestion

A node may be available but noticeably slower in the evening, often due to congestion somewhere along the route. The full path includes your device to the router, your local ISP to the node, and the node's egress to the target site. Testing latency to the node server alone doesn't cover the entire path.

Use two comparisons to narrow down the cause

• Switch networks on the same device: Connect your computer to both home broadband and a mobile hotspot, keeping the node and target unchanged. If the hotspot works but broadband doesn't, focus on the broadband route, router, and Wi-Fi.
• Test the same network at different times: Run three tests during off-peak hours and three in the evening. If multiple nodes slow down only during the evening peak, compare providers or access routes.
• Try different targets through the same egress: If one target is slow but others work normally, check the target service's regional routing, egress IP restrictions, and CDN route.
• Switch to a wired connection on the same network: If Ethernet is stable but Wi-Fi fluctuates, address signal strength and channel interference first. Switching nodes won't fix packet loss on the wireless link.

On Windows, run ping -n 20 192.168.1.1. On macOS or Linux, run ping -c 20 192.168.1.1 to check stability to your local gateway. These examples assume the gateway is 192.168.1.1; check your system's network settings for the actual address. If the gateway doesn't respond to ICMP, a timeout alone doesn't prove the network is down.

tracert or traceroute can offer clues about the route, but traffic from a standard command may not use the application proxy or the same transport as a video stream. Routers along the way may limit ICMP replies, so one hop failing to respond while later hops do is not proof that it is dropping application traffic.

Layer 3: Check rule matches and application traffic capture

Open the client's “Connections” page (sometimes called “Active Connections”), clear any filters, and reload the target webpage. Check the target domain or IP, matched rule, policy chain, and final outbound. Rules are evaluated in order; in a standard rule list, an earlier match can prevent later rules from taking effect.

Run a brief comparison between Rule mode and Global mode

1. On the “Proxies” page, note which node the current policy group selects.
2. Record the actual outbound used by the target connection in Rule mode. Confirm that it didn't unexpectedly match DIRECT or select a slow node from another group.
3. Temporarily switch to Global mode and select the same node in the global policy.
4. Close the target app's existing connections and make a new request. Existing connections may not switch to the new route immediately when you change modes.
5. Switch back to Rule mode after testing. If Global mode works but Rule mode doesn't, check the rules and policy selection first.

Global mode doesn't automatically capture all traffic on the device. It determines which outbound to use after traffic enters the core; whether an app enters the core depends on the system proxy, the app's own proxy settings, or TUN capture. If a browser works but a game or command-line tool doesn't, check how its traffic enters before assuming the node has failed.

Use an explicit proxy to rule out differences in system proxy settings

The example below uses a local HTTP or mixed proxy port, 7890, to request a small webpage. Check the port your client actually uses; don't use this command unchanged with a SOCKS-only port. In Windows PowerShell, use curl.exe to avoid environments that interpret curl as a different command. On macOS and Linux, use curl.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 --output /dev/null --silent --show-error --write-out "connect=%{time_connect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/

On Windows, change the command prefix to curl.exe and replace /dev/null with NUL. The example URL is for checking whether a request completes, not for measuring bandwidth. With an explicit proxy, time_connect mainly measures the time to connect to the local proxy. Time to first byte also includes establishing the proxy tunnel, the remote connection, and the server response; it should not be called “node latency.”

DNS troubleshooting: Slow first visits and inconsistent resolution paths

If a webpage is slow to open the first time but loads much faster on refresh, DNS is one thing to check, though TLS setup and webpage caching can cause similar symptoms. Temporarily set the log level to debug on the “Logs” page, reproduce the issue once, then look for resolution failures, timeouts, or repeated requests for the target domain. Restore the previous log level afterward to avoid excessive logs complicating troubleshooting.

Distinguish system DNS resolution from core DNS resolution

The result of running nslookup example.com on your system doesn't necessarily match the result used inside mihomo. Your browser may use secure DNS, the core may enable fake-ip, and TUN may be configured to intercept DNS. First identify which component is resolving the request, then decide where to make changes.

• Using fake-ip: The common 198.18.0.0/16 range is used for mapped addresses. Seeing an address in this range doesn't mean DNS is broken; check that the mapping and connection work as expected.
• Using DoH: The resolver's own address must be resolvable, and its connection path must be reachable. Don't make resolution of the proxy node's hostname depend on a proxy connection that hasn't been established yet.
• Using IPv6: Check system IPv6 connectivity, the target's AAAA records, and traffic capture settings. Temporarily disable IPv6 at one layer only as part of a controlled comparison, and restore it afterward.
• Editing subscription configuration: Prefer the client's supported override or extension mechanism. Direct edits to generated subscription files may be overwritten the next time the subscription updates.

Don't copy an entire DNS configuration all at once. Check whether fields such as nameserver and proxy-server-nameserver are supported by your core and version. After changing resolvers, establish a new connection to the target; reloading the page may not clear every system, browser, and core cache.

TUN and local performance: Adjust settings only if the captured traffic path is the problem

TUN captures traffic through a virtual network interface and can handle apps that ignore system proxy settings, but it isn't a speed boost. If an explicit proxy works and all apps slow down with TUN enabled, focus on routing, DNS capture, and interactions with other networking software.

Check these four items in order

1. Permissions and services: Confirm that the client has the required service mode or administrator permissions. Check the logs for failures creating an interface or adding routes.
2. Duplicate traffic capture: Temporarily quit other VPNs or proxy clients and test with just one traffic capture method enabled. Don't leave the system firewall disabled.
3. Process usage: Check the client and core processes in Windows Task Manager or macOS Activity Monitor. If a process stays maxed out during transfers, compare the log level, rule count, and core version.
4. MTU and UDP: If small webpages load but large transfers stall, or only apps using QUIC have problems, check the path MTU, UDP forwarding, and related logs. Don't treat one fixed MTU value as the right answer for every network.

If your browser supports it, temporarily disable QUIC, then fully quit and restart the browser to see whether the TCP path improves. If it does, that only means the UDP path warrants further investigation; it doesn't prove that one protocol is always faster. Restore the original setting after testing so a temporary diagnostic change doesn't become a permanent configuration.

Wrap up: Follow the evidence, and don't stack changes

When reporting an issue, include the client and core versions, operating system, network type, time of occurrence, steps to reproduce, and redacted logs. Remove subscription URLs, access tokens, node passwords, and management API keys before sharing. Don't publish your entire configuration.

For client recommendations, see the client guide. For basic system proxy and TUN setup, see the setup guide. The goal is to find a difference you can reproduce: which node, network segment, rule, or traffic capture method causes the slowdown. Once you identify the cause, keep only the necessary changes and retest with the original targets.