Clash Node Timeout or Connection Failed? Troubleshooting from Subscription to DNS

First, distinguish a speed-test timeout from a connection failure

When the Clash client shows “Timeout,” it usually means a test request did not complete within the allotted time. That does not necessarily mean the server is offline: an unreachable test URL, a DNS lookup failure, or invalid node credentials can all produce similar results. Conversely, a successful latency test only confirms that the test request worked at that moment; it does not guarantee that every website, UDP connection, or app will work.

The goal is to identify where the failure occurs: configuration retrieval, local listening, DNS resolution, the node handshake, or rule selection. Save your current configuration and logs first, then test with one node, one destination, and one connection method. Avoid updating the subscription, changing DNS, and enabling TUN all at once—you won't know which change helped.

Keep a minimal test record

• Environment: Note your operating system, Clash client version, core version, and whether you’re on Wi-Fi, mobile data, or a wired network. Record the UI and mihomo core versions separately.
• Configuration: Note the active profile name, when the subscription last updated successfully, the proxy mode, and the node selected in the policy group.
• Symptoms: Distinguish between “all nodes time out,” “only one node fails,” “speed test succeeds but the browser fails,” and “the browser works but one app fails.”
• Timing: For example, note a request started at 14:30:00 and capture the 30 seconds of logs that follow. This is a record-keeping format, not a preset test result.

Step 1: Make sure the subscription is valid and the configuration is active

A subscription URL is a source for configuration, not the node connection itself. A successful subscription update does not mean the nodes are usable: the downloaded configuration may contain expired account details, or the provider may be maintaining its servers. Open the profile list in the Clash client, confirm which profile is active, update that profile, and check the result and last-updated time.

1. Check your account status. Sign in to your subscription provider’s account page and check the expiration date, remaining data, and device limit. If your data is used up or your account is disabled, changing local ports usually won’t help.
2. Check the subscription response. HTTP 401 or 403 errors usually point to authorization or access policies; a 404 may mean the URL is no longer valid, and a 429 means requests are being rate-limited. If the response is a login page rather than configuration data, don’t import it as YAML.
3. Check the load result. After updating, confirm that the node list changed as expected and look for YAML syntax errors, unknown fields, or unsupported protocol warnings. Some Clash clients keep the old configuration when an update fails.
4. Check the effective configuration. Configuration merges, overrides, and scripts can change ports, DNS, or rules. Base your troubleshooting on what actually loaded, not just the original subscription text.

What to check when all nodes fail versus one node

If only one node fails, try another node in the same policy group, then check the failing node’s server address, port, and credentials. If all nodes fail, start with shared dependencies: your local network, system clock, DNS, and local core. Different nodes may also share a server hostname, leaving them all affected by the same DNS issue.

Remote rule sets and proxy groups may be fetched separately through rule-providers and proxy-providers. A successful main subscription update doesn’t guarantee these resources downloaded successfully. Check the logs for resource download errors, especially for dependency issues where fetching a resource requires a proxy that isn’t available at startup.

Step 2: Correct the system clock and verify your network

A significantly incorrect system date can cause TLS certificate validity checks to fail and may also disrupt time-dependent authentication. These errors can occur during the node handshake or while downloading a subscription. Check the full date and time, not just the hour shown in the taskbar.

• Windows 11: Go to Settings → Time & language → Date & time, turn on Set time automatically, then select Sync now under Additional settings or Sync your clock.
• macOS: Go to System Settings → General → Date & Time and turn on automatic date and time. Labels may vary slightly by macOS version.
• Linux: Run timedatectl status to check the time and synchronization status. On systemd-based systems that support time synchronization, run sudo timedatectl set-ntp true to enable it.

Turn off the Clash client’s system proxy and TUN, then try to visit a website that should be directly accessible on your current network. Complete any captive portal sign-in on public Wi-Fi first. If your basic internet connection isn’t working, changing proxy rules will only add noise.

Compare with a different network

On the same device and configuration, test both your usual network and a phone hotspot. If the problem occurs only on your usual network, its DNS, egress restrictions, or firewall may be involved. If both networks fail, check the device and configuration. This comparison narrows down the cause but does not prove that any particular blocking mechanism is involved.

A missing response from ping alone does not prove that a node is offline; servers may not respond to ICMP. Nodes can use TCP, UDP, or other transports, so check connection logs for the protocol in use.

Step 3: Check proxy ports and the connection path

A browser failing to connect to the local proxy is different from a remote node timing out. Common causes include a core that hasn’t started, a port already in use, or a system proxy still pointing to an old port. Open the active configuration and find mixed-port, or check port and socks-port separately. The example below uses the mixed port 7890; this is only an example, so replace it with the port actually listening on your device.

Find the process listening on the port

On Windows, run the following command in PowerShell. Use OwningProcess in the output to identify the process and check whether it is the expected core.

Get-NetTCPConnection -LocalPort 7890 -State Listen
Get-Process -Id (Get-NetTCPConnection -LocalPort 7890 -State Listen).OwningProcess

On macOS, use lsof; on Linux, use ss. You may need elevated permissions to see process details.

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -ltnp 'sport = :7890'

If nothing is listening, check the core startup logs first. If you see address already in use, close the old instance using that port or change the listening port in the Clash client. Don’t terminate an unfamiliar system process—check its name and source first. After changing the port, update the system proxy address too, or your browser may keep connecting to the old port.

Test with an explicit proxy, bypassing the system proxy toggle

The commands below specify the local HTTP proxy directly, letting you check whether the listening port, proxy forwarding, and destination request are working. On Windows, use curl.exe to avoid PowerShell environments where curl may be interpreted as a different command. On macOS and Linux, you can use curl.

curl.exe -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com/

• Connection refused immediately: Focus on the local listening address, port, and core status rather than switching nodes.
• Received an HTTP response: This request completed. If the browser still fails, check the system proxy, browser proxy settings, or extensions.
• Timed out while waiting: Check the logs from the same time to distinguish a failed connection to the node server, a TLS handshake failure, and a timeout waiting for the destination website.

Here, 10 seconds is the connection timeout and 20 seconds is the overall request timeout; neither is a latency measurement. The test is also affected by the active rules: if the destination matches DIRECT, it only confirms that the direct route works. To test a specific node, temporarily select the relevant policy and check the connection log, then restore the previous mode.

Step 4: Check DNS resolution along the actual request path

There are at least two DNS issues to distinguish: whether the node server’s hostname resolves and whether the destination website’s hostname resolves. If the first lookup fails, the node connection cannot be established. If the second fails, the node may pass its speed test while a particular website remains inaccessible. Log messages such as no such host, DNS query timeouts, and resolver connection failures are more useful for troubleshooting than a generic “Timeout” in the UI.

Check system DNS first, then the core’s DNS

# Windows PowerShell: check the system DNS response
Resolve-DnsName example.com

# Basic lookup on most desktop operating systems
nslookup example.com

Replace the example hostname with the one that actually fails in the logs. A successful system lookup doesn’t mean the resolver used by the Clash core is working too. The lookup path may differ if the core uses its own DNS, TUN handles DNS, or an app uses encrypted DNS. Check the effective configuration and logs for dns.enable, nameserver, and related settings.

Support for and behavior of these fields depend on the core version; check the documentation for your version before making changes. Don’t apply a mihomo configuration to an older core that doesn’t support those fields. Adding several public DNS servers at once doesn’t prove the issue is fixed—you still need to verify resolver reachability, routing policy, and bootstrap resolution.

A Fake-IP address is not the node server’s address

With Fake-IP enabled, DNS may return an address from the configured mapping range, such as 198.18.0.0/16. This is an internal mapping that links a domain to a connection; seeing one of these addresses does not mean your DNS is being poisoned. The key is whether the connection returns to the same core and the original hostname is restored correctly.

If apps keep using cached results after you switch DNS modes, restart the affected apps first, then clear the DNS cache using the method for your operating system. On Windows, run ipconfig /flushdns, but note that this won’t automatically clear a browser’s own cache or the core’s mappings. For LAN services that genuinely aren’t compatible with Fake-IP, use the logs to configure a targeted fake-ip-filter instead of bypassing Fake-IP for every domain.

Step 5: Check rule matches and policy group selection

If a node shows latency but websites won’t load, requests may not be using the expected node. In rule mode, rules are matched in configuration order. Domain, IP, and process rules, as well as the final catch-all rule, can send different requests to different policies. Check the connection log in the Clash client and verify the destination hostname, matched rule, policy chain, and actual outbound node.

1. Pin one node. Select a node manually in the policy group so an automatic latency-based group doesn’t switch routes during troubleshooting.
2. Start a new connection. Close existing tabs or restart the app before testing again. Existing long-lived connections may not switch to the new node immediately when you change policies.
3. Check DIRECT and REJECT. Switching proxy nodes won’t help if a request matches a direct or reject rule. Check the relevant rule first.
4. Briefly compare with global mode. Make sure the global policy also selects the node you’re testing. If global mode works but rule mode doesn’t, focus on the rules and policy groups. Switch back to rule mode when you’re done.

Global mode doesn’t automatically route traffic from every app. With only the system proxy enabled, apps that ignore system proxy settings may still connect directly. If an explicit proxy command works but a game, command-line tool, or messaging app fails, first check whether it supports HTTP or SOCKS proxies before deciding whether to use TUN.

Test TUN and UDP separately

TUN routes system IP traffic through a virtual network interface and requires the right permissions, routes, and DNS handling. If the browser works but TUN doesn’t, check that the service is installed, that you have administrator privileges, and that the virtual interface is working. Also check for route conflicts with other VPNs. Don’t assume every failure is caused by the node.

An HTTPS website test mainly checks the TCP path; it doesn’t prove UDP is working. Games, voice calls, and some QUIC connections also depend on the node protocol, server-side forwarding, and local network conditions. Test the affected apps separately and check UDP logs. Enabling a UDP option in the configuration won’t give UDP forwarding capabilities to a server that doesn’t support them.

Finally, use logs to pinpoint handshake and server issues

Move on to node handshakes and server-side troubleshooting only after checking the subscription, system clock, ports, DNS, and rules. You can temporarily set the log level to debug, reproduce the issue once, then restore your usual level. Log access varies by Clash client; look for an export option on the logs page instead of guessing a fixed directory.

Settings that require matching server-side configuration—such as the port, password, UUID, SNI, WebSocket path, and Reality parameters—must match the valid configuration from your subscription provider. Changing one at random may prevent a working node from completing its handshake. If just one node fails consistently on two networks while others work, switch to an available node and report the issue to your provider.

Include these four pieces of evidence when reporting the issue

• Your operating system, Clash client and core versions, and when the issue started.
• Whether all nodes or only some fail, and whether the issue occurs with the system proxy or TUN.
• The explicit proxy test result, matched rule, and comparison after switching networks.
• Redacted logs covering a single failed request—not just a screenshot showing “Timeout.”

For a fresh walkthrough of importing a configuration and setting up a connection, see the user guide. For DNS, rules, and TUN settings, see advanced configuration. Change one setting at a time and keep a restorable copy of your configuration—this is more useful for troubleshooting than reinstalling repeatedly.