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

Before You Start: Tell Slow Page Loads, Slow Downloads, and Disconnects Apart

“Slow Clash speeds” can mean three different things: pages take a long time to load initially, downloads stay slow, or video playback keeps buffering. These point to different issues: DNS resolution or connection setup, sustained throughput, and connection stability. Describe the symptom before changing settings to avoid unnecessary tweaks.

• Slow to load at first, then normal: Check DNS, connection setup, and the destination server’s response before assuming the node lacks bandwidth.
• Large downloads stay slow: Compare nodes and ISP routes, and check whether the server limits speed per connection.
• Speed fluctuates or reconnects are frequent: Check Wi-Fi, packet loss, node load, and background network switching.
• Only one app is slow: Check whether it is using the proxy and which rule it actually matches.

Keep Test Conditions Consistent

Pause cloud sync, system updates, and other downloads. Use the same destination, device, and test duration, changing only one variable at a time. Run each test three times and observe for about 30 seconds each. If you’re on a metered plan, make sure the test won’t use more data than you’re comfortable with.

Note the client name, core type, proxy mode, and whether System Proxy and TUN are enabled. Clash is a common name in the client ecosystem; mihomo is the core that continued development from the original Clash.Meta. Settings and menu names vary across clients and cores.

Layer 1: Node Quality — Check Sustained Transfers Before Latency

Latency tests on a client’s Proxies page usually probe node availability and request time using a specified URL. Results depend on the test address, connection reuse, and client implementation; they do not rank node speeds for every website. A node showing 60 ms may download more slowly than one showing 180 ms.

Compare Two Nodes

1. Open the client’s Proxies page and find the group actually used for the destination site. If it contains nested groups, expand them until you identify the final node.
2. Select node A, establish a new connection to the destination, and record the initial response time, steady download speed, and any pauses.
3. Switch to node B and establish a new connection under the same conditions. Existing connections may continue using the old route, so don’t just switch nodes and watch the original download.
4. Test node A again to rule out a temporary fluctuation at the destination server.

For example, node A has a probe latency of 70 ms but downloads steadily at only 1.2 MB/s, while node B has a latency of 160 ms and sustains 7 MB/s. For large downloads, B is the better choice; for interactive requests, compare actual response times and jitter. A node’s region and tier in its name can help with selection, but don’t prove its physical route or available bandwidth.

What the Node Check Can Tell You

• Only one node is slow on the same network at the same time: suspect that node’s load, ingress, egress, or route first.
• Several nodes are slow for the same site, but other sites work normally: check the destination service, egress region, and rules instead of immediately reinstalling the client.
• Speed changed after updating the subscription: check whether the nodes were replaced or a different node was selected in the group. Updating a subscription does not increase bandwidth.

Layer 2: ISP Routing — Compare Networks and Times of Day

Traffic between a node and your device passes through your local connection, ISP network, and the node’s ingress. The same node name does not mean your home broadband and mobile data use the same route. Evening congestion, inter-ISP peering, and changes to intermediate routes can all reduce speed.

Narrow It Down in This Order

1. Check your local wireless connection first: Move closer to the router or retest over Ethernet. 5 GHz Wi-Fi is generally better for high-speed transfers when the signal is strong, but it may not cover rooms through walls as well as 2.4 GHz.
2. Try another access network: Keep the same computer and node, but connect through a phone hotspot. Watch your mobile data usage and pause background updates on the computer.
3. Compare times of day last: Run the same test during the day and in the evening. Don’t compare results from different dates or nodes directly.

Suppose the same node manages only 0.8 MB/s over home broadband but reaches 6 MB/s through a phone hotspot. That makes the access network or route a good place to investigate, but it doesn’t prove that an ISP is deliberately throttling traffic. A hotspot changes the access method, egress, and routing, so further comparisons are needed.

You can use system ping or a route-tracing tool to inspect basic network connectivity, but their ICMP traffic may not use the HTTP system proxy. The node’s ingress may also ignore ICMP. A single timeout or high latency at an intermediate hop does not by itself prove packet loss on the proxy route. Check the destination’s behavior alongside real application traffic.

Layer 3: Rule Matching — Check Which Egress a Slow Connection Uses

In Clash rule mode, connections are matched in order, and the first matching rule usually determines the policy. Having nodes in your subscription does not mean every app uses one. A destination may match DIRECT or use a policy group different from the one you selected manually.

Trace the Actual Route in Connection Logs

1. Open the client’s Connections page and make the request again. For a persistent connection, close the relevant page or pause the task before retrying.
2. Filter by domain, destination IP, or process, then check the matched rule, policy chain, and final node. Some clients require you to expand connection details to see everything.
3. Check resource domains in addition to the website’s main domain. If the page loads but images or video are slow, those resources may be matching a different rule.
4. If nothing appears on the Connections page, first check whether the app uses the system proxy or is captured by TUN. A missing record can also be caused by a connection ending too quickly or by a UI filter.

Once you’ve confirmed the destination is reaching the client, briefly switch to Global mode, explicitly select a node, and test with a new connection. If the same resource improves noticeably, focus on the original rule, policy group, and egress differences. Global mode will not automatically capture apps that bypass the client, and a single successful test does not prove the rules file is damaged.

Use an Explicit Proxy to Rule Out System Proxy Differences

The Windows PowerShell command below assumes the client’s actual HTTP or mixed proxy port is 7890. Check the port in the client settings first; if it is actually 7897, update the command. This request measures timing phases, not maximum download speed.

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

Here, time_connect mainly reflects the connection to the local proxy, not latency to the remote website. TLS, time to first byte, and total time are all measured from the start of the request, so they should not be added together. If the command succeeds but the browser is slow, check browser extensions, per-app proxy settings, and differences in request protocols.

Layer 4: DNS Resolution — Separate Lookup Delays from Transfer Bottlenecks

DNS more often affects first visits, domain-based routing, and destination address selection than the speed of an established download. If a file has been transferring steadily for minutes but remains slow, changing DNS alone is unlikely to fix the bandwidth problem.

First, Find Out Which Component Handles DNS

Check the config’s dns section, TUN DNS hijacking settings, and whether the browser has Secure DNS enabled. System DNS, browser DoH, and core DNS may follow different routes. Enabling the system proxy does not mean all system DNS queries go through Clash.

• Fake-IP mode: Typically returns a mapped address for a domain, which the core then associates with the original domain when handling the connection. Common configs use 198.18.0.0/16; check the actual fake-ip-range value.
• Redir-Host mode: Returns the resolved address. How that result is associated with the domain and matched against rules also depends on the core and traffic capture method.
• Custom upstream DNS: Check that the upstream is reachable and that DNS requests aren’t creating a dependency loop. Don’t choose a public DNS server just because it’s well known.

On Windows, run Resolve-DnsName example.com to see results through the system DNS path, but this won’t show the result from a browser’s own DoH. With Fake-IP enabled, seeing a mapped address in the configured range is not a resolution failure. Don’t treat that address as the destination server when evaluating route latency.

How to Verify a DNS Change

1. Back up the current DNS config and change one thing at a time, such as replacing an unreachable upstream. Don’t switch modes and replace the entire set of routing rules at once.
2. Reload the config using the method supported by your client. Restart the core if needed, then check the logs for upstream DNS connection errors.
3. On Windows, run ipconfig /flushdns to clear the system cache, then reopen the browser and test again. The browser and core may still have their own caches.
4. Compare the first page load with subsequent loads. If only the initial wait gets shorter and download speed stays the same, limit your conclusion to DNS resolution or connection setup.

Don’t respond to every slowdown by expanding fake-ip-filter. It prevents Fake-IP responses for specific domains, usually for needs such as LAN discovery or app compatibility; it is not a general-purpose speed boost list. Before changing it, identify the specific incompatible domain and behavior.

Layer 5: Local Settings — Check Traffic Capture, Resources, and Protocols

If nodes, the network, and rules all look normal, check the local device. The goal isn’t to find a “speed boost” switch, but to check for double proxying, resource bottlenecks, or retries at the app level.

TUN Does Not Boost Bandwidth

TUN captures traffic through a virtual network interface, making it useful for apps that don’t follow the system proxy. It changes how traffic enters the core; it does not increase the bandwidth in your node plan. Protocol stack, routing, and MTU settings can affect compatibility, but there is no single “fastest” value that works for every device.

If the system proxy works but TUN is slow, reproduce the issue with the same app and node, then check for route conflicts, DNS capture, other virtual network adapters, and core logs. Don’t change MTU, protocol stack, and DNS mode all at once; if performance improves, you won’t know which change helped.

Slow Browsing? Check UDP and QUIC Too

HTTP/3 uses QUIC, which typically runs over UDP. If an app’s UDP route is unavailable, it may wait before falling back. The node protocol, server, and traffic capture method must all support the relevant traffic. Browser behavior with the system HTTP proxy may differ from behavior when traffic is captured by TUN.

Check the protocol and request timings in your browser’s Network panel, or temporarily disable QUIC-related browser experiments for comparison, then restore them afterward. Investigate this path only if you see evidence such as UDP failures or a delay before fallback. Disabling QUIC is not a universal fix for slow connections.

Retest and Record Results: Narrow the Diagnosis to One Actionable Issue

After each change, rerun the original test against the same destination for the same duration, three times. Keep changes that help and revert those that don’t. A single test supports only a limited conclusion: switching nodes helping doesn’t mean DNS needs changing, and a hotspot helping doesn’t mean the client needs reinstalling.

1. Clear difference between nodes: Keep the node that performs consistently, and report the problem node and time of the issue to your subscription provider.
2. Clear difference by network or time: Focus on the access network, Wi-Fi conditions, or node ingress route instead of repeatedly changing local DNS settings.
3. Wrong rule or egress: Adjust the rule or policy group for the relevant domain, then check that both the main request and resource requests follow the expected route.
4. Only the first request is slow: Investigate DNS resolution, TLS, and the remote server’s time to first byte. Don’t use a small webpage request to estimate bandwidth.
5. Only one traffic capture method is slow: Keep using the method that works, and provide the core version, reproduction steps, and redacted logs for further diagnosis.

The most useful finding isn’t “I changed every setting,” but something specific, such as “node A is slow for the same destination, but node B works” or “the issue occurs only in TUN mode.” A clear record points to the right layer to investigate next. If basic connectivity isn’t confirmed yet, start with the connection check steps to establish a consistent baseline.