Clash Node Timeout: Checklist for Subscription, Ports, and Protocol Params

Node timeouts are the most common failure you'll hit with Clash and the mihomo core, but the root cause is rarely the same twice. The same red exclamation mark or timeout message can point to an expired subscription, an inaccurate latency test, a wrong port or protocol setting, a clock drift, or a local firewall blocking the handshake. Before you start poking at configs, sort the symptom into a category first — it saves you from a lot of guesswork.

B-01First, figure out: all nodes timing out, or just some?

Open your node list and check how the timeouts are distributed — this tells you which direction to dig in next.

• All nodes timing out: usually points to a local network issue, a fully expired subscription, a system clock drift, or a security app/firewall blocking everything — not a problem with any single node.
• Only a few nodes timing out, others fine: most likely that specific server is down, its protocol settings don't match the server, or the relay route it uses is unstable.
• Latency flips between good and bad: usually an inaccurate testing method, or the server throttling during peak hours — not a fully dead node.

B-02Check subscription validity

If every node is timing out, check whether the subscription itself is still valid first — this is the most overlooked step but also the most common culprit.

1. Open the subscription management page in your client and check the expiration date and remaining data. Once a plan runs out of data or expires, most providers reject all connections outright, which shows up as every node timing out at once.
2. Tap "Update Subscription" manually and watch whether the node count changes. If it drops to 0 or the list comes back empty, the subscription link has expired or been taken down on the server side.
3. Open the subscription URL directly in a browser (bypassing any client-specific request headers) and confirm it returns valid Base64 or YAML text — not an error page or a blank response. A 403, 404, or empty reply means the problem is on the provider's end, not your client config.
4. Check whether the subscription URL includes an expiry parameter or a temporary auth token — some providers' links expire and need to be regenerated from the dashboard.

B-03Verify your latency testing method

The latency number shown in the client interface depends entirely on how it's measured. A flawed testing method can flag a perfectly working node as timed out.

• Test URL choice: most clients default to http://www.gstatic.com/generate_204 or a similar connectivity check endpoint. If that specific domain is flaky on your local network, the latency reading will be off — try switching to a different test URL in settings and compare.
• Test protocol mismatch: a plain TCP latency check doesn't use the same handshake as your actual proxy protocol (Shadowsocks, VMess, Trojan, Hysteria2, etc.). A clean TCP result doesn't guarantee the proxy protocol itself can complete a handshake — this is why pages can "time out" even though the latency test looks fine.
• Interference from batch testing: testing every node at once means they're all fighting over the same local bandwidth and connection slots, which inflates results for nodes tested later in the batch. Test the suspect node on its own before drawing conclusions.

curl -x http://127.0.0.1:7890 https://www.gstatic.com/generate_204 -I -m 5

This command sends a connectivity request through your local proxy port. A HTTP/1.1 204 response means the selected node and local proxy chain are both fine, and the timeout warning is more likely a quirk of the client's own testing logic. If the command itself hangs or errors out, the problem is really in the proxy chain — move on to checking ports and protocol settings.

B-04Check port and protocol settings

If one node keeps timing out and you've already ruled out the subscription and testing method, it's almost always a mismatch between that node's connection settings and the server config.

1. Double-check the port number: open the node's details and confirm the port matches exactly what the provider's dashboard shows. A digit added or dropped during copy-paste on a manual setup or self-hosted node is the most common rookie mistake.
2. Double-check the protocol and encryption: for Shadowsocks, verify the cipher (e.g. aes-256-gcm, chacha20-ietf-poly1305) matches the server; for VMess, check the UUID, AlterId (usually 0 on newer setups), and transport (TCP/WS/gRPC); for Trojan and Hysteria2, check that SNI and certificate verification options match the server config. A single wrong value here causes a failed handshake that shows up as a timeout.
3. Double-check transport-layer settings: if the node uses WebSocket or gRPC, also check that Path and Host headers match the server. These fields sometimes get truncated or mis-escaped when a subscription link is parsed manually.
4. Double-check TLS/SNI settings: for nodes with TLS enabled, a wrong SNI — or one pointing to a domain that's blocked or unregistered — will also fail the handshake and time out, with symptoms nearly identical to a wrong port. You'll need to check the config file line by line.

B-05Check system clock and local firewall

If none of the steps above turn anything up but you're still seeing timeouts across the board, two system-level factors are easy to overlook.

• System clock drift: most encrypted proxy protocols (especially Shadowsocks AEAD ciphers and VMess timestamp verification) rely on the client and server clocks being roughly in sync. If your local clock drifts too far, the server will reject the handshake outright, which shows up as every node timing out simultaneously. Check whether "sync time automatically" is enabled and that your time zone is set correctly.
• Local firewall or security software: some security apps or the built-in OS firewall can block or throttle the local port Clash listens on (e.g. the 7890 mixed port, or the TUN mode virtual adapter). Temporarily disable your security software's network protection as a test — if things work again, add specific allow rules for it instead of leaving protection off long-term.
• TUN mode driver permissions: if you're using TUN mode to capture system-wide traffic, the virtual adapter driver needs admin/root privileges to be created properly. Without enough permissions, traffic may quietly fall back to the system proxy path instead of TUN, causing certain apps to misbehave — switch back to system proxy mode as a comparison test when troubleshooting this.
• Router or upstream network restrictions: some home ISPs or corporate networks throttle or block specific port ranges. If you've confirmed everything on your end is correct, try a different network (like a phone hotspot) to cross-check.

B-06Checklist summary

Laid out as a table so you can work through it step by step without skipping or repeating checks.

Working through the checklist above resolves most timeout issues. If it turns out the server itself is down or throttling, switching providers or contacting support is the only real fix — no client-side config change can solve a server-side problem.