Clash Node Timeout: Seven Steps to Troubleshoot in Order

A node list full of timeout values, a “cannot connect to proxy server” error, or a browser that just keeps spinning — users call all three “node timeout”, but the causes are completely different. Most people start by switching nodes one after another, and after trying dozens they still see timeout, because the node was never the problem.

The seven steps below run from inside the client out to the network link. Each one gives you a check you can run right away and a clear pass/fail criterion. Work through them in order and don't skip ahead — the result of one step decides whether you need the next.

Tell the four kinds of timeout apart first

Classify the problem before you start. A timeout looks the same on screen, but which stage it happens at narrows the search area in advance.

Symptom	Most likely cause	Check first
Every node times out in the latency test	Expired subscription, DNS resolution failure, local port conflict	Steps 1 → 2 → 3
Only a few nodes time out	That node is offline or temporarily unavailable	Step 1
Latency shows a value, but the browser can't open pages	System proxy not applied, rule matched REJECT	Steps 4 → 5
One app times out, others work fine	The app ignores the system proxy, or split routing doesn't cover it	Steps 4 → 5

The distinction is simple: the latency test uses the kernel's own probe path, while the browser goes through the system proxy or the TUN adapter. If the test fails, the problem sits between the kernel and the node. If the test passes but the browser fails, the problem is in traffic capture or rule routing.

Step 1: Is the subscription and node data up to date?

Subscription links have an expiry date and a traffic cap. Once they run out, the client usually shows no error at all — every latency in the node list simply turns into timeout. So the first move is always to refresh the subscription manually, not to switch nodes.

The order to do it in

Open the Subscriptions or Profiles page in your client, find the profile you're using and click Update — not Reload. Reload reads the old local file and the node data stays the same.
After the update, confirm the node count isn't 0 and that the list shows real node names with a latency column.
Open the generated config file and check whether the server field of the nodes under proxies still points to a valid domain or IP. When a provider changes its node domains, the old config stops working entirely.

Verify the subscription URL with one command

curl -sI -o /dev/null -w '%{http_code}\n' "your subscription URL"

A 200 response means the URL is reachable; 403, 404 or 410 means the subscription URL has expired or needs to be reissued. A 200 with an empty config body usually means the traffic quota is used up.

A subscription that downloads is not a subscription that works

Some providers still return a config file with only the basic fields once the quota is used up. The client loads it normally and the nodes appear, but every connection times out. In that case, check the remaining traffic and expiry date in the provider's dashboard.

Step 2: DNS resolution and node domains

A node domain that fails to resolve is a frequent cause of timeout, and it's easy to misread as a dead node. The Clash kernel resolves node domains through its own dns section, which is configured separately from system DNS — changing system DNS doesn't necessarily affect the kernel.

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  proxy-server-nameserver:      # mihomo only: used when resolving node domains
    - https://1.1.1.1/dns-query

proxy-server-nameserver is a field added by mihomo (Clash Meta). It sends node-domain lookups to a trusted DNS server, so a poisoned answer from a mainland China resolver can't cause the TCP handshake to time out. The original Clash kernel has no such field; there you can only use nameserver-policy to assign a server per node domain.

How to verify

Run nslookup node-domain and nslookup node-domain 1.1.1.1. If the two results differ a lot, DNS poisoning is likely.
If the kernel log shows [DNS] resolve xxx failed, or keeps retrying the same domain, that confirms a resolution problem.
In fake-ip mode, a destination address of 198.18.x.x in the connections list is normal, not a fault.

Step 3: Port conflicts and local listeners

The kernel listens on 7890 (mixed-port, HTTP and SOCKS combined), 7892 (redir-port) and 7893 (tproxy-port) by default, and the control API defaults to 127.0.0.1:9090. If any of these ports is taken, the kernel may fail to start or start only partially, while some client UIs still show Running.

Commands to check port usage

Windows: netstat -ano | findstr :7890, then look up the PID in Task Manager to see which process it is.
macOS：lsof -i :7890
Linux：ss -lntp | grep 7890

Two ways to fix it

Kill the process holding the port and restart the kernel. The usual culprits are a kernel process that didn't exit cleanly last time, another proxy app, or a dev tool that listens on local ports.
Change mixed-port in the config (to 7897, for example), and change the proxy port in the system proxy, browser extensions and command-line tools to match.

Changing only the config and not the system proxy creates a combined failure

The kernel listens on 7897 while the system proxy still points at 7890. The result: latency tests pass but every browser request times out. It looks like a node problem, but it's a port mismatch.

Step 4: Is the system proxy or TUN actually capturing traffic?

A running kernel does not mean traffic is captured. System proxy and TUN are two different capture methods — first confirm which one you're using.

Where to check the system proxy

Windows: Settings → Network & Internet → Proxy. Confirm that “Use a proxy server” is on, the address is 127.0.0.1, and the port matches mixed-port in your config.
macOS: System Settings → Network → your active network service → Details → Proxies. Confirm both HTTP and HTTPS are checked and point to the same port.
Linux: on GNOME, Settings → Network → Network Proxy. Command-line tools in a terminal need the http_proxy environment variable set separately.

Where to check TUN mode

TUN requires administrator or root privileges, and most clients get them by installing a system service (Service Mode in Clash Verge Rev, Service Mode in Clash for Windows). Once it's enabled, confirm from the routing table:

Linux / macOS: ip route should list the TUN adapter and a route for 198.18.0.0/16.
Windows: route print should show a route for the TUN adapter.

One command to test the whole path

curl -x http://127.0.0.1:7890 -o /dev/null -s -w '%{http_code} %{time_total}s\n' https://www.gstatic.com/generate_204

A 204 response within a few hundred milliseconds means the kernel, node and rules are all working — the problem is in the system proxy settings or a specific app.
A 000 response or a long hang means the kernel side never got through. Go back to Step 1.

Aspect	System proxy	TUN mode
Scope	Apps that read system proxy settings	All TCP / UDP traffic
Privileges required	Any normal user	Administrator / root, or a system service
DNS handling	Usually still uses system DNS	Handled by the kernel's `dns` section
Typical problem	Apps that ignore the system proxy, port mismatch	Service not installed, route not written

Step 5: Rule matching and routing results

Rules match from top to bottom and short-circuit: the first rule that matches decides where the connection goes. A wrong rule or an out-of-date rule set also shows up as a timeout.

rules:
  - DOMAIN-SUFFIX,example.com,REJECT
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

Three common mistakes

MATCH in the middle: it matches all traffic, so any rule below it never runs.
IP-CIDR without no-resolve: every connection triggers a DNS lookup first, and a slow or failed lookup shows up as an overall timeout.
The destination domain is caught by REJECT or falls through to DIRECT, while the direct connection itself is blocked by the current network.

How to see which rule matched

Open the Connections page in the Dashboard to see the “Rule” and “Proxy Chain” columns for each connection. The kernel log also prints lines such as [TCP] 1.2.3.4:443 → match GEOIP,CN => DIRECT. If a connection matches REJECT, the browser just hangs with no response instead of failing right away.

Step 6: Kernel logs and how latency is measured

The log level defaults to info. When chasing a timeout, set it to debug, reproduce the problem once, and see where the log stops.

log-level: debug
external-controller: 127.0.0.1:9090
unified-delay: true
tcp-concurrent: true

unified-delay: true: latency is measured over the full handshake, which is closer to real-world experience and makes it easier to spot which kind of node is timing out.
tcp-concurrent: true: probes several IPs for the same domain at once, so one unreachable IP doesn't cause an overall timeout.
external-controller: the Dashboard endpoint. Once configured, you can open the local panel in a browser to watch live logs and the connection list.

Four key log lines

Log line	Meaning	Back to step
`dial tcp 1.2.3.4:443: i/o timeout`	Handshake between kernel and node failed	Steps 1–3
`[DNS] resolve xxx failed`	Node domain failed to resolve	Step 2
No response after `match GEOIP,CN => DIRECT`	It went direct, and the direct connection is blocked by the network	Step 5
`listen tcp 127.0.0.1:7890: bind: address already in use`	Port taken by another process	Step 3

Use one latency test URL everywhere

Set the test URL to https://www.gstatic.com/generate_204. Clients ship with different defaults, so using one URL makes latency numbers comparable across platforms and devices.

Step 7: Network environment and link quality

The first six steps are all on your machine; the last one is in the link. The test is simple: run the same config once on a phone hotspot.

Public Wi-Fi, campus networks and corporate networks often block outbound ports or interfere with SNI. If the same config works on a hotspot but every node times out on the current network, the restriction is almost certainly on the network side.
System clock drift: protocols such as VMess rely on timestamps, and a drift of more than 90 seconds makes the handshake fail outright — again showing up as timeout. On Linux / macOS compare against date -u; on Windows resync with w32tm /resync.
IPv6 preference: when a node domain has both A and AAAA records and local IPv6 is unreachable, some clients try IPv6 first and fall back, which shows up as a first-packet timeout. Add ipv6: false to the config to test this.
MTU and router: some PPPoE setups need the TUN MTU lowered from 9000 to 1500 or less, otherwise large packets are dropped and you get pages that load while video and downloads stall.

Seven-step quick reference

Order	Step	How to check	Pass criterion
1	Subscription refresh	`curl -sI "your subscription URL"`	Returns 200 and the node count is not 0
2	DNS resolution	`nslookup node-domain 1.1.1.1`	Matches the default resolution result
3	Port conflicts	`netstat -ano \| findstr :7890`	No other process is using the port
4	System proxy / TUN	`curl -x http://127.0.0.1:7890 …`	Returns 204
5	Rule matching	Connections page in the Dashboard	Matched rule and proxy are what you expect
6	Kernel log	`log-level: debug`	No dial timeout or DNS failure entries
7	Network environment	Retest on a phone hotspot	Works normally on the hotspot

Three things not to do while troubleshooting

Don't change config and test at the same time. Change one item, save, restart the kernel, then reproduce — otherwise you can't tell which change did the work.
Don't switch nodes instead of diagnosing. If every node times out, the problem is in the client or the local link, and switching nodes won't change the result.
Don't edit the config file generated from your subscription. The next subscription update overwrites your changes; put customizations in the client's extended config or a Merge override.

Work through these seven steps and most timeouts land on one specific spot: subscription, DNS, ports, capture method, rules, logs or network environment. Locate first, then change — far faster than trying nodes one by one.