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

Keep Test Conditions Consistent: Separate Latency from Throughput

The latency shown next to a Clash node measures the time for a single probe. It does not indicate sustained download speed, nor does it guarantee that streaming services, code repositories, and websites use the same route. If latency is 80 ms but downloads reach only 200 KB/s, first record the actual connection path before changing anything.

The TUN settings discussed here apply to clients running the mihomo kernel. Options can differ between the traditional Clash kernel and individual clients. Before you start, note the client name, client version, kernel version, and active configuration name from the client’s About or Kernel page. This helps prevent copying settings intended for a different kernel.

Establish a Reproducible Baseline

1. Pause cloud sync, system updates, and other large downloads. Use a wired connection where possible; on Wi-Fi, stay in the same location and use the same band.
2. Choose one reliable direct-connection site and one destination that requires a proxy. Use the same file and test duration each time, and don’t switch speed-test servers between runs.
3. Keep rule mode and the proxy group unchanged, and select a node manually. Run each test three times for 30 seconds, then record the median result.
4. Record time to start loading, sustained download speed, any interruptions, and the rule, proxy group, and final node shown in the connection panel.

The table below shows how to record results; it is not a benchmark of any specific service. For a real diagnosis, use results from the same device and test resource.

Layer 1: Verify the Node and Actual Outbound Route

Check the Connection Panel Before Switching Nodes

Find the active download request in the client’s Connections panel. Check the destination domain, matched rule, proxy chain, and outbound node. Changing the node in a proxy group may not change the route for an existing connection. Long-lived browser, video, and download connections may continue using the old one.

After each switch, stop and restart the test. If needed, close only the connection associated with that test; don’t clear all connections during a remote desktop session or meeting. If the panel shows DIRECT, the selected proxy node’s throughput isn’t the issue—check which rule matched first.

• One node is slow: Compare two or three nodes in the same proxy group. If only one remains slow, suspect that node’s load, rate limits, or exit quality.
• An automatic group keeps switching: Temporarily use a manual selection group for testing. url-test selects nodes mainly by probe latency; it isn’t a bandwidth test.
• Only one site is slow: Test a different destination. Site rate limits, CDN routing, and peering between the node’s exit and the destination can all affect speed.

Use Global Mode Only for a Brief Comparison

If you suspect the destination is being sent direct by mistake, briefly switch to Global Mode, explicitly select the GLOBAL outbound, and create a new test connection. If Global Mode works but Rule Mode remains slow, switch back and check the domain rules, rule-set updates, and proxy-group routing. Global Mode won’t increase the node’s bandwidth or guarantee that traffic outside the client is captured.

Don’t rewrite all subscription rules just to run a speed test. First note which rule matched, then use a client-supported local override for the destination domain. Direct edits to a generated subscription file may be overwritten during the next update.

Layer 2: Compare Access Networks and Remote Routes

The region in a node’s name rarely tells you the full route. A connection may pass through an entry server or relay before reaching its destination from a different exit. The client’s connection panel can confirm the selected outbound, but may not show every server-side relay.

Narrow Down the Cause with Cross-Tests

1. Same network, different nodes: Keep the home network fixed and switch only the node. If one group of entry nodes is slow while others work, note what those nodes have in common.
2. Same node, different networks: Keep the node and destination unchanged, then switch from home broadband to a phone hotspot. Pause high-traffic tasks first to limit mobile data use.
3. Same setup, different times: Test once off-peak and again in the evening. A slowdown that occurs only in the evening points more strongly to congestion on the access network, entry route, or relay.

If node A is slow on your home network but fast on a hotspot, while node B works on both, the issue is more likely on the route from your home network to node A. That doesn’t prove node A’s server lacks bandwidth. If all nodes are slow on both networks but direct downloads work, check the client, local proxy chain, or limits on the test destination.

Use Ping, Traceroute, and Download Tests for Different Clues

Pinging or tracing the route to a proxy entry provides only partial network clues. Intermediate routers may limit ICMP replies; packet loss at one hop, without comparable loss at the final destination, usually doesn’t prove that hop is dropping forwarded traffic. A standard traceroute also can’t reveal the server-side relay path inside an encrypted proxy connection.

When reporting a route issue, include the time and time zone, access provider, node name, destination domain, results from three test runs, and results from switching networks. Don’t send only a latency list. Before sharing logs, remove subscription URLs, tokens, node passwords, and personal browsing records.

Layer 3: Isolate System Proxy, TUN, and Local Conflicts

Check the Local Listening Port First

A system proxy typically forwards traffic from apps that honor system settings to a local HTTP proxy. TUN captures traffic through a virtual network interface and routing. They can work together in some configurations, but test them separately while troubleshooting so you don’t change both the entry point and routing at once. The example below assumes the active configuration includes mixed-port: 7890; 7890 is not a universal client port.

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

In Windows PowerShell, run the commands below to confirm that a port is listening, then explicitly send a request through the proxy. This checks the route and response time; it does not measure large-file bandwidth.

Get-NetTCPConnection -LocalPort 7890 -State Listen

curl.exe --proxy http://127.0.0.1:7890 --output NUL --silent --show-error --write-out "connect=%{time_connect} start=%{time_starttransfer} total=%{time_total}\n" https://example.com/

Make sure the port in the command matches the client’s actual port. time_connect mainly measures the time to connect to the local proxy, not the node’s round-trip latency. time_starttransfer also includes later stages such as proxy negotiation, TLS, and the server response. Compare changes for the same request rather than attributing a single field to DNS.

A/B Test System Proxy and TUN Separately

1. Turn off TUN and enable only the system proxy. Test with a browser that explicitly supports HTTP proxies or use the command above.
2. Record the result, then turn off the system proxy and enable TUN. Reconnect to the same destination and confirm that the request appears in the connection panel.
3. If only TUN is slow, check for other VPNs, accelerators, or virtual network adapter tools running at the same time. Pause them one at a time and retest; don’t disable multiple security features at once.
4. If TUN won’t start, first resolve service permissions, virtual network adapter, or route-creation errors. Failure to start and low throughput are separate issues.

mihomo offers the TUN stacks system, gvisor, and mixed; availability and behavior depend on the platform and kernel version. mixed typically combines system TCP with gVisor UDP. There’s no stack that’s fastest on every device. Change one option at a time, restart the relevant kernel, and retest with the same task.

DNS and UDP: Distinguish Slow Page Loads, Downloads, and Video

For Slow First Loads, Check Name Resolution First

If the first visit stalls for a few seconds but a refresh works immediately and downloads run at normal speed, check for DNS timeouts and delays while establishing the connection. Look for repeated DNS timeouts in the logs and check whether different resolvers return substantially different CDN addresses for the destination domain. Browser caching and connection reuse can also make the second visit faster, so that alone doesn’t prove a DNS issue.

enhanced-mode: fake-ip maps domains to virtual addresses to help identify traffic; it doesn’t increase node bandwidth. nameserver-policy selects a resolver for specified domains; it isn’t an outbound proxy group. When changing either setting, also check that the resolver is reachable, that its returned address works with the current exit, and how DNS requests are routed.

• A browser’s Secure DNS may use its own DoH connection and bypass system DNS. Note its status during diagnosis; if needed, disable it briefly for comparison, then turn it back on.
• TUN’s dns-hijack is commonly used to intercept traditional port 53 requests; it doesn’t mean all DoH and DoT traffic is captured.
• After switching between fake-IP and real-IP resolution, clear the relevant DNS cache using a method supported by your client and create a new test connection so cached addresses don’t skew the result.

For Video Stuttering, Check UDP and QUIC

If web downloads work but video, voice, or games don’t, check UDP separately. Browsers may use QUIC, which runs over UDP, and both the node and server need to support the relevant forwarding path. Check the connection panel for UDP requests, then briefly disable QUIC using a client- or browser-supported method and compare what happens when traffic falls back to TCP.

If performance improves after the fallback, that only means the UDP path needs further investigation; it doesn’t mean all UDP should be blocked permanently. Likewise, disabling IPv6 isn’t a universal speed fix. First check whether AAAA resolution, the IPv6 default route, and proxy capture are consistent, then consider temporarily restricting the address family for testing.

Draw Evidence-Based Conclusions and Keep Changes Reversible

After comparing all three layers, narrow the issue down as far as the evidence allows. Use the patterns below to choose what to check next; they don’t replace further diagnosis on the server or network side.

Keep the original configuration or export a backup. Record each changed setting, when you changed it, and the result. If an update introduced the issue, restore the affected setting and test before considering a client or kernel update. When finished, restore your usual rule mode, required security settings, and log level so temporary test settings aren’t left running.