How to Troubleshoot Slow Clash Speeds: Identify Whether the Node, Network Route, or Local Settings Are at Fault

Define “slow” first: latency, bandwidth, and response time are different things

A Clash or mihomo panel may show latency of only a few dozen milliseconds while pages still open slowly; conversely, a node with 180 ms latency may reliably saturate your connection. Latency, packet loss, available bandwidth, and website response time describe different stages of the connection. If you focus on one number in the node list, it is easy to mistake route congestion for a client problem.

Build a repeatable testing baseline

Before switching nodes, fix the test conditions. Close apps that are syncing files, downloading updates, or playing video. Keep the same device on the same router, and choose two test targets: one for page opening time and one for sustained downloads. Run each test at least three times and record the median; do not draw conclusions from a single peak result.

1. Switch the client to “Direct” mode and record the local connection's latency and download speed.
2. Return to “Rule” mode and keep the same test node and test address fixed.
3. Test once in the morning and again from 20:00 to 23:00 in the evening, then compare the time periods.
4. Record the client's current mode, node name, download speed, time to first open, and whether any timeouts occur.

Layer 1: Check node latency, load, and protocol status

Node-side issues usually appear as only a few nodes in the same policy group becoming noticeably slow, with performance returning immediately after switching to another region or entry point. Distinguish between “the latency test passes” and “the node provides stable throughput.” Latency tests in Clash panels typically connect to a specified URL and measure response time. They can eliminate unreachable nodes, but they do not directly represent large-file download speed.

Compare nodes in the same policy group under identical conditions

Open the client's “Proxy” page and find the policy group actually used by the current rules. In common desktop clients, follow “Proxy” → “Node Selection” to view the nodes in the group. If you use Clash Verge Rev, check the active mode under “Settings” → “Clash Settings”, then return to “Proxy” to switch nodes. Do not change DNS, TUN, or rules while changing nodes, or you will not know which change produced the result.

• Choose three nodes in the same region and run the latency test three times for each.
• If latency varies by more than 100 ms or repeated timeouts occur, treat the node or entry point as unstable first.
• If latency is stable but downloads are slow, run a sustained download test for at least 60 seconds.
• If every node in the region is slow, add a node from another region as a control.
• If only one node is slow, replacing it is usually more effective than continuing to adjust local parameters.

A traffic multiplier is not a speed multiplier

The “0.5x”, “1x”, and “2x” values commonly shown in subscription panels usually indicate traffic-billing multipliers, not speed multipliers. A 2x node is not inherently twice as fast as a 1x node; it may use a different route, or the value may only affect how traffic is deducted. Judge performance by measured throughput, packet loss, and stability across different times.

An automatic latency group may select a low-latency, low-bandwidth node

The url-test policy group automatically selects a node based on the response from its test URL. If the target returns very little data, a node may win because its handshake is fast even though its sustained bandwidth is poor. Increase the test interval if needed to avoid frequent switching. You can also group nodes with similar stability instead of mixing every region together.

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

interval: 300 means testing every 300 seconds, while tolerance: 80 helps reduce frequent switching when latency differences are small. This URL is only for availability and response testing, not a full bandwidth test. Before editing a subscription-generated configuration, confirm whether a subscription update will overwrite local changes.

Layer 2: Check peak congestion, packet loss, and route changes

Route problems can occur between the local ISP, interconnection points, entry servers, and exit servers. They often have a clear time pattern: normal speeds during the day but higher latency after 20:00, or normal performance on mobile networks but slower speeds on home broadband. Reinstalling the client or deleting the configuration repeatedly will not usually change the result.

Cross-check by time and access network

Keep the node and client settings unchanged during testing; switch only the network. For example, test over home Wi-Fi first, then use a phone hotspot. If speed rises from 12 Mbps to 90 Mbps on the hotspot, the client and node can provide higher throughput, so the problem is more likely on the path from the home broadband connection to the node's entry point.

Latency variation matters more than a single low-latency result

A sequence such as 58 ms, 61 ms, and 64 ms is usually more stable than 28 ms, 190 ms, and a timeout. The latter includes a lower number, but jitter and packet loss can trigger TCP retransmissions and reduce download speed. Video, remote desktops, and games are also more sensitive to jitter.

On Windows, use PowerShell to check whether a TCP connection can be established to the node's entry port. Replace the example host and port with the values actually used by the subscription node:

Test-NetConnection example.com -Port 443
ping example.com -n 20

On macOS or Linux, observe latency continuously:

ping -c 20 example.com
curl -x http://127.0.0.1:7890 -o /dev/null -s -w "connect=%{time_connect} total=%{time_total}\n" https://www.gstatic.com/generate_204

The 7890 in this example is a common mixed port, not a fixed value. Check the actual port under the client's “Settings” → “Port Settings” or in the configuration file's mixed-port field. If the command returns “connection refused”, first check whether mihomo is running and whether the ports match; do not immediately conclude that the remote node has failed.

Layer 3: Check local DNS, rule matching, and proxy conflicts

If multiple nodes perform similarly and the problem persists after changing networks, return to the local configuration. Common symptoms include slow first page loads, an app bypassing the proxy, Rule mode being slow while Global mode works normally, and a sudden slowdown after enabling TUN. Check the local layer in this order: whether the connection enters the core, whether the correct policy is selected, and whether DNS is responding smoothly.

Check connection logs first, not just the node name

Open the client's connection or log page, then revisit the website that is having problems. In common clients, the “Logs” or “Connections” page shows the target domain, matched rule, and final policy. Confirm three things: whether mihomo captured the domain, which rule matched, and which policy group and node were ultimately used.

• If the target app's traffic is completely absent from the connection log, check the system proxy or TUN interception scope.
• If the target domain matches DIRECT but should use a proxy, check the rule order and rule-set update status.
• If the wrong regional policy group was matched, return to the “Proxy” page and check the current selection in that group.
• If DNS timeouts continue to appear in the log, troubleshoot the resolution path first.
• If the same request repeatedly establishes connections, check whether another proxy application is still running on the system.

Clash rules are matched from top to bottom, and the first match takes effect. An overly broad rule placed first can prevent later, more specific domain rules from matching. For example, GEOIP,CN,DIRECT should usually come after domain rules and before the final MATCH. Move only one rule category at a time, reload the configuration, and verify the result in the connection log.

rules:
  - DOMAIN-SUFFIX,example.net,Proxy Node
  - DOMAIN-KEYWORD,stream,Media Policy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy Node

Use Global mode for a short comparison

When Rule mode is very slow, briefly switch to Global mode and access the same target through the same node. If Global mode recovers immediately while Rule mode remains slow, the issue is usually rule matching, DNS routing, or certain resources taking a different path—not node bandwidth. Switch back to Rule mode after testing and correct the rules based on the logs; do not use Global mode long-term to hide a configuration problem.

Slow DNS often looks like “stuck first, then fast”

A DNS resolution timeout delays the first request. This is especially likely when nameservers differ greatly in quality, IPv6 resolves but is unreachable, or system DNS and mihomo DNS paths are mixed. The browser may wait for a failed connection to fall back. You can centralize DNS handling in the configuration and confirm that the client loaded it successfully.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://223.5.5.5/dns-query
    - https://1.1.1.1/dns-query

ipv6: false is useful for checking whether IPv6 fallback is causing delays, but it does not mean IPv6 should be disabled permanently on every network. If both the local network and proxy path fully support IPv6, re-enable it and test again. fake-ip can send domain traffic into rule evaluation earlier, but LAN devices, some games, and services that require real addresses may need to be added to fake-ip-filter.

Check for overlapping system and browser proxy settings

A common desktop conflict occurs when the client has enabled the system proxy while a browser extension forwards traffic to another port, or when an old client leaves a system proxy address behind after exiting. Requests may then be routed through two proxies or trigger failed retries on the local machine.

1. Open the client's “Settings” → “System Proxy” and confirm the current switch state.
2. Open “Settings” → “Port Settings” and record the HTTP, SOCKS, or mixed port.
3. Check browser proxy extensions and temporarily set them to follow the system proxy.
4. Check the operating system's network proxy and confirm the address is usually 127.0.0.1, with a port matching the client.
5. Fully quit other proxy clients, then retest first-open time and sustained downloads.

If the configuration uses mixed-port: 7890, both HTTP and SOCKS clients can connect to that port. Do not send the same browser request first through a SOCKS extension and then through the system HTTP proxy. When only browser proxying is needed and the system proxy is already active, the extension usually only needs to stay direct or follow the system settings.

TUN mode in detail: app interception, MTU, and UDP

TUN mode uses a virtual network adapter to intercept traffic from apps that do not follow the system proxy, making it useful for game clients, command-line tools, and some store apps. It also adds routing, DNS hijacking, and packet-processing steps. If “TUN off works, TUN on is slow”, inspect the TUN configuration before replacing the entire subscription's node set.

First determine whether only the TUN path is affected

1. Keep one node fixed, enable the system proxy, disable TUN, and test in the browser.
2. Keep the node unchanged, enable TUN, and test the same address.
3. Check the Connections page and confirm that both rounds matched the same rule and node.
4. If performance drops only with TUN enabled, check virtual-adapter conflicts, MTU, and the network stack.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

stack: mixed is a common compatibility choice in mihomo. If the device is also running a VPN, virtual machine, container network, or game accelerator, automatic routing may select the wrong egress adapter. First quit other software that creates virtual adapters, then restart the client and test again. Do not change stack, MTU, and DNS hijacking at the same time, or it will be difficult to identify the cause.

Typical signs of an unsuitable MTU

An MTU problem may allow small pages to load while large files stall, or cause uploads to fail on specific sites. Start with a conservative value for comparison, such as testing mtu: 1400 in the TUN configuration. Once it helps, adjust gradually. The right value varies by operating system, broadband connection, and underlying tunnel, so 1400 is only a troubleshooting starting point.

tun:
  enable: true
  stack: mixed
  mtu: 1400
  auto-route: true
  auto-detect-interface: true

If large-file downloads clearly recover after changing MTU while the node and rules remain unchanged, fragmentation or path MTU discovery may be involved. If there is no improvement, restore the original configuration and continue checking DNS and the route instead of lowering the value repeatedly.

Subscription and core status: rule out stale configurations and version mismatches

A failed subscription update does not necessarily take every node offline. The client may continue using a cached configuration, leaving node endpoints, rule sets, or DNS parameters outdated for a long time. Confirm that the “subscription update time” and the “currently running configuration” refer to the same content. After updating, apply or reload the configuration; a completed download alone does not mean the core has switched.

Check the subscription update time and configuration load result

• On the “Subscription” or “Configuration” page, check the last update time and make sure it is not a cache from several weeks ago.
• After a manual update, check for HTTP timeouts, authentication failures, or empty content.
• After a successful update, select that configuration and reload it.
• Open the Logs page and confirm that the configuration parsed successfully and that policy groups and rule sets were generated.
• If the subscription includes overrides, check whether local overrides still match the current fields.

When an older Clash configuration is migrated to mihomo, the basic proxy, policy-group, and rule structures usually remain usable, but some extension fields, TUN parameters, and rule-set behavior may vary by version. If the configuration fails to load, locate the field named in the log before deleting the entire subscription. Check the core version under the client's “Settings” → “Core” or “About” page; menu names vary slightly between clients.

A 10-minute troubleshooting workflow and how to interpret the results

When the problem is happening, use the sequence below to narrow it down quickly. The key principle is to change only one variable per round and record the results before and after each change.

1. Minute 1: Close background downloads and run one direct-connection test for the local baseline.
2. Minutes 2–3: Return to Rule mode, fix the test node, and record latency, first-open time, and 60-second download speed.
3. Minute 4: Switch to another node in the same region. If only the original node is slow, classify it as a node-side issue.
4. Minute 5: Switch to a node in another region. If all proxy nodes are slow but direct access is normal, continue checking the route or local settings.
5. Minute 6: Retest the same node using a phone hotspot. If the hotspot recovers, focus first on the home broadband path.
6. Minute 7: Check the connection log and verify the rule, policy group, and target node.
7. Minute 8: Briefly switch to Global mode. If it recovers, focus on rules and DNS.
8. Minute 9: Disable browser proxy extensions and other proxy clients to eliminate local proxy overlap.
9. Minute 10: Compare TUN on and off. If only TUN is slow, check the virtual adapter, MTU, and DNS hijacking.

What data to keep in your troubleshooting record

If you need to report the issue to a subscription provider, network administrator, or client project, “it’s slow” is difficult to reproduce. Provide comparable data, but do not publish subscription URLs, node passwords, or the full configuration. Keep the test date, time, access network, client version, mihomo core version, node region, operating mode, and test results.

Test time: 2026-06-20 21:30
Access network: home broadband, Ethernet connection
Operating mode: Rule mode, TUN enabled
Local direct connection: 286 Mbps
Node A: 72 ms latency, 18 Mbps sustained download
Node B: 81 ms latency, 96 Mbps sustained download
Phone hotspot + Node A: 74 Mbps
Rule match: MATCH → Proxy Node
Symptom: drops in the evening, recovers during the day

These records support a clear diagnosis: Node A performs poorly on the home broadband route in the evening, while Node B and the phone-hotspot comparison show that the client's basic settings are not entirely failing. Layered evidence like this makes it easier to find what actually needs to be replaced or adjusted than repeatedly clearing the configuration.