Clash Log Errors Explained: dial tcp, i/o timeout, and no such host

First locate where the failure occurs, then check the error keywords

dial tcp just means “attempting to establish a TCP connection”—it does not identify the cause of the failure. Focus on the address, port, and final error that follow. i/o timeout means a network read or write timed out; no such host means the current resolution path could not return a usable host address. These terms do not automatically mean “the node is down,” “the network is slow,” or “change DNS.”

A proxied request typically travels through “app → local proxy listener → rules and proxy groups → proxy server → destination.” DNS lookups can happen at different stages, including when resolving the proxy server’s hostname or the destination hostname. Identify which stage the failing address belongs to before changing a local port, proxy selection, or DNS settings.

Keep a minimal record of one failed request

1. Open the client’s Logs page and note when the error occurred. The page may be called “Runtime Logs” or “Logs.”
2. Note the current mode, active configuration name, node selected in the proxy group, and whether System Proxy and TUN are enabled.
3. Temporarily set the log level to debug and reproduce the failure once. When you’re done troubleshooting, switch back to info to prevent logs from growing indefinitely.
4. Keep the matching rule, selected outbound, and final error from around the same time. Don’t capture only a single red-highlighted keyword.

Common Clash errors: identify the cause before changing settings

A single error can have several layers. For example, the outer message may say dial failed, while the underlying cause is a DNS query timeout. Start with the most specific error at the innermost level, then work outward to identify which connection triggered it.

dial tcp and connection refused: identify the connection target first

dial tcp 192.0.2.10:443: connect: connection refused

This log indicates that the TCP connection to 192.0.2.10:443 was refused. Common causes include a stopped service, an incorrect port, or a network device actively rejecting the connection. If this is the proxy node’s address, check the current node’s server and port. If it belongs to the destination, check whether the rules sent the request to DIRECT.

If you see 127.0.0.1, check the local proxy listener first

Failed to connect to 127.0.0.1 port 7890: Connection refused

This message may come from a browser or command-line tool rather than the Clash log. It usually means the app cannot connect to the local proxy listener: the core may not be running, the listener port may have changed, or the app may still be using an old port. Check the client’s port settings to confirm which port is actually listening, then verify the address and port configured in System Proxy.

• mixed-port: 7890: Accepts both HTTP proxy and SOCKS proxy traffic on the same port.
• port: HTTP proxy listener; socks-port: SOCKS proxy listener. Don’t infer the protocol from the port number alone.
• external-controller: The control API, not a proxy listener for your browser.

For example, if the control API is at 127.0.0.1:9090, that does not mean you should set 9090 as the System Proxy port. Confusing the proxy listener with the control API can cause connection failures, unexpected responses, or pages that won’t load.

i/o timeout: test DNS, the node, and the destination separately

i/o timeout only means that a network operation did not finish in time. It can occur during a DNS UDP query, while connecting to the proxy server, or during a read or write after the connection is established. Switching through a dozen nodes just because you saw this message can hide the real issue: your local network.

Step 1: Reproduce the issue using an explicit proxy listener

If your active mixed port is 7890, run the command below. In Windows PowerShell, use curl.exe to avoid environments where curl is interpreted as another command. On macOS and Linux, use curl in most cases.

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

The 10-second limit applies to connecting, and the 20-second limit applies to the entire request; neither is the core’s default timeout. -I sends a HEAD request, which a server may respond to with 405. Any valid HTTP response means the request did not time out at the network level, regardless of that status code. Remove -I if you need to inspect the response body.

Step 2: Change only one variable at a time

1. Keep the destination URL and rules unchanged. Switch to a known-good node in the same proxy group, then retry the request.
2. Keep the node unchanged and try another destination you’re allowed to access. If only one destination fails, check for destination-side restrictions or the rule that matches it.
3. Keep the client configuration unchanged and test using a phone’s hotspot. If the hotspot works but your usual network doesn’t, you have a reason to investigate routing or filtering on that network.

A successful latency test does not mean every website will work. The test URL, required HTTP status, and actual destination may differ. Likewise, a failed test does not necessarily mean the node is completely unusable. Verify with the request that actually fails.

no such host: identify which hostname failed to resolve

lookup node.example.net: no such host

If the hostname in this error is the node’s server, the proxy connection has not been established yet. Check the node hostname for typos, confirm the subscription hasn’t expired or been replaced by the provider, then investigate the resolution path used for that hostname. If the error points to the destination website, check destination DNS and the matching rule; don’t assume the subscription has expired.

Check these three areas in order

1. The address itself: Make sure server is not a full URL containing https://, a path, or trailing spaces. This field should usually contain a hostname or IP address.
2. System DNS: Run nslookup node.example.net. This hostname is only an example; replace it with the actual hostname from the log, and note that the query will be sent to the resolver in use.
3. Core DNS: Check the active configuration’s dns section. Look for resolver connection timeouts or refused connections at the same time as the error.

The result of nslookup is a point of comparison; it does not prove that the core’s DNS is working. The system resolver, built-in Clash DNS, and browser Secure DNS may each use a different path. TUN DNS hijacking can also change how queries are routed.

If encrypted DNS is configured to go through the proxy, but the proxy node’s hostname also depends on that DNS to resolve, you can create a startup dependency loop. Establish a reachable resolution path for the node hostname first rather than forcing all DNS queries through a proxy that is not yet connected.

address already in use: how to find a local port conflict

listen tcp 127.0.0.1:7890: bind: address already in use

This is a local listener failure, unrelated to your node plan or remote hostname. Common causes include another proxy client already running or an old core process that did not exit cleanly. Identify what is using the port before deciding whether to close the old process or change the port. Don’t terminate an unfamiliar system process.

Windows: find the process listening on a port

netstat -ano | findstr :7890
tasklist /FI "PID eq 1234"

The first command lists entries that include the port. Check the local address, LISTENING status, and PID. In the second command, 1234 is an example process ID; replace it with the actual PID returned by your query. A connection entry alone does not necessarily mean the process is occupying a listening port.

macOS / Linux: check which process is listening

lsof -nP -iTCP:7890 -sTCP:LISTEN

If lsof isn’t installed on Linux, try ss -ltnp 'sport = :7890'. You may need additional permissions to see process information. If you change the mixed port from 7890 to 7891, also update System Proxy, browser extensions, terminal environment variables, and any other apps configured to use the old listener.

A “started” status in the interface doesn’t guarantee that every listener started successfully. Check the logs after startup to see whether the error concerns mixed-port, the DNS listener port, or the control API. This helps avoid changing the wrong setting.

TUN, certificates, and dropped connections: don’t treat them all as timeouts

• network is unreachable: First check whether the address is IPv6, then confirm that your current network has a usable IPv6 route. This points more toward a routing issue; it doesn’t prove that the server is offline.
• permission denied or operation not permitted: If this occurs while creating a TUN device, check the client’s service mode, system permissions, and whether another VPN is using the device. Follow the current client’s installation instructions to grant the required permissions; don’t broadly elevate the permissions of the entire app.
• x509: certificate has expired or is not yet valid: First check the system date, time, and time zone, then verify the node’s certificate. Don’t use skip-cert-verify: true as a permanent fix.
• connection reset by peer or EOF: The connection was reset or the read ended. Possible causes include the server, protocol settings, or an intermediary network. This line alone isn’t enough to determine whether the password is wrong.

To compare TUN behavior, note its original state, turn TUN off, then test with a request that explicitly uses 127.0.0.1:7890. If the explicit proxy works but TUN fails, focus on routing, DNS hijacking, and conflicts with other VPNs. Simply turning off TUN and opening a browser is not an equivalent test: the browser might switch to System Proxy or connect directly.

If only one app fails, first check whether it uses TCP or UDP, reads System Proxy settings, or has its own proxy configuration. A successful HTTP proxy request does not prove that UDP forwarding works. Don’t jump straight to changing the global mode or the entire subscription configuration.

Retest after fixing the issue and keep comparable evidence

1. Retry with the same URL, request method, and proxy group, and confirm that the original error no longer appears.
2. Check which rule matched and which outbound was used in the log, so you can rule out the request accidentally going direct.
3. Restore the temporary log level and test settings, and save any necessary local configuration changes.
4. When asking for help, include the core name and version, OS version, time of the error, full error chain, and steps to reproduce it.

Follow this order: local listener → rule and outbound → node resolution and connection → destination response. Change one thing at a time and compare the same request before and after each change; this is usually more effective than reinstalling repeatedly. For port settings, see the port guide in Getting Started. For persistent timeouts, see timeout troubleshooting.