Clash Node Timeout: How to Fix Connection Failures in the Right Order

First, identify the issue: all nodes or only some

Before troubleshooting, stop repeatedly running latency tests. A node timeout is an outcome, not proof that the node is dead. An expired subscription, a broken connection, incorrect system time, DNS problems, port conflicts, or incompatible settings can all appear as a timeout. Confirm the scope first to avoid unnecessary checks.

All nodes time out

If nodes in Hong Kong, Japan, the United States, and other regions from the same subscription all time out at once, check the shared components first. These include subscription status, direct connectivity, whether the Clash core is running, whether the system proxy or TUN is active, and whether the current network restricts the relevant protocol. Dozens of nodes failing simultaneously is usually less likely than a local environment problem.

• After switching to any proxy group, every node shows timeout.
• Latency tests fail uniformly after waiting 5 to 10 seconds.
• The logs repeatedly show network unreachable, DNS resolution failure, or connection refused.
• After closing Clash, ordinary websites also fail to open over a direct connection.

Only some nodes time out

If other nodes in the same subscription still report latency such as 45 ms or 120 ms, the client core, basic network connection, and subscription format are probably working. Focus on the affected nodes: the server may be offline, the port may have changed, protocol settings may have been updated, the route may be blocked by your carrier, or the health-check address may be unreachable from that node.

Step 1: Confirm that the subscription is active and the configuration is up to date

Open the client's subscription or configuration page first. Common entry names include “Subscriptions,” “Profiles,” “Profile Management,” or “Configuration.” Check the current profile's update time, remaining traffic, and expiration date. Menus vary by client; for example, look under “Configuration” → “Subscription Management” or “Profiles” → current profile → “Update.”

1. Make sure the subscription has not expired and that remaining traffic is not 0 GB.
2. Update the subscription manually once and note whether it succeeds or fails.
3. After a successful update, reload the profile instead of continuing to use the old one.
4. Open the proxy group and confirm that the node list has actually refreshed.
5. Do not paste the subscription URL into public speed-test sites or screenshots.

How to tell whether a subscription update failed

An HTTP 401 or 403 during an update usually means the subscription credentials are invalid, the link was reset, or access is restricted by the server. HTTP 404 means the address does not exist. Persistent 5xx responses suggest a temporary server-side problem. If you see connection timeout, check whether the subscription URL is reachable directly, since many clients update profiles through a direct connection by default.

A successful update does not guarantee that the node parameters are valid. Open the profile details and check whether the node count has unexpectedly dropped to 0 or the new profile still references an old provider cache. Configurations using proxy providers may have a structure like this; the actual node list comes from the provider file, not the main profile itself:

proxy-providers:
  provider-main:
    type: http
    url: "subscription URL"
    path: ./providers/provider-main.yaml
    interval: 3600
    health-check:
      enable: true
      interval: 600
      url: https://www.gstatic.com/generate_204

interval: 3600 means an update is attempted every 3,600 seconds; a health check with interval: 600 runs every 600 seconds. Even after the main profile is updated, an unchanged provider cache can keep showing expired nodes. Manually update the proxy provider on the client's provider page, then restart the core.

Step 2: Disable the proxy and verify the direct connection

Clash relies on the current network to connect to proxy servers. If the underlying connection is down, every node will naturally time out. In the client, first disable “System Proxy”; if TUN mode is enabled, temporarily disable TUN as well. Fully close and reopen the browser, then visit a website that normally works over a direct connection.

Run two minimal tests

1. Disable the system proxy and TUN, then open a directly accessible website over the current Wi-Fi.
2. Leave the Clash profile unchanged, switch the computer or phone to a mobile hotspot, and test the same nodes again.

If every node times out on the current Wi-Fi but recovers immediately over a mobile hotspot—for example, latency changes from timeout to 80–250 ms—the problem is in the original network, router, or carrier route, not the Clash configuration. Restart the modem or router, check its internet status and DNS settings, then ask the network administrator whether outbound restrictions are enabled.

On Windows, you can also open a terminal and run basic connectivity tests. These test the local network and DNS, not proxy-node speed:

ping 1.1.1.1
nslookup example.com

A blocked ping does not necessarily mean the network is down. However, if domain resolution fails and websites also cannot open directly in the browser, fix the network first. macOS and Linux use the same commands in Terminal; on some systems, use dig example.com instead of nslookup.

Additional checks for public Wi-Fi

Hotels, airports, and campus networks often require a sign-in page. Wi-Fi may appear connected while a browser login is still required. With the proxy disabled, visit a regular HTTP page and check whether it redirects to the sign-in portal. Until authentication is complete, connections from Clash are often blocked or redirected, which can look like every node is timing out.

Step 3: Correct the system time, then check the core and local ports

Incorrect system time can break the handshake

TLS certificate validation depends on the date and time. A system clock that is off by several minutes or hours can cause subscription requests, WebSocket TLS, gRPC TLS, and other encrypted connections to fail. In Windows, open “Settings” → “Time & language” → “Date & time,” enable automatic time and automatic time zone, then click “Sync now.” On macOS, open “System Settings” → “General” → “Date & Time” and enable automatic settings.

After syncing, fully quit and restart the client. Do not merely switch nodes, because old connections and DNS cache entries may remain in the core process. If the logs show certificate has expired, not yet valid, or handshake failure, prioritize checking the system time and certificate chain.

Confirm that the Clash or mihomo core is running

An open graphical interface does not mean that the core process is healthy. Open “Settings” → “Core” or “Settings” → “Clash Core” and check that its status is running. Clients using the later mihomo core from Clash Meta may show mihomo in the logs and process list. If the core repeatedly fails to start, open the logs and inspect the first error rather than the final retry message.

Check for port conflicts

A common local mixed HTTP and SOCKS port is 7890, while the control port is often 9090. Use the values in the current YAML and client settings as the source of truth. A common configuration looks like this:

mixed-port: 7890
external-controller: 127.0.0.1:9090
allow-lan: false
mode: rule
log-level: info

If another proxy program is already using 7890, Clash may be unable to listen on that port. On Windows, run this in a terminal:

netstat -ano | findstr :7890
netstat -ano | findstr :9090

On macOS or Linux, run:

lsof -nP -iTCP:7890
lsof -nP -iTCP:9090

After finding an old process using the port, quit that proxy program or change mixed port under “Settings” → “Port Settings” to an available port such as 7891. Then update the system proxy to use the new port as well. Changing only the YAML while leaving the system proxy unchanged makes the browser continue connecting to the old 127.0.0.1:7890.

Step 4: Verify node protocol settings and configuration compatibility

Once the subscription, direct connection, and core are confirmed to work, check the node parameters. Do not guess the protocol from the node name. Use the server-provided configuration as the source of truth, focusing on the server address, port, UUID or password, transport, TLS, SNI, ALPN, and Reality parameters.

Parameter differences that commonly cause timeouts

• server and port: The server was migrated, but the old address or port is still in use.
• network: The server uses WebSocket, but the client attempts a direct TCP connection.
• servername or sni: The TLS handshake uses the wrong domain name.
• ws-opts.path: The WebSocket path is missing its leading slash or still contains the old value.
• grpc-opts.grpc-service-name: The gRPC service name does not match the server.
• Reality parameters: public-key, short-id, or servername does not match.
• UDP: UDP is not enabled for the node, but it is being used for requests that depend on UDP.

Older Clash cores may report an error while loading the configuration or skip incompatible nodes when they encounter newer fields. If the configuration includes Reality, Hysteria2, TUIC, or similar protocols, make sure the client uses a mihomo version that supports them. If the version is outdated, update it through “Settings” → “Core” → “Update Core,” then reload the configuration.

If the logs show unsupported proxy type, field not found, or a configuration parse failure, the problem is at the configuration-loading layer and the node connection has not started. Repeated latency tests will not help; fix core compatibility or the subscription format first.

A health-check timeout does not mean every website is unavailable

Client latency tests usually access a specified URL, such as a lightweight page that returns HTTP 204. The test address may be restricted independently by the node's exit, DNS, or current network. Temporarily switch the test URL to another stable HTTPS address for comparison, but do not use a large download URL as a health check, as it increases traffic and test time.

To determine whether a node is truly usable, check three things together: health-check latency, connection results in the logs, and an actual web request. A single 5,000 ms timeout only means that the test did not finish within the limit. Three consecutive timeouts combined with failed real requests point more strongly to a node or route problem.

Step 5: Check the system proxy, TUN, and DNS layers

System proxy mode

System proxy mode mainly handles applications that follow the system proxy settings. Go to “Settings” → “System Proxy,” turn it off and back on once, and verify that the proxy address is 127.0.0.1 and that the port matches mixed port. Browser extensions, other proxy software, and manually configured PAC files can override system settings, so temporarily disable these extra entry points while troubleshooting.

If node tests work but only one application cannot connect, the node is usually not the problem. Check whether the application reads the system proxy or specifies its own proxy port. Verify with a browser first, then compare the results with the affected application.

TUN mode

TUN mode uses a virtual network interface to handle more traffic and usually requires administrator privileges. When activation fails, client logs may show errors related to interface, route, permission, or device. On Windows, launch the client with administrator privileges; on macOS, approve the network extension or VPN configuration the first time it is enabled. If another VPN is active, quit it completely first to avoid routing-table and virtual-adapter conflicts.

Troubleshoot TUN with a binary approach: disable TUN and enable only the system proxy. If the browser works again, the node itself is usable and the problem is in TUN permissions, routing, or DNS. If both modes time out, continue checking the node and route layers.

How to identify DNS problems

If node latency is normal but domains will not open while a known IP responds directly, check DNS. Common mihomo configuration fields include dns.enable, nameserver, fallback, and fake-ip. Do not change every DNS setting at once without understanding the original configuration.

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

Port 1053 must also be available. If you use TUN and fake-ip, retest after disabling TUN to avoid interference from stale routes and cache. On Windows, run ipconfig /flushdns to clear the system DNS cache; on macOS, retest after restarting the network or system. Clearing the cache is only a supporting step and cannot fix an incorrect upstream DNS configuration.

Step 6: Switch nodes last and confirm the conclusion with logs

Only move to node switching after all shared components above are working. Choose 2 or 3 different nodes in the same region first, test each three times, and wait about 10 seconds between tests. Do not test dozens of nodes at once: concurrent health checks may trigger network throttling and make the logs harder to read.

1. Select node A, test its latency, and open an actual webpage.
2. Select node B in the same region and repeat the same steps.
3. Switch to node C in another region to determine whether the issue is regional routing.
4. Switch to a mobile hotspot and keep one comparison set from the different network.

If nodes A and B time out on home broadband but work over a mobile hotspot, the likely cause is the current carrier route. If the same node times out on both networks while other nodes in the subscription work, the likely cause is the node server or port. If every region times out on both networks, return to the subscription and protocol settings layers for another review.

Keywords to look for in the logs

• i/o timeout: The connection or read/write operation did not finish within the time limit.
• connection refused: The destination is reachable, but the port refused the connection.
• network is unreachable: The local route or network interface cannot reach the destination.
• no such host: Domain name resolution failed.
• TLS handshake timeout: The TLS handshake timed out; check the route, SNI, system time, and server.
• authentication failed: Authentication parameters do not match or the credentials are no longer valid.

Keep the log level at info first. Switch briefly to debug only when the information is insufficient, reproduce the issue once, then switch it back. Before sharing logs, remove subscription URLs, UUIDs, passwords, tokens, server credentials, and personal network information.

Common misdiagnoses and the fastest path to a fix

Misdiagnosis 1: Reinstalling as soon as you see a timeout

Reinstalling only resets client files; it cannot fix an expired subscription, an offline server, a carrier route problem, or an incorrect system clock. It may also erase useful logs and make the issue harder to locate. Export any needed configuration first, then complete the basic layered checks.

Misdiagnosis 2: Assuming a lower latency number guarantees a connection

A latency test reflects only a specific test request. A 40 ms health check does not guarantee that the target website is reachable or that the rules send the request to that node. When a webpage fails, open the connection log and confirm which rule matched the domain, which proxy group handled it, and which node was ultimately selected.

Misdiagnosis 3: Switching proxy groups without confirming the actual selection

In rule mode, a request is matched against a rule before entering the assigned proxy group. You may manually switch a group named “Node Selection,” while the target domain actually matches another group named “Auto Select.” The logs should show rule results such as DOMAIN-SUFFIX or MATCH. You can temporarily use Global mode for a cross-check, but restore the original rule mode afterward.

Ten-minute triage checklist

1. Minute 1: Confirm whether all nodes or only some nodes time out.
2. Minute 2: Check the subscription expiration date, remaining traffic, and last update time.
3. Minute 3: Disable the proxy and TUN, then verify the direct connection.
4. Minute 4: Switch to a mobile hotspot for a network comparison.
5. Minute 5: Sync the system time and restart the core.
6. Minute 6: Check whether local ports such as 7890 are occupied.
7. Minute 7: Inspect the first error in the logs.
8. Minute 8: Verify the protocol, TLS, SNI, and transport settings.
9. Minute 9: Disable TUN and retest using only the system proxy.
10. Minute 10: Run a final cross-test with nodes in different regions.

The key is to check components shared by all nodes before investigating an individual node. For all-node timeouts, start with the subscription, network, core, and ports; for isolated timeouts, focus on the node server, protocol settings, and route. Keep the result of each test so you can jump directly to the relevant layer next time.