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

First, identify exactly where the slowdown occurs

Clash may show as connected while webpages load slowly, videos buffer frequently, or downloads remain sluggish. The issue is not always node performance. A complete connection includes the local app, Clash core, DNS resolution, proxy node, ISP route, and destination website. Congestion at any point can make an iPhone feel slower as soon as Clash is enabled.

Before troubleshooting, keep the variables fixed. Use the same Wi-Fi network, speed-test site, browser, and proxy node. Run each test for at least 30 seconds and repeat it three times. Do not change the node and network at the same time, or you will not know what caused the improvement.

Record four baseline sets

For example, if a direct download reaches 280 Mbps but stays around 85 Mbps through the proxy, the bottleneck is likely the proxy route or node. If the direct connection reaches only 18 Mbps, a proxy usually cannot exceed the limit of the current access network. If the speed test is normal but the first page load takes 3–5 seconds, check DNS before testing bandwidth again.

Layer 1: Check node load and protocol

First confirm the node actually selected on Clash’s policy-group page. With an “Auto” or “Fallback” policy group, the group name shown on the home screen is not the final exit node. Open the “Proxies” or “Policies” page and expand the relevant group to see the specific selected node.

Test sustained throughput with a fixed file

1. Keep the current node unchanged, and pause cloud sync, system updates, and video playback.
2. Choose a repeatable 100 MB to 500 MB test file and observe the stable speed after 30 seconds.
3. Wait two minutes, repeat the test twice, and record the minimum, median, and maximum values.
4. Change only the node. Do not modify DNS, mode, or the local network, then run the same test.

If a node records 72 Mbps, 69 Mbps, and 74 Mbps across three rounds, it is relatively stable. If results swing sharply between 8 Mbps, 91 Mbps, and 17 Mbps, common causes include high node load, shared upstream bandwidth, or packet loss. Further local rule changes are unlikely to help much.

Node protocols and device performance

Different protocols consume different amounts of CPU for encryption, encapsulation, and transport. Newer iPhones typically handle common Shadowsocks, Trojan, VLESS, and WireGuard traffic easily, but older devices may throttle under high bandwidth, heavy encryption, or sustained heat. During testing, open iOS “Settings” → “Battery” to see whether the Clash client uses unusually high power, and make sure the device is not noticeably hot.

• Only one node is slow: Suspect node load, the node’s exit route, or its configuration first.
• All nodes in one region are slow: The regional entry, exit, or ISP interconnection may be congested.
• Every protocol is slow: Continue by checking the intermediate route and local network.
• Only one protocol is slow: Check that protocol’s transport parameters, UDP support, and server configuration.

Layer 2: Separate node issues from route issues

Between your iPhone and the proxy node are your home router, broadband ISP, mobile network, and inter-network links. An idle node does not guarantee a smooth route from your device to that node. The simplest way to separate the causes is to keep the node unchanged and switch the access network.

Run a cross-check on Wi-Fi and cellular

1. On Wi-Fi, choose a fixed node and complete three rounds of latency and download tests.
2. Turn off Wi-Fi, use 4G or 5G, and test the same node again.
3. If cellular is clearly faster, restart the modem and router, then check performance during broadband peak hours.
4. If Wi-Fi is faster, check cellular signal strength, data throttling, and current cell-site load.

For example, if the same node delivers 240 ms latency and 12 Mbps on home Wi-Fi but 96 ms and 83 Mbps on 5G, the node is probably not generally broken; the route from your home broadband connection to that node is likely poor. Conversely, if both networks stay near 10 Mbps while direct connections reach 200 Mbps and 150 Mbps respectively, a node-side limit is more likely.

Identify peak-hour congestion and persistent packet loss

Route congestion often appears between 20:00 and 23:00 local time. Run the same test once in the morning, afternoon, and evening. If daytime performance is stable but drops sharply at night, do not keep changing settings; switching the entry region or using a different carrier route is usually more effective.

A latency spike from 80 ms to 180 ms does not necessarily affect downloads. If timeouts occur every few seconds, video, voice calls, and games are more likely to stutter. Some clients show latency only for successful requests, so a timing-out node may still display a normal value. Check the connection log for repeated timeout, connection reset, or context deadline exceeded messages.

Check your home router and Wi-Fi

• Prefer 5 GHz or 6 GHz Wi-Fi and avoid crowded 2.4 GHz channels.
• Retest close to the router to rule out retransmissions caused by walls or a weak signal.
• Temporarily disable secondary proxies, parental controls, and traffic shaping on the router to avoid duplicate processing.
• Make sure no device on the local network is uploading photos, syncing cloud storage, or downloading a large update.
• If both the router and iPhone run a proxy, keep only one layer enabled for testing to avoid forwarding traffic twice.

Layer 3: Check Clash local settings

When several nodes and access networks are all slow, inspect the local Clash configuration. Do not change ten switches at once. Change one item at a time, retest, and then decide whether to keep it.

Compare Rule mode with Global mode first

On the client’s “Proxies” or “Mode” page, temporarily switch Rule to Global and test with the same node. If Global mode is clearly faster, Rule mode may be sending the test domain through DIRECT, selecting another policy group, or matching an unsuitable rule. Switch back to Rule after testing and review the matched rules in the connection log.

Rules are matched from top to bottom, and matching stops at the first hit. An unsuitable order for domain rules, rule providers, and GEO rules can send a destination through the wrong exit. A download site may connect directly while its resource domains use the proxy, resulting in a normal page load but slow file downloads.

Reduce frequent health checks

Node health checks do not saturate bandwidth by themselves, but too many checks at short intervals can repeatedly wake the network extension and create extra connections. If a policy group contains 80 nodes and checks every 30 seconds, it may generate 9,600 requests per hour. For everyday use, try setting interval to 600 seconds and the rule-provider update interval to 86400 seconds.

proxy-groups:
  - name: Auto Select
    type: url-test
    proxies:
      - Node A
      - Node B
      - Node C
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80

rule-providers:
  common:
    type: http
    behavior: classical
    path: ./ruleset/common.yaml
    url: https://example.com/rules/common.yaml
    interval: 86400

Choose a test URL that is stable, returns very little content, and is reachable on the current network. Do not configure multiple large policy groups to check every 30 or 60 seconds. If the client offers “Settings” → “Parameters” → “Health Checks,” disable automatic testing for policy groups you do not use.

Check TUN mode and MTU

TUN mode takes over more system traffic and is useful for apps that need transparent proxying, but an incorrect MTU can cause fragmentation, retransmissions, or slow loading on some websites. Common test values are 1500, 1400, and 1280. Do not jump across several values at once: record the current setting, change it to 1400, and retest. If the issue occurs only on cellular networks or a specific WireGuard route, continue with 1280.

tun:
  enable: true
  stack: mixed
  mtu: 1400
  auto-route: true
  strict-route: false

This syntax applies to clients that support Clash.Meta or mihomo configuration syntax; older Clash cores may not support every field. An iOS client may instead expose these options under “Settings” → “Parameters” → “TUN.” After changing the setting, disconnect and reconnect the system VPN so the network extension reloads the configuration.

Make sure there is no duplicate proxy

iOS usually allows only one primary VPN configuration to be active at a time, but browser proxies, router proxies, and Clash can still create multiple forwarding layers. Go to iOS “Settings” → “General” → “VPN & Device Management” → “VPN” and confirm that the expected client is connected. Then open “Settings” → “Wi-Fi” → current network → “Configure Proxy.” When Clash handles traffic, this should usually be set to “Off.”

Treat slow DNS and slow bandwidth separately

DNS mainly affects domain resolution and the initial connection. A typical sign is waiting several seconds after entering a URL, followed by normal image and video speeds once the page starts loading. If a large file has begun downloading but remains at only a few hundred KB/s, changing DNS alone usually will not fix a sustained bandwidth bottleneck.

Use IP-versus-domain behavior to narrow it down

• Every site opens slowly the first time but becomes fast after refresh: check DNS timeouts and caching first.
• Only a specific domain is slow: check its matched rule, IPv6 result, and CDN route.
• The speed-test site has normal latency but low download speed: return to the node and route layers.
• The log repeatedly shows DNS timeout: switch to reachable nameservers and check the listening address.

A mihomo-compatible configuration can start with a simple DNS setup for comparison. The example below enables fake-ip, uses two explicit DNS servers for primary resolution, and avoids stacking too many fallbacks. Public DNS reachability varies by network, so use results measured in your current region.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 223.5.5.5
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

1053 is a common example of a local listening port for Clash DNS, not the port of an external DNS service. If the client manages DNS automatically, do not let another local service bind to the same port. Before editing, save the current values under “Settings” → “Parameters” → “DNS”; after testing, decide whether to restore them based on the results.

Test IPv6 separately

Some networks return AAAA records even though the actual IPv6 path performs poorly, causing a site to wait before falling back to IPv4. Temporarily set dns.ipv6 to false for comparison. If the initial load improves noticeably, continue checking local IPv6, the node’s IPv6 support, or the destination’s IPv6 route rather than blaming every issue on the node.

Choose the next action based on the results

After completing the three-layer tests, act on the comparison data instead of randomly switching settings. The mapping below can quickly narrow the scope.

Use a minimal configuration for the final isolation test

If the issue is still unclear, create a temporary configuration containing just one node, one policy group, and two rules. Use the common listening port 7890, disable scripts, rule providers, traffic sniffing, and extra health checks, and keep only essential features. If the minimal configuration works, the original configuration contains a conflict or extra overhead. If it is still slow, return to the node, route, or device layer.

mixed-port: 7890
mode: rule
log-level: info
ipv6: false

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - Test Node

rules:
  - MATCH,PROXY

After testing, do not use the temporary configuration as your long-term setup. Its purpose is to isolate variables; it does not include the direct-connection, LAN, privacy, and app-routing rules needed for daily use. Once you understand the scope of the original issue, restore DNS, rule providers, TUN, and health checks one group at a time, running the same test after each change.

Three common troubleshooting mistakes

Looking only at node latency

Latency helps filter out nodes that cannot connect or respond unusually slowly, but it does not represent bandwidth, packet loss, or peak-hour load. Include at least one download test lasting more than 30 seconds.

Changing DNS, MTU, and rules at the same time

When several settings change together, even if speed recovers you cannot tell which change helped. Save the original configuration, change one variable at a time, and record three rounds of results before and after each change.

Treating Global mode as a permanent speed boost

Global mode is useful for comparison testing. It sends more traffic through the same proxy, but it is not inherently faster. Once a rule-match issue is confirmed, fix the rules or policy group and return to Rule mode.