How to fix all Clash nodes timing out: Check subscriptions, system time, and port conflicts

First, distinguish failed latency tests from actual connection failures

In a Clash client, “timeout” usually means a request did not complete within the allotted time. It does not necessarily mean the subscription is invalid. A latency test sends a request to a test URL through a selected node; a failure at any stage—node handshake, DNS resolution, or the test site's response—can result in a timeout. Clash is a general term for a client ecosystem. The interface and features depend on the client and the core in use; mihomo also commonly appears in configuration guides referring to the Clash Meta name.

First, narrow down the scope: are all nodes failing latency tests, or only one proxy group? Do tests fail while websites still load, or do all proxy requests fail? Did the issue start after updating the configuration or switching Wi-Fi? These details are more useful than running dozens of tests in a row.

1. Pause bulk testing and select one node manually. In rule mode, make sure the request actually matches the proxy group that contains that node.
2. Open the client's Connections and Logs views, then visit a known-working HTTPS page. Note the target address, matched rule, and error at the same time.
3. If websites load but all latency tests fail, check the test URL, timeout, and concurrency first. Don't reinstall the client yet.

Step 1: Check your local network and subscription

Rule out sign-in requirements and network changes first

Temporarily turn off the system proxy and TUN, then check that regular websites work with a direct connection. Hotel, campus, and public Wi-Fi may require you to sign in through a web page first. Until you do, node connections may all fail even if the Wi-Fi icon shows a connection. Try a phone hotspot for comparison: keep the configuration, node, and target the same, and change only the network. If the hotspot works but the original network doesn't, check its DNS, outbound restrictions, or router.

A successful subscription update doesn't mean the service is still available

• Account status: Check the expiration date, remaining data, and device or concurrent-connection limits on your provider's site. Pay attention to the time zone shown there.
• Update result: Check the subscription update history and node count. HTTP 401 or 403 often indicates an authentication issue or access restriction; 429 may mean the request was rate-limited. Check the server's message for the specific cause.
• Configuration loaded: A successful download only means the file was retrieved. Confirm that the new configuration is active and that the core didn't reject it due to invalid fields.
• Node origins: Nodes in multiple regions may share the same entry domain. If all nodes time out, the shared entry may be down; it doesn't necessarily mean every server failed at once.

If subscription updates require a proxy, a broken connection can cause the update to fail repeatedly. Update from a network supported by your provider, or use its local configuration import method. Subscription URLs often contain credentials; don't paste them into public speed-test sites, conversion services, or forums.

Step 2: Sync your system clock and check handshake requirements

TLS certificate validity checks and authentication mechanisms used by some protocols depend on the system clock. An incorrect clock after sleep or a manually set wrong date can make multiple nodes fail at once. Don't check only the hour and minute in the taskbar: verify the date, year, time zone, and automatic sync status too.

• Windows 11: Go to Settings → Time & language → Date & time. Turn on “Set time automatically,” check the time zone, and select “Sync now.”
• macOS: Go to System Settings → General → Date & Time and enable automatic date and time. The wording may vary slightly between system versions.
• Linux: Run timedatectl status to check clock synchronization. On systems using systemd, enable a time-sync service according to your system's administration practices.

For example, if the log shows x509: certificate has expired or is not yet valid, compare the system clock with a trusted time source first. If the same error persists after syncing the clock, check the server certificate next. Don't hide the problem by disabling certificate verification; skip-cert-verify won't fix a wrong password, unreachable port, or mismatched protocol settings.

Step 3: Check whether the core starts and whether a port is in use

Seeing nodes in the list doesn't mean the proxy core is running properly. The GUI may have loaded the configuration while the core exited on startup because a port was already in use. Search the client logs for startup failures, configuration parsing errors, and address already in use, then check which ports are actually listening.

The examples below use 7890 as a local mixed proxy port. This is only an example, not a default for every client. Check the client port settings or active configuration for mixed-port, port, and socks-port. The control interface may use 9090; it's for managing the core and shouldn't be entered as the browser's HTTP proxy port.

Find what's using port 7890

On Windows, use PowerShell to check the listening address and process ID, then look up the corresponding program:

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Id 1234

The 1234 in the second command is just an example. Replace it with the process ID returned by the first command. On macOS and common Linux distributions, you can use:

lsof -nP -iTCP:7890 -sTCP:LISTEN

If another proxy client owns the port, exit that application normally before starting the current client. Don't force-quit an unfamiliar system process. If you switch to 7891, update the manual proxy settings in your apps too. For everyday use on your own device, loopback listening is enough; there's no need to enable LAN access just to troubleshoot.

Step 4: Use an explicit proxy request to narrow down the issue

Temporarily turn off TUN and select one node manually. Sending a request to a specific local proxy address avoids uncertainty about whether an app follows the system proxy, but the request is still subject to the core's current mode and rules. Open the Connections panel while testing and make sure the traffic isn't routed to DIRECT.

curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 5 --max-time 15 \
  --output /dev/null --write-out "%{http_code}\n" \
  https://cp.cloudflare.com/generate_204

This command works in a macOS or Linux shell. In Windows PowerShell, use the command below to explicitly call curl.exe:

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 --output NUL --write-out "%{http_code}\n" https://cp.cloudflare.com/generate_204

• Returns 204: This confirms the request reached the target through the local proxy this time. Check the Connections panel to confirm the actual policy and egress route.
• Connection refused immediately: Check the local port, listening address, and core process first. If the local connection was established, the refusal may have come from a later remote connection; check the logs to pinpoint it.
• Times out while waiting: Check the remote connection, DNS, handshake, and test target. Don't use curl's result alone to diagnose a specific protocol issue.

A particular route may also restrict the test URL, so cross-check with another known-working HTTPS target. If the test timeout is set to 1,000 ms, temporarily raise it to 5,000 ms and test twice in sequence. These are troubleshooting examples, not universal recommendations. A longer timeout only means waiting longer; it won't fix authentication errors or a failed entry point.

Step 5: Use log keywords to pinpoint DNS, authentication, and protocol issues

Temporarily set the log level to info; switch to debug only if you need more detail. Reproduce the issue once and filter the logs by time. Restore the original level when you're done to avoid generating excessive logs. Before sharing logs, remove subscription URLs, passwords, tokens, and other account information.

Resolving the entry point is not the same as resolving the target

The node server's domain must resolve correctly before the core can connect to its entry point. The domain of a website you visit in your browser is resolved later. These lookups may use different resolution paths. If the node entry domain can't be resolved, repeatedly changing website routing rules usually won't help. You can query your entry domain with nslookup, but a successful system lookup doesn't prove the core's DNS configuration is working.

mihomo DNS settings may involve nameserver, default-nameserver, and proxy-server-nameserver. Check the documentation for the core you're using to see which settings it supports. Don't force all DNS requests through a proxy that isn't connected yet, creating a loop between name resolution and connectivity.

Check related protocol settings together

Don't assume older Clash cores support the same features as mihomo. If your configuration uses protocols such as Hysteria2, confirm that the running core supports them. UDP-based transport may also be restricted on your current network. If TCP-based nodes work but these nodes all fail, testing on a hotspot is more useful than blindly changing the password. Check the server port, authentication, SNI, and transport settings against the original subscription; configuration converters may omit fields.

Step 6: Once basic proxying works, troubleshoot TUN and rules

If an explicit proxy request succeeds but connections fail only when TUN is enabled, investigate routing, permissions, DNS interception, and other virtual network adapters. TUN intercepts system network traffic; it doesn't make nodes more reachable. It can't restore an expired account or fix an incorrect server port.

1. Quit other VPNs, proxy clients, and software that may change routes to prevent multiple traffic interception components from running at once.
2. Check the service mode or system permissions required by your client, then enable TUN on its own and keep the connection logs open.
3. Check whether DNS requests are being intercepted correctly and whether connections to the proxy server are mistakenly sent back into the tunnel.
4. If only some HTTPS sites hang when using TUN, then look into issues such as path MTU. Record the original value and test one change at a time; don't make MTU changes your first fix for all timeouts.

In rule mode, confirm which proxy group is actually selected. A select group may point to another automatic group that's still using old test results. Select a specific node directly and check the connection chain to avoid ambiguity from nested groups. You can temporarily switch to global mode for comparison, but restore the original mode afterward so other apps' traffic routes aren't changed.

Record findings and restore settings in order

If the issue persists, reporting “all nodes time out” isn't enough to diagnose it. Gather the details below to help your provider check the entry point and help client maintainers determine whether the issue involves the core or system traffic interception.

• Operating system and client versions, plus the actual core name and version. Find these in the local About screen or startup logs.
• When the issue started and whether you had just updated the subscription, upgraded the system, switched networks, or enabled TUN.
• How the same node performs on the original network versus a phone hotspot, and what happens with an explicit proxy request.
• A redacted log excerpt with context before and after the error. Include the target request time, whether TUN was enabled, and the proxy group that actually handled the request.

To restore service, first make a request through one node using an explicit proxy, then verify the system proxy, and finally enable TUN and automatic proxy groups only if needed. Work through the checks in this order—local network and account → system time → core and ports → DNS and handshake → traffic interception and rules—to distinguish entry-point failures, misleading test results, and local configuration issues. To choose a compatible client, visit the Clash client download center. For import instructions and basic setup, see the user guide.