How to Troubleshoot Slow Clash Speeds: A Layered Check of Nodes, Routes, and Local Settings

Layer 1: Establish a repeatable speed baseline first

The node latency shown by Clash, webpage load time, and download speed are three different metrics. A latency test usually measures the response time of a single HTTP request or TCP connection. It shows whether a node is reachable, but does not directly represent sustained throughput. A node with 80 ms latency may have limited bandwidth, while another with 180 ms latency may maintain a higher speed when downloading a large file. When troubleshooting, do not focus only on the milliseconds shown in the node list.

Start by keeping the device, network, and test target consistent. Close apps that are syncing files, updating the system, downloading games, or uploading photos. Then choose a stable website and a sufficiently large test file. Run each test for at least several dozen seconds, recording initial page-load time, sustained download speed, and any mid-test pauses. Short speed tests are easily affected by caching, connection warm-up, and server-side throttling.

1. Temporarily disable Clash's system proxy or TUN mode and measure the current network's direct-connection performance.
2. Enable Clash, lock in one node and one proxy mode, and repeat the test with the same target.
3. Switch to another node in the same region and run the same test again.
4. Record latency, download speed, upload speed, packet loss, and page-resolution time separately.

If the direct connection is already noticeably slow, check the local broadband, cellular network, or Wi-Fi first instead of immediately changing the Clash configuration. If only proxied connections are slow, continue by checking the node, ingress route, egress route, and client settings. If only one website is slow while other proxied traffic works normally, the issue may also lie with the destination site, routing policy, or the site's connection quality to the exit address.

Layer 2: Separate node latency, bandwidth, and load

The node is the most common speed bottleneck, but “node available” only means that a connection can be established. Actual node speed also depends on server bandwidth, concurrent load, protocol implementation, carrier ingress quality, and the route from the exit node to the destination website. Slower speeds during peak hours that recover overnight usually point to load or route congestion. If speeds remain consistently slow all day, check node throttling, path quality, and the device's processing capacity.

Do not treat latency tests as full speed tests

Clash clients commonly use a test URL to calculate node latency. The result is affected by the test URL, connection reuse, DNS caching, and timeout settings. Low latency with low throughput may indicate insufficient node bandwidth; occasional latency spikes may indicate link jitter. If many nodes time out at once, check the subscription, network permissions, DNS, or server status instead of repeatedly testing nodes one by one.

When choosing a node, group nodes by region first, then compare at least three nodes in the same region. Tests should cover webpages, small files, and sustained downloads. For video playback, also watch whether buffering remains stable, since a high instantaneous peak does not guarantee stable long-term throughput. If the client supports URL Test, Fallback, or load-balancing policy groups, understand how each makes its choice: URL Test tends to select nodes with faster test responses, Fallback prioritizes failover, and load balancing may send different connections through different nodes.

Check whether the policy group actually selected the target node

Configurations often contain multiple layers of policy groups. For example, application rules may first enter “国外网站”, which then references “自动选择” before ultimately pointing to a specific node. Switching a group in the interface does not necessarily mean that the current request went through it. Open the connection list or logs and confirm which rule matched the destination domain, which policy group handled it, and which node was ultimately used.

Destination domain → rule match → policy group → child policy group → specific node

If traffic matches DIRECT, the speed test is actually measuring a direct connection. If it matches REJECT, the request is actively denied. If it matches an automatic policy group, the client may select another node in the background. During troubleshooting, temporarily pin a specific node in the policy group to prevent automatic switching from affecting the results. Restore the original policy afterward.

Layer 3: Determine whether the ingress or egress route is congested

A proxied connection includes at least three path segments: the device to the local carrier, the carrier to the proxy node, and the proxy node to the destination website. Any segment can reduce speed. A nearby node may be geographically closer, but that does not guarantee a shorter inter-carrier route. The same node can perform completely differently over different broadband or cellular networks.

The most practical method is cross-testing. Keep the node unchanged and switch the device from home Wi-Fi to a mobile hotspot; or keep the network unchanged and switch to a node in another region or with a different ingress type. If the same node recovers after changing networks, the issue is more likely on the path from the local carrier to the node. If performance recovers after changing nodes, load or routing on the original node is more suspect.

• Normal during the day, slow at night: First consider peak-hour congestion, shared-bandwidth load, and inter-carrier pressure.
• Webpages are fast, downloads are slow: Check sustained node bandwidth, destination-site throttling, and single-connection performance.
• Downloads are fast, but video buffers frequently: Check the streaming service's egress route, policy matching, and connection stability.
• Initial access is slow, then normal: Focus on DNS, TLS connection setup, and the initial route selection.
• Speed periodically drops to zero: Check packet loss, wireless interference, node restarts, connection switching, and device sleep policies.

The command-line ping utility provides only limited evidence. Some servers deprioritize ICMP responses or do not respond at all, while TCP and UDP services continue to work. Traceroute can help show where the path changes significantly, but a nonresponsive hop alone does not prove a failure. More reliable conclusions come from comparisons across multiple times, networks, and nodes.

Layer 4: Check DNS resolution and connection wait times

DNS issues are often mistaken for slow internet. Typical signs include a long blank screen after entering a URL even though the page loads normally afterward, some domains opening while others repeatedly time out, or performance recovering immediately after switching networks. In these cases, the bottleneck may be in domain resolution rather than data transfer through the proxy node.

Clash or mihomo configurations can take over DNS and use mechanisms such as standard DNS, encrypted DNS, Fake IP, or Redir Host depending on the operating mode. Toggle names vary between clients, but the actual behavior is determined jointly by the core configuration and the configuration generated by the client. Before making changes, check whether DNS is enabled, along with the listen address, default resolver, and upstream servers.

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.example/dns-query

The snippet above only illustrates the relationship between fields; the example addresses should not be treated as usable services. For real troubleshooting, use a resolver that is reliably reachable and confirm that the system or router is not forcibly forwarding DNS requests elsewhere. If the upstream encrypted DNS service itself requires an initial domain lookup, also make sure the bootstrap or default resolution path works correctly.

Common misdiagnoses in Fake IP mode

Fake IP returns reserved addresses for domains, then the core maps those addresses back to the original domains and applies rule matching. This helps take over domain traffic consistently, but some LAN devices, specialized apps, or services that require real addresses may need to be added to an exclusion list. If only a printer, router admin page, LAN storage device, or a small number of apps misbehaves, check fake-ip-filter and LAN bypass rules instead of assuming that the node has slowed down.

Old DNS entries may also remain cached on the system. After changing the configuration, restart the relevant apps and, if necessary, clear the system DNS cache before testing again. Browsers may also use their own secure DNS, causing the browser and other programs to follow different resolution paths. Confirm separately whether the system, browser, or Clash is handling DNS so that multiple components do not rewrite it at the same time.

Layer 5: Compare system proxy, rule mode, and TUN mode

A system proxy usually uses the operating system's proxy settings to tell applications to send HTTP or HTTPS requests to Clash. Browsers and desktop programs that follow the system proxy can be intercepted, but some games, command-line programs, store apps, and software with its own network stack may ignore the setting. TUN mode creates a virtual network interface and intercepts more TCP, UDP, and DNS traffic at a lower layer. It offers broader coverage but depends more heavily on permissions, routing tables, and operating-system network components.

If the browser is fast but a game, terminal download tool, or specific app is slow, first confirm whether that app is entering the proxy. Check Clash's connection list for the request and review the destination address, protocol, rule, and final node. No entry usually means the traffic never reached the core. An entry using DIRECT means the rule selected a direct connection. Only an entry that passes through a node warrants further analysis of the node and route.

How to compare rule mode and global mode

Rule mode uses domains, IPs, processes, or rule sets to choose DIRECT, REJECT, or a policy group. Global mode generally sends most traffic to the selected proxy policy. When troubleshooting a particular website, briefly switch to global mode for comparison. If the site recovers in global mode but remains slow in rule mode, check rule matching, the policy group, and DNS. If both modes are slow, the node or route is more likely at fault.

Global mode is for temporary diagnosis only and should not replace fixing the rules. Restore rule mode after testing and identify the specific rule responsible for the difference in the logs. Also check the MATCH rule at the bottom of the configuration, since requests not matched by earlier rules ultimately fall through to it.

What to check when TUN mode reduces speed

• Confirm that the client has the system permissions required to create a virtual network adapter and modify routes.
• Check whether another VPN, virtual-machine adapter, game accelerator, or security tool is also modifying the routing table.
• Confirm that the MTU suits the current network; oversized packets may be fragmented or dropped.
• Check whether UDP is stable. Restrictions on UDP in some network environments can affect QUIC, gaming, and real-time communications.
• Compare speeds with TUN disabled and only the system proxy enabled to determine whether the issue is related to the virtual interface.

Some browsers prefer HTTP/3 over UDP. If the route has unstable UDP support, webpages may connect slowly, videos may stutter, or speed-test results may fluctuate. Use connection logs to confirm the protocol, then run a short comparison test. Do not permanently disable several network features at once; first determine which change actually affects the result.

Layer 6: Rule out device performance, wireless networking, and background apps

A proxy core must handle encryption, decryption, rule matching, DNS processing, and connection forwarding. Modern desktop devices can usually handle everyday traffic, but low-power routers, older phones, resource-constrained servers, or devices carrying many simultaneous connections may push CPU usage close to its limit. In that case, switching nodes may not help because the bottleneck is local processing capacity.

During a speed test, open Task Manager or a system monitor and watch CPU, memory, disk, and network usage for the Clash client, core process, browser, and security software. If one core stays fully loaded when speeds drop, simplify unnecessary complex rules, reduce excessive logging, limit concurrent connections, or compare results on a more powerful device.

Wi-Fi is another common variable. The 2.4 GHz band is prone to interference from neighboring networks, Bluetooth devices, and household appliances. Farther from the router, a device may repeatedly retransmit data. Prefer Ethernet or a stable 5 GHz or 6 GHz network for baseline tests. If wired performance is normal but Wi-Fi is slow, adjust the channel, distance, and router placement before changing the proxy protocol.

Background apps consume upstream bandwidth, and a saturated upstream can increase download latency. Cloud-drive syncing, photo backups, video calls, and torrent uploads can all cause this. Even when download capacity remains available, queueing delay can make webpages and interactive requests feel sluggish. Pause background tasks, wait a while, and then run the same test again.

Configuration size and log level

Large rule sets and frequently updated subscriptions increase load time, but a normal configuration should not add noticeable latency to every request. If the client remains sluggish long after startup, check for duplicate rule sets, repeated references to the same resource, and an excessively verbose log level. Debug logging is useful for short-term diagnosis; continuously recording large volumes of connection data increases disk writes and interface-rendering overhead.

If speeds suddenly drop after a subscription update, also verify whether policy-group names and node names changed. The client may fall back to a policy group's default item, or automatic testing may select a different node. Compare the final configuration and currently selected items before and after the update; this is more revealing than repeatedly reimporting the subscription.

A ten-minute troubleshooting workflow, in order

Speed issues are easiest to narrow down layer by layer, from the outside in. The workflow below does not require immediately editing YAML. First use comparisons to identify the affected layer, then adjust the relevant setting.

1. Test direct access: Test the current network with the proxy disabled to confirm that the base connection has no obvious issue.
2. Pin a node: Disable automatic selection, choose one node, and record its latency and sustained download speed.
3. Switch nodes: Choose one node in the same region and one in a different region, then compare performance during peak and off-peak hours.
4. Inspect connections: Confirm that the request entered Clash and record the matched rule, policy group, and final node.
5. Switch networks: Test the same node over a mobile hotspot or another broadband connection to assess the ingress route.
6. Check DNS: Determine whether the delay occurs during resolution or transfer, and verify the resolution paths used by the system and client.
7. Compare modes: Compare rule mode with global mode, and the system proxy with TUN mode.
8. Check resources: Look for CPU, memory, wireless-signal, and background-upload bottlenecks.
9. Reload the configuration: Confirm that the configuration parsed successfully and that the policy-group selection and subscription update match expectations.
10. Restore settings: Revert global mode, debug logging, and temporary DNS changes used only for testing.

The final record should include the test time, network type, client version, core type, proxy mode, node name, target website, and speed results. If you need to report the issue to a node provider or client project, this information is far more useful diagnostically than saying that it “feels slow.” Before sharing configuration details, remove subscription URLs, authentication data, node credentials, and personal network information.

Troubleshooting takeaway: locate the slow segment first

Slow Clash speeds do not necessarily mean high node latency. A complete connection involves the local network, DNS, rule matching, proxy ingress, node processing, egress routing, and the destination website. Test a direct-connection baseline first, pin a node, then compare results by changing the network, node, and mode one at a time. This usually separates node load, carrier routing, DNS delays, and device bottlenecks quickly.

If every node is slow on the same network but recovers after switching networks, prioritize the local network and carrier path. If only a few nodes are slow, focus on node load and egress routing. If the first page load is slow but downloads are stable, check DNS. If only a specific app misbehaves, confirm that the system proxy or TUN mode is actually intercepting its traffic. Recording each layer, changing one item at a time, and restoring temporary settings afterward prevents a simple issue from becoming a tangle of configuration conflicts.