Clash Node Timeout: A Step-by-Step Connection Troubleshooting Guide

Identify the type of timeout first

A timeout in Clash does not necessarily mean the problem is on the node server. A latency test passes through the client core, DNS resolution, your local network, the node entry point, and the test URL in sequence. If any step fails to respond within the time limit, Clash may show Timeout. Narrow down the scope before changing settings; this is more effective than repeatedly refreshing the subscription.

Use comparative tests to separate node issues from local issues

1. Keep the current subscription unchanged and test at least three nodes from different regions and entry points in succession.
2. Turn off Clash system proxy and TUN, then open a website that normally works to confirm that the underlying network is healthy.
3. Restart the Clash core, enable only the system proxy, and test browsing again.
4. Temporarily import the same subscription on another device or network, such as a phone hotspot, and compare the results.

If the same node times out on home broadband but works over a phone hotspot, the problem is more likely on the device, router, or current network path. If only one node fails across multiple devices and networks while other nodes from the same subscription work, narrow the scope to that node’s entry point, port, or protocol settings.

Step 1: Confirm the client core, configuration, and proxy ports

When every node times out, first confirm that the Clash Meta (mihomo) core started successfully. A graphical interface opening does not mean the core is listening on its ports. If the logs show address already in use, configuration file test failed, or repeated restarts, resolve port conflicts and configuration errors first.

Check core status and the active configuration

Using the common Clash Verge Rev 2.4.2 interface as an example, open “Settings” → “Clash Settings” to view the active core and ports, and check the configuration currently in use under “Subscriptions.” Labels vary by client and may appear as “Core,” “Configuration,” or “Profiles.” The criteria are the same: the configuration is enabled, the core is running, and the logs show no repeating errors.

• Mixed Port: A common value is 7890; it accepts both HTTP and SOCKS5 requests.
• HTTP Port: Older configurations commonly use 7890.
• SOCKS Port: Older configurations commonly use 7891.
• External Controller: A common listening address is 127.0.0.1:9090. This is a control interface, not an application proxy port.

Do not set your browser proxy to the controller port 9090. If the configuration declares only mixed-port: 7890, the browser or system proxy should point to 127.0.0.1:7890. After changing the port, update the system proxy, browser extensions, and other manual settings as well.

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

Check for port conflicts

On Windows, use PowerShell to check whether a process is already listening on port 7890:

Get-NetTCPConnection -LocalPort 7890 -ErrorAction SilentlyContinue
Get-Process -Id (Get-NetTCPConnection -LocalPort 7890).OwningProcess

On macOS and Linux, use:

lsof -nP -iTCP:7890 -sTCP:LISTEN
ss -lntp | grep 7890

If an older Clash build, another proxy tool, or a leftover background process is using the same port, exit the conflicting program before restarting the current client. Do not let two programs manage the system proxy at the same time; the port shown in the interface may otherwise differ from the port actually used by the operating system.

Step 2: Narrow the test from the system proxy to TUN mode

Start troubleshooting with the system proxy rather than enabling TUN immediately. The system-proxy path is shorter, making it easier to verify whether the node can establish a connection. In Clash Verge Rev 2.4.2, open “Settings” → “System Settings” → “System Proxy.” After enabling it, confirm that the system proxy server is 127.0.0.1 and that its port matches the Mixed Port.

The browser works, but apps still connect directly

The system proxy affects only apps that actively read the operating system’s proxy settings. Some games, command-line tools, virtual machines, and software with its own network stack ignore the system proxy. A working browser therefore does not mean every app is being routed through Clash.

• First, search for the target domain or process in Clash’s “Connections” panel.
• If no record appears, the traffic usually never reached Clash.
• If a record appears but remains stuck in “Connecting,” continue by checking the node entry point and DNS.
• If the record shows DIRECT, check the rule match result instead of changing nodes.

Everything times out after enabling TUN

TUN mode uses a virtual network adapter and routing rules to take over more traffic. Windows usually requires administrator privileges and a virtual adapter driver that loads correctly; macOS requires approval for the network extension the first time; Linux requires /dev/net/tun and the appropriate network-management permissions.

If the system proxy works after TUN is disabled, the node itself is probably fine. Troubleshoot TUN separately instead of continuing to modify the subscription. Restore service in this order:

1. Disable TUN, quit the client, and confirm that the system network has recovered.
2. Restart the client and verify that the Mixed Port proxy works before doing anything else.
3. Launch the client with the required permissions, then enable TUN.
4. Check whether a VPN, virtual-machine bridge, traffic filter, or another TUN implementation is running at the same time.
5. If domains fail to open but IP addresses work, move on to DNS troubleshooting.

Step 3: Check DNS and the node entry domain

A node address may be an IP address or a domain name. When the server address is a domain, Clash must first obtain the entry IP through the local resolver or the default resolver in its configuration. If the entry domain cannot be resolved, every node using that entry may time out, even when all proxy protocol parameters are correct.

Check resolution at the operating-system level first

On Windows, run:

nslookup node.example.com
Resolve-DnsName node.example.com

On macOS or Linux, run:

dig node.example.com
nslookup node.example.com

Replace node.example.com with the actual server value from the node configuration. If the result is NXDOMAIN, times out, or contains no A/AAAA record, first confirm that the entry domain in the subscription is still valid. This check is especially important when multiple failed nodes share one entry domain.

Separate entry resolution from proxy-side DNS

Clash DNS settings handle application domain resolution and may also participate in resolving node entries. In a mihomo configuration, default-nameserver is mainly used to resolve the DNS servers themselves, node entries, and other basic targets. It should usually contain directly reachable DNS addresses in IP form, avoiding a circular dependency where a proxy is required to resolve the proxy entry.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8
  nameserver:
    - https://1.1.1.1/dns-query

This example explains the configuration layers; it does not mean every network should use the same resolvers. Enterprise and campus networks, or environments with internal domains, may need to retain the local DNS server. Save the original configuration before editing, reload it afterward, and watch the logs for lookup, no such host, or DNS request timeouts.

If only IPv6 entries fail, temporarily verify whether the current network has a usable IPv6 route. An AAAA record does not guarantee that the local device can connect over IPv6. Do not permanently disable IPv6 as a workaround; check the router, carrier path, and the node entry’s actual IPv6 support instead.

Step 4: Check protocol parameters when one node times out

When one node fails but other nodes from the same subscription work, the system proxy and basic local DNS are usually not the main problem. Focus on that node’s server address, port, and protocol fields. Reimporting the subscription can rule out fields lost during manual editing, but it cannot fix an offline server or incorrect data from the subscription source.

Do not switch tls, udp, or skip-cert-verify based on guesswork. These fields must match the server configuration. In particular, skipping certificate verification is not a general fix; it may hide the error temporarily but cannot resolve an incorrect SNI, an expired certificate, or an incorrect system clock.

Check the local system time

TLS handshakes depend on an accurate clock. On Windows, go to “Settings” → “Time & language” → “Date & time,” enable automatic time setting, and select “Sync now.” On macOS, go to “System Settings” → “General” → “Date & Time” and enable automatic time setting. A clock drift of only a few minutes can make a certificate appear not yet valid or already expired.

Confirm that the node port is reachable

In Windows PowerShell, run a TCP probe against the node server and port:

Test-NetConnection node.example.com -Port 443

On macOS or Linux, use:

nc -vz node.example.com 443

A successful TCP test only shows that a connection can be established to the entry port; it does not verify the UUID, password, TLS, or transport settings. A failed test may indicate that the server is not listening, the entry address is invalid, a firewall is dropping traffic, or the current network is restricting access. Some UDP-based protocols cannot be assessed directly with a TCP probe, so correlate the result with core logs and tests on another network.

Step 5: Check the firewall, router, and current network

When every node fails but the configuration works on another device, inspect the local security policy. Windows Firewall may allow the graphical client online while blocking the mihomo core that actually runs the connections. Third-party security software may also create rules by process path; after a client upgrade changes the core’s file path, an old allow rule may no longer match.

Windows checklist

1. Open “Windows Security” → “Firewall & network protection” → “Allow an app through firewall.”
2. Confirm that the current Clash client and mihomo core have access on the network type currently in use.
3. Go to “Settings” → “Network & Internet” → “Proxy” and check for an obsolete manual proxy.
4. Quit other VPNs, proxies, and network-filtering tools, then restart Clash.
5. Retest over a phone hotspot to determine whether the issue occurs only on the current router or broadband connection.

Temporarily disabling the firewall is suitable only as a brief comparison test. If a rule is confirmed as the cause, turn the firewall back on and create an explicit rule for the actual core process rather than leaving protection disabled.

Router and network exit

Router parental controls, guest-network isolation, enterprise egress ACLs, and captive portals on public Wi-Fi can all affect node connections. First open a regular HTTP and HTTPS website to confirm that the sign-in or authentication flow is complete. If switching to a phone hotspot restores the connection immediately, check the router’s DNS, IPv6, MTU, access controls, and upstream network restrictions in turn.

An MTU issue often appears as a successful TCP connection followed by a stall during TLS or large-packet transfer. In a TUN environment, if small pages open intermittently while images and downloads remain stuck, treat MTU as a later check rather than changing it without comparison data. Record the original value, then adjust gradually within the options supported by the client, keeping each change small.

How to read logs: locate the failing stage by its keywords

Temporarily setting the log level to info is usually sufficient. Use debug briefly only when you need rule and handshake details, then switch it back to avoid rapid log growth. When reproducing the issue, record the exact time, node name, and target domain, then search for entries around that timestamp.

i/o timeout is only an outcome; it does not identify who is responsible. Check the destination that appears before it: if the timed-out target is the node entry, inspect the node and local network exit; if it is a DNS server, inspect the resolution path; if it appears only for the latency-test URL while other connections work, check the test address.

A fixed troubleshooting order and recovery criteria

The full process can be reduced to eight steps. Follow them in order and record the result at each step:

1. Confirm direct connectivity: Disable the system proxy and TUN, then verify that the underlying network works.
2. Confirm the core is running: Check configuration loading, port listening, and startup logs.
3. Enable only the system proxy: Test using the actual Mixed Port, such as 127.0.0.1:7890.
4. Test nodes side by side: Compare at least three nodes to distinguish a single-node failure from a global issue.
5. Check entry resolution: Query the node domain and review IPv4, IPv6, and DNS logs.
6. Verify protocol fields: For a single node, check only its port, TLS, SNI, and transport settings.
7. Retest on another network: Use a phone hotspot to distinguish device, router, and current network-exit issues.
8. Restore TUN last: Once the basic proxy is stable, check the virtual adapter, routes, and DNS interception.

Recovery means more than seeing a latency number. At minimum, the client core should run steadily; web requests should appear in the connection panel; rules should match as expected; multiple targets should open without intermittent timeouts; and new connections should use the new policy after switching nodes. If only latency testing recovers while real connections still fail, troubleshooting is not complete.