Troubleshooting 8 min read

Clash Node Timeout Troubleshooting: Checking Subscriptions, Ports, and Protocols

All-node timeouts rarely mean dead nodes. Check subscriptions, port conflicts, system proxy, protocol/core compatibility and DNS pollution to find the cause.

Narrow Down the Problem Scope First

When the latency column shows "timeout" across the board, the first instinct is often to suspect dead nodes or an expired subscription, but that's just one of many possible causes. More commonly, the local environment has an issue: a port is occupied, the system proxy isn't active, the core version doesn't match the protocol, or DNS resolution is being tampered with. These issues can make the entire latency test fail at once, looking exactly like "all nodes are down" while having nothing to do with the nodes themselves.

Start with a quick check: open the system browser and try visiting a site outside your country directly. If it fails to load with no sign of proxy traffic, the connection layer likely isn't working. If the client shows "Connected" but the page still spins, move on to the layer-by-layer checks below. Don't jump straight to swapping subscriptions or deleting nodes — that only turns a simple problem into a complicated one.

Layer 1: Subscription Validity

An expired or dead subscription link is the layer most often overlooked, especially with free or unrenewed subscriptions. Here's how to check directly:

  • Click "Update Subscription" manually in the client and watch whether the node count changes or an error appears.
  • Paste the subscription URL directly into a browser address bar. If it returns empty text, a 404, or an error JSON, the server-side subscription has failed — this isn't a local configuration issue.
  • Check the subscription's expiration date and remaining traffic. Many panels pack this info into the Subscription-Userinfo response header, which most clients display somewhere in the UI.

If the subscription really has expired, nothing further down the chain will fix it — contacting the provider or switching to a valid subscription link is the only way forward. If the subscription is fine but nodes still time out, move to the next layer.

Layer 2: Local Port Conflicts and Listening Status

The Clash core listens on a set of local ports: the HTTP proxy port, the SOCKS5 port, and an external control port for panel communication (default 9090). If another program is occupying these ports, the core may fail to start or the proxy function may work only partially — the node looks online, but traffic never actually passes through it.

How to check:

  1. Look up the port numbers in the client's settings — typically the HTTP port (commonly 7890) and the mixed port (commonly 7891).
  2. Use a system command to check whether the port is already in use: netstat -ano | findstr 7890 on Windows, lsof -i:7890 on macOS/Linux.
  3. If it's occupied, close the conflicting program, or change the port number in the client settings to an unused range, then restart the client and try again.

Running two proxy tools on the same machine is a common cause — for example, another proxy tool's process didn't fully exit and is still holding the port in the background.

Layer 3: System Proxy and TUN Mode Switches

A properly listening port doesn't guarantee traffic actually routes through Clash. System-level proxy switches matter just as much:

  • System Proxy mode: the client automatically writes system HTTP/HTTPS proxy settings. If this switch gets turned off by mistake, browsers and most apps bypass Clash entirely and go out through the raw network. Check whether the "System Proxy" toggle in the client is actually on.
  • TUN mode: TUN mode uses a virtual network adapter to intercept all traffic at the system network layer, independent of any single app's proxy settings — useful for apps that ignore the system proxy. On some systems, enabling TUN mode requires extra authorization (network extension permission, admin rights); if that authorization is denied, TUN can silently fail to start without a clear warning in the UI.
  • Some apps ignore the system proxy: command-line tools and certain game clients don't read system proxy settings at all. These cases require TUN mode, or a manual proxy configuration specific to that app.
Tip

To verify traffic is actually going through Clash, open the client's Connections panel and check whether a matching connection entry shows up while browsing. If nothing appears there, traffic never entered Clash — the problem is at this layer, not the node.

Layer 4: Protocol and Core Compatibility

The original Clash core only supports a limited set of proxy protocols, while Clash Meta (i.e. mihomo) extends support to Hysteria, Hysteria2, TUIC, some VMess variants, and more. If a subscription contains a protocol type the original core doesn't recognize, the corresponding nodes get flagged as unavailable or consistently time out on latency tests — that's not a network issue, it's a core capability gap.

How to check:

  1. Confirm which core version the client uses underneath. Most modern clients (Clash Verge Rev, FlClash, Clash Plus) default to the Meta/mihomo core already.
  2. Check the protocol field in the subscription's node list. If keywords like hysteria2 or tuic show up while the client is still on the legacy original Clash core, switch to a client that supports these protocols.
  3. The protocol itself may also depend on network conditions — QUIC-based protocols, for example, are throttled or blocked outright on some networks, so nodes using that protocol time out consistently while other protocols work fine. In that case, switch to nodes using a different protocol rather than continuing to check local settings.

Layer 5: DNS Pollution and Resolution Failures

Even if the first four layers check out fine, a DNS resolution issue can still make nodes appear to time out. The reason: before testing speed or establishing a connection, the client has to resolve the node's domain name into an IP address. If this step gets tampered with, the result is a wrong IP or no result at all, and the connection naturally fails afterward.

Common fixes:

  • Enable enhanced-mode: fake-ip in the config file's dns field, and configure a trusted upstream DNS (such as an encrypted DoH/DoT server), avoiding the machine's default DNS, which may be compromised.
  • Check whether the nameserver list includes your ISP's default DNS — if so, replace it with an independent encrypted resolver.
  • With TUN mode on, DNS requests get intercepted too — if resolution is still off, check whether the dns-hijack setting in the TUN config block is correctly capturing port 53 traffic.
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fake-ip-range: 198.18.0.1/16

After setting up upstream DNS, restart the core to apply it, then run the latency test again to see if the numbers return to normal.

Summary: The Five-Layer Check Order

In short: first confirm the subscription itself can actually be fetched, then check whether ports are free and whether System Proxy or TUN really took over traffic, then check whether the protocol is supported by the current core, and finally check whether DNS resolution is being tampered with. These five layers move from "external data source" down to "local network stack" — a failure at any layer produces the same surface symptom of "everything times out," but the fix is completely different at each level. Checking in order keeps you from wasting time tweaking the wrong part of the config.

If nodes still time out after checking all five layers, try a different network (like a phone hotspot) to isolate whether the issue is with the local machine or the network environment it's on, narrowing the problem down further.

Download Client