Troubleshooting slow Clash speeds

First, pinpoint the symptom: slow page loads, slow downloads, or dropped connections

FlClash uses the Clash Meta (mihomo) core to handle proxy connections. A web request may involve DNS lookup, rule matching, connecting to a node, making a remote request, and transferring data. A slowdown at any stage can look like “slow Clash speeds,” but each cause calls for a different fix. Note the symptoms before changing settings to avoid mistaking a routing issue for a DNS problem.

Pause cloud sync, system updates, and other downloads first. Use one device, one network, and one test file, keeping conditions consistent. Home broadband speeds are usually listed in Mbps, while download tools may show MB/s; 100 Mbps converts to a theoretical maximum of about 12.5 MB/s. Actual throughput also depends on protocol overhead, Wi-Fi signal, and the remote server, so the figures are not directly comparable.

Node layer: pin the proxy group and test the same destination

A low latency reading doesn’t guarantee fast downloads. Client latency checks usually measure the time for a single request to a specified address, which can be affected by the test endpoint, caching, and connection setup. It doesn’t directly measure sustained bandwidth. A node showing 60 ms may be congested, while one at 160 ms may still deliver fast downloads.

Test in A → B → A order

1. Open the proxy group and temporarily select node A manually. If you’re using an Auto or fallback group, make sure it won’t switch the outbound node during the test.
2. Visit the same destination and download the same file, provided it’s permitted for testing. Observe each run for about 30 seconds and note the initial wait and steady-state speed separately.
3. Switch to node B. Close the test page or stop the download, then start a fresh connection and repeat the test. Finally, switch back to A to check whether its initial slow result was a one-off.
4. Check the domain, rule, and outbound chain in FlClash’s connection log. Existing long-lived connections may continue using the original node; changing the proxy group won’t immediately move every existing connection.

For example, if A delivers about 1.2 MB/s in both runs and B delivers 8 MB/s, the only conclusion so far is that “B performed better for this destination at this time.” These are example readings, not results measured by this site. The same pattern could be caused by a longer route from A’s exit to the destination, speed limits based on the exit IP, or insufficient shared node bandwidth. Test a second destination to confirm.

In rule mode, a page’s main document, images, and video may use different proxy groups. Don’t rely only on the node selected in the page’s top-right corner. You can briefly compare Global and Rule mode, but make sure the Global group is actually using the same node. If Global mode is fine but Rule mode is slow, check whether slow requests are going direct, using another node, or matching an unsuitable rule. See the rule matching guide in Advanced Config for details.

Route layer: compare time, network, and destination

If several nodes are slow, the problem isn’t necessarily your local configuration. Nodes with different names may still share an entry point, exit, or upstream route. Add another network or test at a different time to narrow down the cause.

• Compare times: Test the same node and destination at 10:00, 20:00, and 23:00. If speeds consistently drop only in the evening, track the pattern for two or three days before concluding that peak-hour congestion is the cause.
• Compare connections: Switch the same computer from home Wi-Fi to a mobile hotspot. Keep an eye on data charges and limit the test to a short session. If the hotspot restores normal speeds but broadband remains slow, check your router, broadband connection, and related interconnection routes first.
• Compare destinations: Test legal downloads from at least two different sites. If only one site is slow, the cause may be its CDN routing, account limits, or the exit IP address.
• Compare local network conditions: If possible, test over Ethernet or closer to the router. If both direct and proxied downloads are slow, check for Wi-Fi interference and other devices using your bandwidth.

Ping packet loss is only a clue. Routers may rate-limit ICMP, and a nonresponsive hop doesn’t necessarily mean real traffic is interrupted. Proxy protocols, UDP forwarding, and ordinary Ping may also take different routes. Don’t change your entire configuration just because one hop shows an asterisk; check whether real downloads stall and whether the connection log shows retries.

Local device layer: system proxy and other network tools

The system proxy usually affects only apps that honor the setting; it doesn’t capture all traffic. TUN mode uses a virtual network interface and routing rules to capture eligible IP traffic. A working browser connection doesn’t mean games or command-line tools are using the proxy. Conversely, proxy environment variables in a terminal may send requests to an old client port.

First, establish a proxy path you can verify

1. Pause other proxy clients and nonessential VPNs, and note their original state. On managed work devices, don’t disable security components required by your organization; check the device policy first.
2. Confirm the actual listening port in FlClash’s active configuration; don’t assume an example port is the default. Check whether any browser extension specifies a separate proxy.
3. On Windows, check the system proxy under Settings → Network & Internet → Proxy. On macOS, go to System Settings → Network → your current network → Details → Proxies. Names may vary slightly between OS versions.
4. Turn off TUN and leave only the system proxy enabled, then retest with a browser that explicitly supports system proxy settings. Next, turn off the system proxy and test TUN on its own. This avoids changing both paths at once.

Assuming the local HTTP or mixed listener is actually 7890, the command below explicitly sends this request through that proxy. Use curl.exe in Windows PowerShell; macOS and Linux typically use curl. If your port differs, update the command first. The destination is for observing request timings, not a bandwidth test.

curl --proxy http://127.0.0.1:7890 --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, replace /dev/null with NUL. When accessing HTTPS through a local HTTP proxy, time_connect mainly measures the connection to the local proxy listener, not latency to the remote node. Time to first byte includes several stages, such as establishing the proxy tunnel, TLS, and the remote server’s response. Use this command to compare runs, not to diagnose a DNS problem from a single number.

TUN layer: check traffic capture and resources before changing stacks

If system proxy mode works but TUN is noticeably slower, first confirm that the virtual network interface was created successfully and the core has the required permissions. Permissions and service mechanisms differ across Windows, macOS, and Linux. Android uses system VPN authorization, which generally can’t be used at the same time as another VPN in the same user space.

Check in this order

• Check live connections: After an app sends a request, confirm that the corresponding connection appears in FlClash. If it doesn’t, investigate routing capture and app bypass settings before changing nodes.
• Check CPU usage: Monitor the core process during a download. Investigate device performance and data-processing overhead only if a core stays busy and throughput hits a consistent ceiling.
• Try another TUN stack: Common mihomo stack options include system, gvisor, and mixed. Available options depend on the platform, core, and client version. Change only one option at a time, re-enable TUN as prompted by the app, and retest. There’s no single stack that’s fastest on every platform.
• Check MTU last: Investigate path MTU only if small requests work but large downloads stall, or TLS connections repeatedly hang on a particular network. Changing MTU isn’t a general-purpose speed boost.

If you have evidence pointing to an MTU issue, and your configuration supports it, try 1400 as a diagnostic comparison. Record the original value first and restore it if there’s no improvement. A lower MTU means more packets per unit of data and doesn’t guarantee higher bandwidth. Before changing service modes, virtual adapters, or routes, read the TUN configuration guide to avoid settings that disrupt other network connections.

DNS layer: lookup time is not transfer bandwidth

DNS most often affects the first page load, connection setup, and address selection. Once a connection is established, changing DNS alone usually won’t fix slow, sustained large-file downloads. To see whether DNS is involved, compare the first request with repeat requests and check logs for timeouts, lookup failures, and the actual destination address.

How to assess Fake-IP vs. real-IP

fake-ip returns a virtual address that the core maps back to a domain when handling the connection. redir-host uses the actual resolved address. Seeing an address in the 198.18.0.0/16 range doesn’t automatically mean something is wrong; check the range in your active configuration. Don’t switch modes just because an address looks unfamiliar, or assume one mode is simply “fast” and the other “slow.”

1. Check the DNS configuration that’s actually active, not just the original subscription. Client overrides, patches, or merged configurations may change the final dns section.
2. Check whether your browser has its own Secure DNS setting enabled. If the browser performs lookups using DoH, system DNS tests may not reflect the browser’s actual path.
3. Check that the encrypted DNS upstream is reachable and that the DNS server hostname can be resolved without relying on an unavailable route. Misconfiguration can create a lookup dependency or cause repeated delays.
4. After changing DNS settings, clear the DNS cache if your client supports it, then restart the test app. Refreshing the page alone may leave existing connections or app-level caches in use.

Don’t replace your entire configuration with an unfamiliar DNS list. Changing resolvers can affect CDN addresses and IPv4/IPv6 selection, and a brief speed improvement doesn’t prove the resolver itself is faster. If logs show repeated IPv6 connection failures while IPv4 is stable, test the IPv6 route separately. Temporarily adjusting the relevant setting can test your theory, but a lasting fix means repairing the route or configuring address families for your network.

Record your findings: identify the layer

By the end of troubleshooting, you should be able to summarize the reproducible conditions in one sentence, such as: “On home broadband in the evening, node A is slow on two destinations; the same settings work on a mobile hotspot.” That’s more useful than “none of the nodes work.” When reporting an issue to your subscription provider or the client project, include a redacted time range, OS version, FlClash and core versions, and the steps you used to compare results.

Capture only the few dozen seconds needed to reproduce the issue. Remove subscription URLs, node passwords, authentication tokens, and private domains first. Full subscription links often contain credentials and must not be shared publicly. After testing, restore any temporary changes to the mode, proxy group, and system proxy, keeping only adjustments confirmed to help.

If the client can reproduce the issue consistently, consider updating to an official project release and recording the versions and test results before and after. Updating isn’t a substitute for troubleshooting; comparisons using the same node and destination while changing one variable at a time are what show whether a change helped. If you haven’t confirmed the subscription import or outbound mode, start by following the setup guide to establish a working baseline, then test speeds.