Clash Nodes Timing Out? Troubleshoot Failed Tests and DNS

First, distinguish failed speed tests, unreachable nodes, and rules that aren't matching

Don't reinstall the client just because you see a timeout. A failed speed test only means the core couldn't complete a request to the test URL through the selected node within the allotted time. An unreachable test URL, a failed node connection, or a DNS issue can all produce the same timeout. First identify what's failing, then change your settings.

Record the current setup before troubleshooting

1. Note the client version, core name and version, active configuration name, and when the problem occurred.
2. Save a copy of the configuration. Take screenshots of the current proxy mode, proxy group selection, system proxy, and TUN toggle.
3. Choose one node, one test URL, and one website. Change only one setting at a time.
4. Open the client's Logs and Connections pages. The labels may vary between clients; use the options shown in your app.

Speed test results are usually shown in milliseconds: they measure how long that test request took, not download bandwidth. Temporarily raising the timeout from 3,000 to 10,000 ms can show whether the request is simply slow to establish. These values are examples for troubleshooting, not measured performance, and they won't fix an unavailable node.

Step 1: Confirm the subscription is valid and the updated configuration is active

Open the client's Subscription or Configuration page and update manually. Confirm the last-updated time changes, then check that the active configuration is the one you just updated. A new configuration appearing in the list doesn't mean the core has loaded it.

Choose the next step based on the update result

• 401 or 403 response: Check that the subscription URL is complete, the access token hasn't changed, and the subscription account is active. Refer to the server's message for the specific cause.
• 404 response: Check whether the URL path has expired. Copy the address again from the original subscription management page instead of using an old bookmark.
• 200 response, but import fails: Check whether the response is actually a login page or an error page. A successful HTTP request doesn't guarantee that the response contains a usable configuration.
• YAML parsing error: Check indentation, field formatting, and whether the client supports the subscription format. Don't load a single-node link as a complete configuration file.
• Subscription download times out: Check whether the update request depends on the current, nonworking proxy. If the client offers a proxy option for subscription updates, temporarily change how the request is sent and try again.

After updating, check that the node names, node count, and proxy group members match expectations. The server may have replaced node addresses, or local override rules may have filtered out new nodes. If the configuration failed to load, fix that error first rather than repeatedly running speed tests.

Step 2: Check the system clock and rule out basic network problems

Make sure the device can access the internet, then check the system date, time, and automatic synchronization settings. Certificate validation depends on an accurate clock, and some authentication methods are also sensitive to time drift. A different displayed time zone isn't necessarily a problem; what matters is whether the actual system time is correct.

• Windows: Go to Settings → Time & language → Date & time. Check Set time automatically, then select Sync now.
• macOS: Go to System Settings → General → Date & Time and check the option to set the date and time automatically.
• Android: Open Date & time in system settings and enable automatic time. Menu locations vary by device and Android version.

If the logs show certificate has expired or certificate is not yet valid, check your device's clock first, then check the server certificate's validity period. Don't disable certificate verification to bypass the error; that can hide the real issue and weaken connection security.

Switch networks to narrow down where the problem lies

Keep the same node and configuration, then switch your computer from its current network to a mobile hotspot and test again. If it works on the hotspot but not the original network, check the original network's access restrictions, captive portal, and router settings first. If both networks fail, continue checking the device and node. Switching networks can narrow things down, but one test alone can't prove the server is at fault.

Step 3: Check the core, port conflicts, and system proxy

Confirm that the client shows the core as running. An open app window doesn't mean mihomo started successfully. The log message address already in use usually means another process is using the listening address or port. Fix startup errors before testing nodes.

Check the actual listening port

mixed-port provides both HTTP and SOCKS5 proxy access. The example below uses local mixed port 7890. Check the client settings or active configuration for the actual port; this example isn't a default for every client.

# Example configuration snippet, not a complete configuration
mixed-port: 7890
allow-lan: false

Check the listening port in Windows Command Prompt:

netstat -ano | findstr LISTENING | findstr :7890

Check on macOS or Linux systems with the required tools:

lsof -nP -iTCP:7890 -sTCP:LISTEN

If another process is using the port, identify it by its process ID, then close the unneeded app normally or change the port used by Clash. Don't force-quit an unknown system process. After changing the port, update any proxy address you've entered manually in other apps.

Distinguish the local proxy from the remote node

On Windows, use the following command to send a request explicitly through the local HTTP proxy. The test URL is only an example of the command structure; replace it with a known-accessible HTTPS URL for comparison.

curl.exe -I --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://example.com/

On macOS or Linux, change curl.exe at the start of the command to curl. If you immediately get a connection error for 127.0.0.1:7890, check the local listener and port first. If the request reaches the core, use the Connections panel to see which rule and node it ultimately uses. Explicitly setting a proxy confirms only that the request reached the proxy entry point; it doesn't guarantee that the rules selected a remote proxy.

If the explicit proxy test works but your browser doesn't, check the client's System Proxy toggle, the browser's own proxy settings, and whether another network utility is overriding the system proxy. TUN mode also involves service permissions and routing, so avoid repeatedly switching it alongside the system proxy at this stage.

Step 4: Check DNS separately for the node server and destination domain

DNS issues can occur at two different points: resolving the node server's domain to an address, and resolving the website you're trying to visit. If the first lookup fails, the proxy connection may never be established. If the second fails, the node's speed test may work while a particular website remains unavailable.

Check the node server's domain first

Find the node's server field in the active configuration. If it contains a domain name, use nslookup or Resolve-DnsName to check the system's lookup result. Enter the actual server domain in the command; don't paste a subscription URL or a full URL with a path.

• System lookup fails and the client reports a DNS error: Check local DNS and network connectivity first.
• System lookup works but the client can't resolve the domain: Check the DNS upstream and access method used by the core; it may use a different resolution path.
• Encrypted DNS is configured: Confirm that its endpoint is reachable, and remember that the endpoint's domain may also need a bootstrap lookup.
• Using mihomo: Check the proxy-server-nameserver setting in a compatible version. It specifies the DNS upstream used to resolve proxy server domains; check the current core's configuration documentation for support details.

Then check Fake-IP and app caches

In Fake-IP mode, DNS returning a synthetic address can be expected. Common configurations use the 198.18.0.0/16 range, so seeing an address in that range doesn't by itself mean DNS is broken. Check the core's connection logs to confirm that the app's request is being intercepted correctly and the domain mapping is still valid.

A browser's Secure DNS, an app's built-in resolver, and system DNS may use different paths. If only one app is affected, check that app's DNS settings instead of rewriting the entire configuration. For comparison, temporarily disable its custom resolver, record the result, then decide what to use long term.

Change one DNS setting at a time, reload the configuration, then close and reopen the app you're testing. On Windows, ipconfig /flushdns clears the system DNS cache, but it won't automatically clear the browser's own cache or replace the core's cache management. If you switch between Fake-IP and another mode, also account for existing connections and mappings.

Step 5: Check protocol settings and transport requirements one by one

If only a few nodes still fail, focus on those nodes. Update from the subscription source first rather than assembling parameters by hand. The Clash GUI and its core are separate components: seeing a node type in the interface doesn't guarantee that the active core version supports that type or every field it uses.

QUIC-based node transports typically rely on UDP. If the current network blocks UDP, changing the local HTTP proxy port won't fix the remote transport. Try another network or test a different transport offered by the server. A standard TCP port check can't confirm that a UDP-based node works.

Even a successful TCP connection only shows that a connection was made to a listening port. Authentication failures, TLS handshake errors, or a mismatched transport can still make the proxy unusable. Don't treat an open port as proof that the entire protocol is working.

Final verification: Use rules, logs, and real requests to pinpoint the issue

After making a fix, don't rely on the speed test color alone. Open a real website and check the destination domain, matched rule, proxy group, and final node in the Connections panel. In rule mode, a test website may be routed through DIRECT, so being able to open it doesn't prove that the selected proxy node works.

Use logs to identify where the request fails

• connection refused: The destination explicitly refused the connection. Check the address, port, and whether a service is listening.
• i/o timeout: A request didn't complete in time at some stage. Use the surrounding log entries to determine whether the timeout occurred during DNS lookup, connection, or handshake.
• no such host: Check the domain spelling and DNS resolution path first.
• authentication failed: Check the authentication settings and account status; switching DNS again won't help.
• unsupported proxy type: Check the configuration type and core compatibility. Fix the loading issue first.

If you need to temporarily increase the log level, capture one reproducible attempt, then restore the usual level. After troubleshooting, revert temporary changes to the test URL, proxy mode, and app DNS settings. Keep only changes that actually fixed the issue, so diagnostic settings don't become permanent by accident.

Include these details when reporting an issue

Include the client and core versions, operating system, scope of the failure, results of switching networks, time of the error, and relevant redacted log excerpts. Note whether the subscription updates, whether the local port is listening, and whether the request reaches the core. This makes it easier to tell whether the cause is a local setting, DNS resolution, or the node service than a report that just says “all nodes are red.”

In short, troubleshoot in this order: subscription updated and enabled → clock and network working → core running and port available → DNS path working → protocol settings match → real request uses the expected node. Stop at the first repeatable failure and fix it there.