Clash Slow on Mac: Troubleshoot Nodes, Routes, and Local Settings

Start here: Tell slow loading, slow downloads, and intermittent drops apart

The node latency shown in Clash is not the same as download speed. Loading a webpage involves DNS lookup, connection setup, the TLS handshake, and data transfer. A delay at any stage can feel like a slow connection. Identify the symptom first, then narrow it down by checking the node, network route, and local settings in that order. This is more useful than changing DNS, rules, and TUN settings all at once.

Set up a repeatable test

1. Pause cloud sync, system updates, and other downloads. Use the same Mac, network, and target file throughout.
2. Set the policy group used by the request to manual selection and pin one node to prevent automatic switching during the test.
3. Run each test three times and record the time, node, network type, proxy method, and result. Mark the first run separately, as caching may affect it.
4. Change one variable at a time. Restore the original settings when finished and check whether you can reproduce the result.

Layer 1: Node quality and the actual proxy exit

Open the client's connection list, find the domain you're accessing, and check the matched rule, policy group, and final node. Selecting a node in the interface doesn't mean every request uses it: a rule may point to another policy group or match DIRECT. Interfaces and menu names vary, so use the connection details available in your client.

Pin a node to rule out automatic switching

url-test selects nodes based on configured probe results, fallback picks an available node in order, and load-balance distributes connections according to its policy. For troubleshooting, use a manual selection group to keep the test request on the same exit. Switching nodes usually won't move existing long-lived connections to the new node, so start a fresh request. If needed, close only the existing connection for the app you're testing.

• Only one node is slow: The node may be overloaded, bandwidth-limited, or affected by its upstream route. Switch nodes and test again.
• Several nodes in the same region are slow: Compare nodes in other regions, with different entry points or providers. Node names alone don't tell you whether routes are independent.
• All nodes are slow on one website: Check for site-side rate limits, CDN routing, account restrictions, or limits on access from your exit IP.

Latency is not throughput

Low latency helps with interactive tasks, but sustained downloads also depend on congestion, packet loss, available bandwidth, and the remote server's capacity. A node with lower latency may still download large files more slowly. Test with the same file from a legitimate, accessible source. Don't compare downloads from different sites or use a webpage only a few KB in size to estimate bandwidth.

Pay attention to units: download tools report MB/s, while internet plans are advertised in Mbps. Using decimal units, 10 MB/s is about 80 Mbps; protocol overhead affects real-world results. This is a unit conversion, not a promise of node speed.

Layer 2: Routes from your local network to the node and from the node to the destination

A proxy connection involves at least two routes: from your Mac to the proxy entry point, and from the proxy exit to the destination service. Switching nodes changes at least part of the route, so also test a different local network. Keep the node and destination the same, then briefly compare using your phone's hotspot. If the hotspot is noticeably faster, the issue is more likely with your Wi-Fi, router, or access provider's route.

Use curl to confirm requests are going through the proxy

Terminal tools don't necessarily use the macOS system proxy. The command below explicitly sets a local HTTP or mixed port and reports timings for each stage. It uses 127.0.0.1:7890 as an example; check the port your client is listening on before running it. Use an HTTPS URL for an accessible, moderately sized file. Don't paste signed URLs or subscription links into public logs.

printf 'Enter the HTTPS URL of the test file: '
read -r TEST_URL
curl --proxy http://127.0.0.1:7890 --noproxy "" \
  --location --output /dev/null --silent --show-error \
  --connect-timeout 10 --max-time 60 \
  --write-out 'status=%{http_code}\nconnect=%{time_connect}s\ntls=%{time_appconnect}s\nfirst_byte=%{time_starttransfer}s\ntotal=%{time_total}s\nbytes=%{size_download}\nspeed=%{speed_download} B/s\n' \
  "$TEST_URL"

speed_download is measured in bytes per second. time_starttransfer is the total time from the start of the request until the first byte arrives, not just server processing time. When accessing HTTPS through a local HTTP proxy, time_connect mainly measures the connection to the local proxy; it is not the latency to the remote node. The proxy tunnel and TLS phases that follow are also affected by the remote route.

If the destination allows direct access, replace the proxy options with --proxy "" --noproxy "*" for a comparison. This only bypasses curl's explicit proxy; with TUN enabled, the request may still be routed through it. To test a true direct connection, turn off TUN first and check that no other VPN is handling the traffic.

Check for congestion by time of day

If the same node works well during the day but slows down consistently in the evening, and wired and Wi-Fi connections perform similarly, shared-route congestion is worth investigating. Record three results in each of two time windows; this is more informative than a single speed test. Pinging the proxy server offers limited clues: it may restrict ICMP, and ICMP routes or priority may differ from those of actual proxy traffic.

Layer 3: System proxy, rules, and local resource use

On recent versions of macOS, go to System Settings → Network → your current network service → Details → Proxies to check HTTP, HTTPS, and SOCKS settings. Labels may vary slightly between versions. Confirm the proxy address is local and the port matches your client, then check for settings left behind by an older client.

networksetup -listallnetworkservices
networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"
scutil --proxy

If the network service has been renamed or you're using USB Ethernet, replace Wi-Fi in the command with the actual service name shown by the first command. Check the output for the enabled status, server address, and port. Don't rely on the color of a client toggle to determine whether the system settings were applied.

Check for conflicting proxies and mismatched rules

• Browser proxy extensions may override the system proxy. Disable them during testing, or make a note of the exit route they use.
• Running two tools with TUN, VPN, or traffic-filtering features at once can cause routing conflicts. Test with only one traffic interception method enabled.
• If only certain domains are slow, check their connection details to see whether they're incorrectly routed through a remote proxy or bypassed by a direct-connection rule.
• Open Activity Monitor and check CPU and network use. If the client or another process is using resources continuously, pause demanding background tasks and repeat the same request.

Clash is a name used across the core and client ecosystem; graphical clients don't all support the same overrides, logs, or service modes. Clients using mihomo may also handle permissions and configuration merging differently. Before making changes, check the configuration currently in effect, not just the original YAML in your subscription. See the YAML guide for field definitions.

DNS modes: Troubleshoot slow first loads and lookup failures

DNS issues often show up as slow first loads, failures on some domains, or inconsistent results between browsers and command-line tools. mihomo's fake-ip mode assigns mapped addresses to domains, while redir-host uses real DNS results. It's not simply a choice between fast and slow: compatibility depends on the app, routing method, and DNS configuration.

First, find out which DNS path is being used

1. Run scutil --dns to see the system's current resolvers and their scopes. VPNs and different network interfaces may each provide their own resolvers.
2. Check whether your browser has its own Secure DNS setting enabled. A working browser lookup doesn't mean system resolution or the client's built-in DNS is working properly.
3. Check client logs for DNS timeouts, unreachable upstream servers, or repeated retries. If the upstream DNS depends on a proxy connection that isn't established yet, this can create a startup dependency issue.
4. Repeat the test for one affected domain, then compare results before and after switching networks. Don't change every upstream server and mode at the same time.

When accessing HTTPS through an HTTP proxy, the proxy usually resolves the destination domain. That means curl's local DNS lookup time doesn't directly measure DNS performance for the destination. Similarly, dig may use a different resolution path from your browser, the system resolver API, or mihomo's internal resolver.

TUN stack and Wi-Fi power saving: Test one variable at a time

Choosing a TUN stack and checking routes

TUN uses a virtual network interface to handle IP traffic; it doesn't increase node bandwidth. mihomo offers the system, gvisor, and mixed stack options. Availability and defaults depend on the client's bundled core and documentation. Each stack can affect protocol handling, compatibility, and resource use; there is no single best choice for every Mac.

Note the current stack, then change only that option. Re-enable TUN or restart the core as required by your client, and repeat the same request. The example below shows only the field to compare, not a complete configuration. Don't use it to overwrite existing TUN, DNS, routing, or permission settings.

tun:
  enable: true
  stack: system

If the explicit HTTP proxy works but TUN doesn't, focus on routing loops, DNS interception, and other network extensions. Don't start by changing the MTU at random. Only test that setting separately if you have evidence such as large transfers stalling to a specific destination or a connection freezing after the handshake, and follow the core's documentation. Before enabling automatic routing, consider your access needs for local devices and work VPNs.

Separate Wi-Fi issues from Low Power Mode

Mac Low Power Mode isn't a proxy speed limit switch, so it doesn't prove that Clash is slowing downloads. You can include it as a test variable: check Low Power Mode under System Settings → Battery, plug in your Mac, and compare results at the same location using the same node. Available options and labels vary by Mac model and macOS version, and one change alone doesn't establish cause and effect.

• Option-click the Wi-Fi icon in the menu bar to view the signal, noise, and transmit rate reported by the system. These are wireless link metrics, not internet download speeds.
• Test again near the router and, if possible, compare with a wired connection. If Ethernet works normally but Wi-Fi doesn't, start by checking signal strength, interference, and roaming.
• Test 5 GHz and 2.4 GHz networks separately. 5 GHz isn't always more reliable when there are many walls; compare repeated results at your current location.
• If speeds drop only after waking from sleep, reconnect to Wi-Fi and check the client's proxy and TUN status. Reinstalling the client repeatedly is not a long-term fix.

Classify the results and restore your settings

The goal is a reproducible finding, not a long list of settings you've changed. For example, “With the same node and file, Ethernet is normal but Wi-Fi stays slow” points to the wireless network. “The explicit proxy works with TUN off” narrows the issue to local traffic interception. The more specific the finding, the less you have to rely on guesswork.

1. Node issue: Switch exits and send your provider the time, node, and destination details. Hide account information, subscription URLs, and authentication parameters.
2. Route issue: Keep the results from different access networks and times of day to distinguish local network congestion from issues between the exit and destination.
3. Local issue: Keep only changes you've verified as effective, and restore any temporary stack, DNS, policy group, and power-saving settings.
4. Still can't pinpoint it: Share the client name, core type, macOS environment, proxy method, and redacted logs. A latency screenshot alone isn't enough.

Trying another client can help identify GUI configuration or permission differences, but it won't increase the capacity of your subscription nodes. Find the bottleneck first, then decide whether to adjust rules, fix local settings, or change exit routes.