Clash Node Timeouts and Connection Errors: A Layer-by-Layer Troubleshooting Guide

First, identify the failure: a timeout during testing, a proxy connection error, or a website that won't load

A Clash node timeout does not necessarily mean the node's server is down. Latency tests usually send a request to a test URL through the node. The result depends on your local network, the node connection, the proxy handshake, DNS resolution at the exit, and the test site. A failure at any step can trigger a timeout. First pinpoint the failing layer, then change the relevant setting—don't cycle through DNS servers, ports, and cores at random.

Clash refers to a family of cores and configuration ecosystems. Clients provide the interface and handle tasks such as subscription management and system proxy settings. Clash Meta was later renamed mihomo. Menu locations, config merging, and core capabilities vary by client. When troubleshooting, trust the logs and active config of the core that's running—not just the contents of the subscription file.

Layer 1: Make sure the subscription updated and the config is active

First confirm the client loaded the new config; only then test the node. Updating a subscription, parsing its config, and switching to that config are three separate steps. If a remote subscription update fails, the client may keep using its local cache. Seeing nodes in the list doesn't mean the latest update succeeded.

1. Check when it was updated and whether it succeeded. Find the active subscription or config in your client, run an update, and note the HTTP status code or error. Menu names vary by client. Don't mistake the automatic update interval for the time of the last successful update.
2. Make sure the response contains a config. HTTP 200 only means the request succeeded; a login page or a traffic-limit notice can also return 200. If the logs report a YAML parsing error, check the response content before trying to fix it by changing indentation.
3. Confirm the config is selected and reloaded. After switching, check that the expected nodes appear in the proxy group. Look for errors such as unknown fields, missing proxy groups, duplicate names, or unsupported proxy types.
4. Distinguish the main config from proxy providers. Configs that use proxy-providers also fetch nodes separately. A successful main config update doesn't mean the providers updated successfully.

What if the subscription download itself needs a proxy?

If an old node stops working and subscription updates are set to use that node, updates can get stuck in a dependency loop. First check whether the subscription domain is reachable directly on your current network. If your client offers a proxy option for subscription updates, temporarily switch to a path you've confirmed works. The main config's proxy-providers fetch and the client's own subscription download may use different mechanisms, so check their logs separately.

Never paste a subscription URL containing a token into a public testing site. If you need help, share only the status code, a redacted error, and the update time. A complete subscription URL is usually equivalent to a login credential.

Layer 2: Check your local network and compare network connections

If all nodes suddenly fail at once, check the local connection they share first. Pause the system proxy and TUN, then visit a website that normally works on your current network without a proxy. If basic connectivity is down too, troubleshoot Wi-Fi, Ethernet, a captive portal, or your router first. Restore any proxy settings you need when testing is done.

• Check for a captive portal: Hotel, campus, and public Wi-Fi may require you to sign in through a browser first. With a proxy enabled, the sign-in page may not open correctly.
• Check your system clock: A badly incorrect date, time zone, or clock can cause certificate validation to fail. Enable automatic time sync, then test TLS-based nodes again.
• Try a phone hotspot temporarily: Keep the same device, config, and node; change only the network. If the hotspot works but your original network doesn't, investigate its DNS, outbound traffic policies, or IPv6 route first.
• Rule out overlapping network tools: Temporarily quit other VPNs, proxy clients, or traffic filters so multiple tools aren't changing your routes at once. Don't leave your system firewall disabled as a long-term troubleshooting measure.

A hotspot test can narrow down the cause, but it can't prove that your ISP is blocking traffic. Mobile and fixed-line networks may use different DNS results, IPv4/IPv6 exits, and routes. Comparing the two tests is more useful than repeatedly running latency checks.

Layer 3: Check the listening port and whether app traffic reaches the core

Make sure the local proxy endpoint works before checking the remote node. A port conflict, a core that failed to start, or a system proxy pointing to an old port can all make apps report that the proxy won't connect. The fields below illustrate local listening only; they are not a complete config with nodes.

# Merge into the top level of your current config; don't declare the same key twice.
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

mixed-port accepts both HTTP and SOCKS proxy connections; 7890 is the port used in this example. external-controller is a control interface, not a browser proxy endpoint. Don't enter the commonly used control port 9090 in an app's HTTP proxy settings.

Find out which process is using port 7890

On Windows, check the listening ports in PowerShell, then use the returned process ID to identify the program:

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

On macOS, use the built-in lsof command; on Linux, use ss. You may need appropriate permissions to inspect process details:

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

# Linux
ss -lntp 'sport = :7890'

If another proxy instance is using the port, first confirm which instance should be serving traffic, then stop the duplicate or change its port. If you change the port, update the system proxy and app settings too. When the logs show address already in use, resolve the port conflict first—you don't need to switch nodes.

Test the local proxy endpoint directly, bypassing system proxy settings

curl --noproxy "" -x http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 -I https://example.com/

In Windows PowerShell, use curl.exe instead of the curl command shown above to avoid an alias used in some environments. --noproxy "" clears the proxy bypass list for this request; the 5-second limit sets the connection timeout, and 15 seconds sets the total request time.

If the request can't connect to 127.0.0.1:7890, check that the core is running and listening on the right port. A 200 or 301 HTTP response means the request received a response, but check the connection logs to confirm which policy was used. A rule may have sent it through DIRECT, so a response code alone doesn't prove the proxy node works.

Layer 4: Distinguish node hostname resolution from destination hostname resolution

When troubleshooting DNS, first ask: which hostname failed to resolve? If the node's server field contains a hostname, the core must resolve it before connecting. Visiting a destination site may involve another DNS lookup. A node address lookup failure and a website hostname lookup failure aren't the same issue.

• Node hostname resolution fails: Logs may show lookup, no such host, or a DNS timeout. Use a system tool to look up the node hostname, note whether it returns A or AAAA records, then compare the result with the core logs.
• Destination hostname resolution fails: The node handshake may have succeeded, but a later request can still fail during DNS resolution. Check whether the failure is on your device, in the core's DNS, or at the server's exit.
• Only the IPv6 path is failing: Check whether the logs show a connection to an IPv4 or IPv6 address. A successful system lookup doesn't guarantee that either address family has a working route, or that the core used the same resolver.

The example below shows how mihomo can use a dedicated resolver for node hostnames. The active core must support the relevant fields. This is not a general-purpose DNS recommendation. Merge it into your existing dns mapping; don't add a second dns key at the same level.

dns:
  enable: true
  nameserver:
    - 1.1.1.1
  proxy-server-nameserver:
    - 1.1.1.1

proxy-server-nameserver resolves proxy node hostnames. The resolver address in this example may not be reachable on your network, so choose one you've verified works. If your config already uses DoH, Fake-IP, or per-domain resolvers, preserve its structure and change only what's directly related to the issue.

Layer 5: Check protocol settings and core compatibility

A TCP connection to the same address and port doesn't mean the proxy protocol handshake will succeed. If the local endpoint works and the node address resolves, but only certain nodes fail, check protocol support and server settings. Older Clash cores and mihomo support different protocols. A node appearing in the client doesn't mean the active core can use its protocol.

First get a config from the provider that's intended for your current core. Don't infer the protocol from a node's name or delete parameters you don't understand. If you use a subscription converter, check that its target matches the core you're running; an incompatible conversion can drop transport or authentication fields.

A TCP reachability test only answers part of the question

On Windows, Test-NetConnection checks whether a TCP connection can be made to a specified address and port. Replace the value after -ComputerName with the actual node hostname from your config, and the value after -Port with its port. Don't use a TCP test to prove that UDP-based protocols such as Hysteria2 work.

Even a successful TCP test only means that a connection could be established to the port at that moment; the password, TLS, or proxy transport can still fail. Conversely, nodes commonly don't respond to ICMP, so packet loss from ping alone doesn't prove that the proxy is unavailable.

Layer 6: Check for server issues, exit restrictions, or a faulty test target

Focus on the server and exit only after you've largely ruled out the earlier layers. Compare different destinations on the same node, then test the same destination through different nodes. Don't just keep testing one latency URL.

1. Test two destinations through the same node. If regular websites work but latency testing fails, check the test URL, required response, and timeout threshold in the client config. A faulty test target doesn't mean the node is down.
2. Try another node for the same destination. If only one exit fails, the cause may be its route to the destination, the destination's security checks, or a DNS issue at the server.
3. Check your account status. Verify the expiration date, remaining traffic, device limit, and any maintenance notices from your provider. Being able to download the subscription doesn't mean the proxy account still has traffic available.
4. Send the provider redacted evidence. Include the failure time and time zone, node identifier, core version, error type, network-switch test results, and destination hostname. Don't send your password, UUID, full subscription URL, or full config.

connection refused usually means the connection was explicitly rejected, often because no service is listening on the port or an intermediary actively refused it. i/o timeout means a network operation didn't finish in time; use the logs to determine whether it happened during connection, handshake, or data transfer. EOF means the data stream ended; by itself, it doesn't tell you whether authentication failed or the remote end disconnected.

If regular websites work through a node but a particular platform returns a 403, CAPTCHA, or regional restriction, investigate the relationship between that site and the exit. Increasing the connection timeout won't fix an application-level restriction, and this isn't a local port issue.

Verify recovery: make sure traffic follows the expected policy

Troubleshooting is complete when the actual request succeeds over the expected route—not when the latency indicator turns green. In rule mode, the client selects a policy based on its rules. Node tests often connect directly to a selected node, so the two types of traffic may take different routes. Check the connection view or runtime logs for the destination hostname, matched rule, and node used.

• Browser fails, but an explicit proxy request works: Check the system proxy port, the browser's own proxy settings, extensions that take over proxying, and the bypass list. Existing connections may reuse an old route, so close them before retrying.
• Browser works, but terminal requests fail: Command-line tools don't always use the system proxy. First test with the explicit curl -x proxy method in this guide, then decide whether to set proxy environment variables supported by the tool.
• Need to route more apps through the proxy? TUN can handle some traffic from apps that don't use the system proxy, but it still depends on permissions, routes, and DNS settings. Enabling TUN won't fix an expired subscription, incorrect password, or dead node.
• Changed the log level temporarily? When troubleshooting is done, restore log-level to your usual info setting or its original value. This avoids keeping detailed logs that may contain the destinations you visit.