Clash Node Timeout or All Nodes Failing? Troubleshooting Checklist

First, identify whether the timeout occurs during a speed test or when you browse

Open the client's Proxy page and note the current policy group and selected node. Then check the Logs page for a failed request. Depending on the client, these pages may be called Proxy Groups and Runtime Logs. Use the labels in your app. Don't reinstall or change DNS, rules, and ports all at once.

A node speed test typically asks the core to request a test URL through the selected node, then calculates latency according to the client's settings. A timeout only means the test did not finish within the allotted time. An unavailable test URL, failed DNS lookup, or unsuccessful node handshake can all produce the same result.

• Speed test times out, but websites load: Check the test URL and timeout setting first. Don't delete the node right away.
• Latency is shown, but one app won't load: Check per-app proxy settings, rule matching, and the app's own network settings first.
• All nodes time out and all proxied requests fail: Check shared dependencies in order. Start with your network, then check the subscription and DNS.
• Only one node fails: Compare it with a node on a different server before changing the entire configuration.

Step 1: Stop the proxy and check your network and VPN interface

Make sure your phone can connect to the internet directly

1. Stop the connection from the client's home screen and confirm the VPN icon disappears from the Android status bar.
2. Open a website you can normally access directly. If public Wi-Fi shows a sign-in page, complete the login before starting the client.
3. Turn off Wi-Fi and test the same node over mobile data. Then switch back to Wi-Fi without changing any other settings.
4. If the node fails only on a particular Wi-Fi network, note the difference. Don't assume all nodes are down.

Android's VpnService lets apps create a local VPN interface. In typical personal-use setups, only one VPN service can be active per user. Another VPN, firewall, or filtering app that uses the VPN interface may displace Clash. Stop those services, then reconnect.

Check for system settings that block direct connections

On Android, go to Settings → Network & internet → VPN, then tap the settings icon next to your client. Check Always-on VPN and Block connections without VPN. Some devices put these options under Connection & sharing. If connection blocking is enabled, losing internet access after stopping the client may be the intended system behavior, not a Wi-Fi fault. To test a direct connection, you can turn the option off temporarily. Traffic may bypass the proxy during the test; restore the setting afterward if needed.

If the connection drops only after the screen locks, unlock the phone and restart the service. Then go to Settings → Apps → your client → Battery and check for background restrictions. Track this separately from persistent node handshake timeouts.

Step 2: Confirm the subscription updated and its configuration is active

Open the Configuration page, manually update the current subscription, and check the update time and any error message. A subscription provides node and rule configuration; an update failure is not the same as a proxy connection failure. An older configuration may still work, and a successful update doesn't mean every server in the subscription is reachable.

1. Make sure the active configuration is the one you just updated, not an older imported file with the same name.
2. Sign in to your subscription provider's account page and check the expiration date, remaining data, and device or connection limits.
3. Check the update error: HTTP 401 or 403 usually points to authorization or access restrictions. 404 means the requested URL wasn't found. Check the response details to determine the exact cause.
4. If you see a YAML parsing error or an unsupported proxy type, fix the configuration loading issue before testing nodes.

YAML is a common text format for Clash configurations, and indentation affects how the structure is parsed. Don't use a subscription URL as a node server address or save a returned sign-in page as a configuration. If the app says the file downloaded but then reports a parsing error, it likely didn't receive configuration data the client can use.

Step 3: Distinguish node hostname lookups from destination DNS lookups

DNS translates domain names into IP addresses. A proxied request may first resolve the node server's hostname, then resolve the destination website locally or remotely. A failure at either stage can appear as a connection timeout. Check which hostname the error mentions to see where the failure occurred.

On Android, check system settings under Settings → Network & internet → Private DNS. Private DNS usually uses encrypted DNS over TLS; it is separate from DNS over HTTPS in the configuration file. Temporarily set system Private DNS to Automatic for comparison. This does not necessarily reset the client's internal DNS settings.

mihomo is a proxy core compatible with the Clash configuration ecosystem. In its DNS settings, proxy-server-nameserver can specify resolvers for node server hostnames, while default-nameserver is used for bootstrap lookups such as resolving the DNS servers themselves. Whether these fields work depends on the core's actual support, not just the client shell's name. Don't force every DNS request through a proxy that can't connect yet, or you may create a startup dependency loop.

Don't casually replace a node hostname with an IP address you found online. TLS server-name verification, SNI, and CDN or load-balancer routing may all depend on the original hostname. SNI tells the server which hostname is being requested during the handshake. Even if a TCP connection succeeds after switching to an IP, the TLS handshake may still fail.

Step 4: Check the system clock and TLS errors

Go to Settings → System → Date & time and turn on Set time automatically and Set time zone automatically. On some devices, these options are under More settings → Date & time. Confirm the date, year, and time are correct, then restart the connection.

TLS encrypts connections and verifies server identity. Certificates have validity periods, and some proxy protocols are sensitive to clock differences. If the logs show certificate has expired or is not yet valid, check your device's clock first, then check the server certificate. This error alone doesn't prove the phone's clock is wrong.

• x509: certificate signed by unknown authority: The certificate chain may be incomplete, the certificate may be self-signed, or an intermediary device may be intercepting the connection.
• Certificate name mismatch: Check that the node hostname matches the server name required by the provider.
• Certificate errors persist despite a correct clock: Save the logs and ask the provider to check its certificate deployment and endpoint address.

Don't leave skip-cert-verify enabled just to hide an error. Skipping certificate verification weakens server identity checks; it won't fix a blocked port or incorrect protocol parameters.

Step 5: Check the protocol, server port, and core support

Check the protocol, server address, and server port in the node details. Then note the actual core version from the client's About page or core information screen. The Clash client shell and its core have separate version numbers. Importing a configuration doesn't mean the running core supports every protocol and field in it.

Don't confuse the local listening port with the remote server port

• Local port: For example, mixed-port: 7890 in the configuration lets apps on your device connect through an HTTP or SOCKS proxy. 7890 is just a common example; check your active configuration.
• Server port: The port in the node details is used to connect to the remote service. It could be 443 or another port assigned by the provider.
• Management port: external-controller is for the control interface, not a proxy endpoint for browsing websites.

Changing the local port from 7890 to 7891 won't fix a blocked remote server port. If the logs show address already in use, check whether another process is using the local port or the service was started twice.

Compare different transport types

Protocols such as Hysteria2 and TUIC rely on UDP. Some networks restrict UDP, causing these nodes to fail while TCP-based nodes still work. Compare with a TCP node explicitly provided by your service, on the same network. Turning off the UDP option in a node configuration doesn't convert the protocol to TCP.

For nodes using WebSocket or gRPC, also check the transport path, Host, or service name. An HTTP 400 or 404, or an unexpected handshake response, may indicate mismatched endpoint parameters or a server-side reverse proxy issue. Get an updated subscription compatible with your current core instead of guessing at individual fields.

Step 6: Check whether traffic reaches the intended policy group

Open the Connections page, then visit the target website in your browser. Check whether the request appears and note its rule, policy group, and final node. Rule mode selects direct or proxy access according to the configuration. Selecting a node only affects its policy group; it doesn't override rules that route traffic directly.

1. If the request doesn't appear, check whether per-app proxy settings exclude the browser and confirm the VPN service is running.
2. If the request matches DIRECT, check the relevant rule first instead of repeatedly switching nodes in the proxy group.
3. If the request reaches a different policy group, open that group and check what's selected. It may still be set to DIRECT or an old node.
4. Briefly switch to Global mode for comparison and select a specific node. Restore Rule mode after testing so you don't mistake a temporary setting for your final configuration.

Global mode is useful for comparing proxy selection, but it doesn't guarantee that all device traffic is captured. Apps excluded by per-app settings and traffic that never enters the proxy interface won't appear just because you changed modes. Desktop TUN captures traffic through a virtual network interface; Android clients generally receive traffic through VpnService. Neither can fix an unavailable server or invalid credentials.

Desktop check: Test a specific local proxy port

If you also use the same subscription on a computer, you can run the command below in a terminal. This example assumes the computer client's HTTP or mixed port is actually 7890 and the test URL is https://example.com/. The URL itself must also be reachable. This is not a built-in Android test.

curl --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 -I https://example.com/

127.0.0.1 always refers to the device running the command. A command on your computer won't connect to the client on your phone. Allowing other devices to connect also requires LAN listening and access controls, which you shouldn't enable as an extra troubleshooting step. An HTTP response only confirms that this particular test path works; it doesn't prove all apps are using the proxy.

Quick guide to log errors: Find the earliest failure in the connection chain

Temporarily set the log level to info on the Logs page; switch briefly to debug only if you need more detail. Note the time of a request, reproduce the issue, and save the surrounding log lines. Wording varies between cores. Use the table below to guide your investigation, not as a substitute for full context.

For example, if a node hostname lookup fails before a test times out, fix DNS first. Don't treat the final timeout line as the only cause. After troubleshooting, restore your usual log level to avoid retaining excessive access logs.

Still timing out across all nodes? Gather details others can reproduce

If direct access works, the subscription is valid, the clock is correct, and at least two nodes on different servers fail over both Wi-Fi and mobile data, send the evidence to your subscription provider or client maintainer. Nodes that share an entry hostname aren't fully independent server comparisons.

• Environment: Android version, client name and version, and core name and version. Use the details shown in your app.
• Time: Date and exact time of the failure, including your time zone, so it can be compared with server logs.
• Scope: All nodes or one node; speed test failure or actual website failure.
• Network comparison: Results from 3 tests each on Wi-Fi and mobile data, and whether you completed any public Wi-Fi sign-in.
• Logs: The relevant lines around the first error. Redact subscription tokens, authentication details, and personal access domains.
• Checks already performed: Subscription update result, system time, DNS comparison, and protocol type, to avoid repeating tests.

When you're done troubleshooting, restore any temporary changes to the log level, proxy mode, Private DNS, and system VPN blocking settings. Keep the shortest steps that reliably reproduce the issue. That's more useful than layering on more configuration overrides.