Home>Tutorials>Node Connection Troubleshooting

Clash Node Connection Failed: 8 Causes & Troubleshooting Guide

Updated: 14 min read
Table of Contents
  1. Diagnosing the Problem
  2. Expired or Depleted Subscription
  3. Node Server Offline
  4. Protocol Incompatibility
  5. Port Blocking by Firewall
  6. TLS Handshake Failure
  7. Incorrect System Time
  8. Local Firewall or Security Software
  9. DNS Resolution Failure
  10. Quick Diagnostic Checklist
  11. Advanced Debugging Techniques

Diagnosing the Problem

Few things are more frustrating than setting up Clash only to find that none of your nodes will connect. Latency tests show timeouts, web pages refuse to load, and the log panel fills with cryptic error messages. Node connection failures are among the most common issues Clash users face, but they are almost always traceable to one of eight root causes.

This guide walks through each cause with clear symptoms, diagnostic steps, and solutions. The guide is client-agnostic: whether you use Clash Verge Rev, FlClash, Clash Meta for Android, or any other mihomo-based client, the underlying causes and fixes are the same. If you need help with initial setup first, our Windows installation guide covers the basics from scratch.

Before diving into the specific causes, make sure you have performed these baseline checks:

Cause 1
Expired or Depleted Subscription

Symptoms

  • All nodes show timeout on latency test
  • Subscription was working previously but suddenly stopped
  • The provider's dashboard shows zero remaining traffic or an expired date

Diagnosis

Log in to your proxy provider's website or app and check your account status. Look for remaining traffic quota and subscription expiration date. If either has reached zero or passed the current date, your subscription is no longer active.

Solution

Renew or top up your subscription with your provider. After renewal, update your subscription in Clash by right-clicking the profile card and selecting "Update". If your provider changes the subscription URL upon renewal, you will need to import the new URL and remove the old profile.

Prevention tip

Set a calendar reminder a few days before your subscription expires. Most providers send email notifications, but these can land in spam. Keeping your subscription current avoids unexpected downtime.

Cause 2
Node Server Offline

Symptoms

  • Some nodes connect while others timeout
  • The issue appears suddenly without any configuration changes on your end
  • Nodes from the same region all fail simultaneously

Diagnosis

Run a latency test on all proxy groups. If only certain nodes or regions fail while others work, the problem is likely on the server side. Check your provider's status page, Telegram channel, or website for outage announcements.

Solution

Switch to nodes that pass the latency test. If entire regions are down, wait for your provider to restore service or contact their support. You can also refresh your subscription to see if the provider has added replacement nodes.

Cause 3
Protocol Incompatibility

Symptoms

  • Specific nodes fail while others using different protocols work
  • Log shows errors like "unsupported protocol" or "unknown proxy type"
  • Newly added nodes fail while older nodes continue working

Diagnosis

Check the mihomo core version bundled with your client. Newer proxy protocols like VLESS, Reality, and Hysteria2 require recent mihomo versions. If your client bundles an outdated core, it cannot connect to nodes using these newer protocols.

You can verify the core version in the client's Settings or About page. Compare it with the latest mihomo release on GitHub.

Solution

Update your client to the latest version, which should bundle a recent mihomo core. If your client does not auto-update the core, you may need to download the latest mihomo binary manually and place it in the client's core directory.

Alternatively, ask your provider which protocols their nodes use. If they have recently migrated to VLESS/Reality, ensure your client supports these. For a comparison of clients and their protocol support, see our Clash client comparison.

Cause 4
Port Blocking by Firewall

Symptoms

  • Nodes on certain ports work while others on different ports fail
  • Nodes using port 443 work but nodes using non-standard ports timeout
  • The issue appears after connecting to a new network (office, hotel, campus)

Diagnosis

Run latency tests and note which ports succeed and which fail. If nodes using port 443 (standard HTTPS) consistently work while nodes on other ports fail, your network is likely blocking non-standard ports.

Solution

Switch to nodes that use port 443 or other commonly allowed ports (80, 8080). Many providers offer "relay" or "IPLC" nodes that use standard ports specifically for restricted network environments.

If all ports are blocked, the network may be performing deep packet inspection (DPI). In this case, nodes using obfuscation protocols or TLS-wrapped traffic (like Reality or WebSocket over TLS) have the best chance of passing through.

Cause 5
TLS Handshake Failure

Symptoms

  • Log shows errors like "tls: handshake failure", "certificate verify failed", or "x509: certificate is valid for"
  • Nodes using TLS-based protocols (Trojan, Reality, TLS-WebSocket) fail
  • Non-TLS nodes (plain Shadowsocks, VMess without TLS) work fine

Diagnosis

TLS handshake failures typically result from one of three issues: (1) the server's TLS certificate does not match the SNI configured in your proxy settings, (2) the server's certificate has expired, or (3) your system's CA certificate store is outdated.

Check the logs for the specific error. An "x509" error usually indicates an SNI mismatch. A "certificate has expired" message points to a server-side issue.

Solution

For SNI mismatches: verify that the sni or servername field in your proxy configuration matches the domain on the server's certificate. If you are using a subscription from a provider, this should be pre-configured correctly. If you manually edited the configuration, double-check the SNI value.

For expired certificates: this is a server-side issue. Contact your provider to renew the certificate, or switch to a different node.

For outdated CA stores: update your operating system's root certificates. On Windows, run Windows Update. On Linux, update the ca-certificates package.

TLS issues can also contribute to DNS leaks if the handshake partially succeeds. For a complete DNS hardening guide, read our DNS anti-pollution configuration guide.

Cause 6
Incorrect System Time

Symptoms

  • TLS-based nodes fail with certificate-related errors
  • Nodes were working but suddenly stopped after a system reboot or travel
  • The error mentions "certificate not yet valid" or "certificate has expired"

Diagnosis

TLS certificate validation is time-sensitive. If your system clock drifts more than a few minutes from real time, certificate validation fails even if the certificate is perfectly valid. This commonly happens after dual-booting between operating systems (which can cause the hardware clock to shift between UTC and local time), after traveling across time zones without updating the clock, or when NTP synchronization is disabled.

Check your system time against a reliable source like time.is.

Solution

Enable automatic time synchronization in your operating system settings. On Windows, go to Settings, Time & Language, Date & time, and toggle "Set time automatically" on. On macOS, enable "Set date and time automatically" in System Settings, General, Date & Time. On Linux, ensure systemd-timesyncd or ntpd is running.

After correcting the time, restart Clash and re-test node connectivity.

Cause 7
Local Firewall or Security Software

Symptoms

  • Nodes fail immediately after installing new security software
  • All nodes timeout with no specific error in Clash logs
  • The issue resolves when security software is temporarily disabled

Diagnosis

Some antivirus suites, internet security software, and even Windows Defender can block Clash's network activity. The proxy process attempts outbound connections that the security software interprets as suspicious. This is particularly common with corporate-managed endpoints that have aggressive endpoint detection and response (EDR) software.

Solution

Temporarily disable your security software and test node connectivity. If nodes connect with the software disabled, add Clash and the mihomo core binary to the software's exclusion/whitelist. The exact steps depend on your security software:

  • Windows Defender: Settings, Privacy & Security, Virus & threat protection, Manage settings, Exclusions. Add the Clash Verge Rev installation directory and the mihomo executable.
  • Third-party antivirus: Look for an "Exclusions" or "Trusted applications" section in the settings.
Security reminder

Only add exclusions for software you have downloaded from official sources. If you obtained your Clash client from the official GitHub releases page, it is safe to exclude. Never download proxy clients from unverified sources and add them to your security software's whitelist.

Cause 8
DNS Resolution Failure

Symptoms

  • Log shows "lookup" or "resolve" errors for node server hostnames
  • Nodes using IP addresses directly work, but nodes using domain names fail
  • The issue appears after changing DNS settings or TUN mode configuration

Diagnosis

If Clash cannot resolve the domain name of a proxy server, it cannot establish a connection. This can happen when DNS is misconfigured in Clash's settings, when TUN mode is not capturing DNS queries properly, or when the system's DNS resolver is blocked.

Check the logs for entries containing "dns" or "resolve". If you see "no such host" or "i/o timeout" for DNS queries, the problem is DNS-related.

Solution

First, verify your Clash DNS configuration. The default-nameserver field must contain DNS servers that can resolve the DoH/DoT hostname itself. These must be plain DNS (IP addresses), not encrypted DNS URLs:

dns:
  enable: true
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://doh.pub/dns-query
    - https://dns.alidns.com/dns-query

If you are using TUN mode, ensure dns-hijack includes any:53 to capture all DNS queries. Without this, some applications may send DNS queries that bypass Clash's resolver.

If DNS resolution still fails, try adding a direct DNS bypass for the proxy server's domain:

dns:
  nameserver-policy:
    "your-proxy-server.com":
      - 223.5.5.5
      - 119.29.29.29

This forces Clash to use specific DNS servers for resolving the proxy server's hostname, bypassing any potential pollution or blocking.

Quick Diagnostic Checklist

Use this checklist to narrow down the cause quickly:

  1. Check subscription status -- Log in to your provider and verify your account is active with remaining traffic.
  2. Test multiple nodes -- If some nodes work and others fail, the issue is server-side (Causes 2, 3, 4, or 5).
  3. Test all nodes fail -- If absolutely no nodes connect, the issue is likely on your end (Causes 1, 6, 7, or 8).
  4. Check system time -- Verify your clock is accurate to within a few seconds.
  5. Check the logs -- The mihomo log often contains the specific error message that points directly to the cause.
  6. Try a different network -- If switching from Wi-Fi to mobile hotspot fixes the issue, your original network is blocking traffic (Cause 4).
  7. Disable security software -- Temporarily turn off antivirus/EDR to rule out local blocking (Cause 7).
  8. Update your client -- An outdated client may lack support for newer protocols (Cause 3).

Advanced Debugging Techniques

Enable Debug Logging

In your client settings, set the log level to debug. This produces verbose output including every connection attempt, DNS query, and rule match. While noisy, debug logs reveal the exact point of failure in the connection pipeline.

Test with a Minimal Configuration

Create a new local profile with a single proxy node and a single MATCH rule. Strip away all complexity:

proxies:
  - name: "test-node"
    type: vmess
    server: your-server.com
    port: 443
    uuid: your-uuid
    alterId: 0
    cipher: auto
    tls: true

proxy-groups:
  - name: "Test"
    type: select
    proxies:
      - test-node

rules:
  - MATCH,Test

If this minimal config connects successfully, the issue lies in your main configuration's rules, DNS settings, or other advanced features. Gradually add sections back until the failure recurs to isolate the problematic component.

Use the Clash API Directly

If your client's UI does not expose enough diagnostic information, you can query the mihomo RESTful API directly. With the external controller enabled, use curl or a browser to check:

These API endpoints provide raw diagnostic data that can help pinpoint issues invisible through the GUI.

Check for IP Leaks

After resolving connection issues, always verify that your traffic is properly routed. Visit an IP checking service and a DNS leak test site to confirm your proxy is functioning correctly and not leaking your real IP or DNS queries.

Still stuck?

If you have worked through all eight causes and the checklist without success, the issue may be specific to your provider's infrastructure or a bug in a recent client release. Visit your client's GitHub Issues page to search for similar reports. You can also consult our complete tutorial guide for additional troubleshooting sections covering TUN mode, DNS configuration, and subscription management.

Continue Reading

How to Fix Clash Subscription Import Failures Clash DNS Anti-Pollution Configuration Clash TUN Mode: Global Transparent Proxy Guide Beginner's Guide to Clash Rule Configuration 10 Clash Verge Rev Tips & Hidden Features