Reading Clash Logs: info/warning/error Levels and Common Error Messages Explained

What Log Levels Mean, and Getting Them Set Right First

Clash cores (whether the original Clash or Mihomo, i.e. Clash Meta) share a unified log-level system, from most to least verbose: debug, info, warning, error, and silent. The corresponding config field is log-level, and most clients expose the same toggle in their settings UI. For everyday troubleshooting, start with info to check whether connections are being established normally, then switch to debug temporarily when you need to inspect the handshake process in detail. Remember to switch it back afterward — debug generates a huge volume of logs, and leaving it on long-term eats disk space and makes logs harder to read.

log-level: info
# Temporarily switch to this when troubleshooting connection issues
log-level: debug

The four levels aren't arbitrary — understanding them helps you quickly judge whether a log line deserves attention:

debug: The most granular level, covering DNS resolution details, handshake steps, connection pool state, and more. Very noisy under normal operation.
info: Logs the rule match result, node used, and destination address for every connection. This is the best level for day-to-day monitoring.
warning: Something went wrong, but the core is still trying to handle it on its own — for example, a node fails its health check but other nodes remain available.
error: A definitive failure — the connection was not established, and manual intervention is usually required.

The log panel in graphical clients typically color-codes levels, with warning shown in yellow and error in red — the same idea as semantic colors in a design system: color only signals priority, and you still need to read the message to know the actual cause.

Connection Errors, Explained One by One

This category of logs appears while the core is trying to establish a TCP/UDP connection to the destination server or a proxy node — it's the first thing to check when troubleshooting "can't connect" issues.

dial tcp timeout

This means the core initiated a connection but received no response within the timeout window. There are three common causes: the destination server itself is slow or down; the link between the selected proxy node and the destination has packet loss; or there's no connectivity at all between your device and the proxy server (for example, the node's server has expired or been blocked). A good troubleshooting order is to first switch to another node in the same proxy group and retest the same destination — if switching nodes fixes it immediately, the problem is with that specific node, not your local config. If every node times out, check the basic connectivity between your device and the proxy server's exit point next.

connection refused

Unlike a timeout, this means the other side explicitly refused the connection request — the network path is fine, but nothing is listening on that port, or the connection was actively rejected by a firewall (rather than silently dropped). If this error points to 127.0.0.1 plus a local port, it usually means the core itself isn't listening properly, or the mixed-port setting was changed without the client UI refreshing. Check the mixed-port value and confirm the process is actually listening on that port.

no route to host

This is a network-layer error meaning the system's routing table has no path to the destination IP. It commonly shows up after enabling TUN mode if the routing table gets corrupted or conflicts with the system's existing routes. Restarting the TUN service, or checking whether another network tool has taken over the default route, usually resolves it.

i/o timeout and EOF

i/o timeout usually appears during the read/write phase after a connection has already been established, meaning the connection succeeded but data transfer was interrupted — often due to insufficient node bandwidth or a long-lived connection being forcibly closed by a middlebox. EOF means the remote side closed the connection on its own; if it happens only once or twice, it's usually not a concern, but if it keeps happening on the same node, consider temporarily removing that node from the proxy group.

How to Read Rule Match Logs

At the info level, every new connection logs a line showing the matched rule and the policy applied, roughly in the form "matched rule type plus policy used." These aren't error logs, but they're the key clue for troubleshooting "why isn't this site going through the proxy" or "why is the speed off."

[TCP] example.org:443 match DomainSuffix(example.org) using PROXY
[TCP] cn.example.com:443 match GEOIP(CN) using DIRECT
[TCP] 10.0.0.5:8080 match Match() using REJECT

The first line shows this connection matched a domain-suffix rule and used the PROXY policy group; the second shows the destination IP was identified as being in mainland China and went direct under the GEOIP rule; the third shows no specific rule matched, so it fell through to the catch-all MATCH rule, whose policy is REJECT — meaning it was blocked outright. If you notice a lot of connections that should work normally falling through to the catch-all rule and getting rejected, it's usually a rule-ordering issue, or the catch-all rule was mistakenly set to REJECT instead of DIRECT. Checking the last line of rules in your config is the quickest way to spot this.

Note

Rules are matched top to bottom, and matching stops at the first hit. If a domain that should go through the proxy gets intercepted early by a broader rule above it and routed direct instead, the match info in the log will tell you exactly which rule caused it — no guesswork needed.

Node and Proxy Group Warnings

Beyond per-connection errors, Clash also periodically logs the results of proxy group health checks. These are usually at the warning level and don't mean a connection has completely failed, but they're worth keeping an eye on.

health check failed / url-test timeout: When a proxy group is configured with auto speed-testing (url-test or fallback type), a node that fails to complete a request to the test URL within the set time gets marked unavailable and skipped temporarily, with a retry on the next check cycle. The occasional one-off is normal.
all proxies unavailable / no proxy available: Every node in the proxy group has been marked unavailable, so every connection using that group fails. This can happen if all the subscription's nodes have expired, or if the test URL itself isn't reachable from your network, causing a false-positive failure across all nodes. Try manually switching to a node in that group and testing directly — if it connects fine manually, the speed-test logic is misjudging things, and you should adjust the test URL or interval.
proxy group has no selected proxy: The policy group has no available nodes to choose from, usually because the parsed subscription returned an empty node list. Go back to subscription management and check the node count and whether your filter rules are excluding every node.

DNS-Related Logs and How to Troubleshoot Them

Many errors that look like connection problems actually stem from failed DNS resolution. If you see could not resolve host in the logs, or resolution is unusually slow, first check whether the dns field is enabled in your config and whether the upstream DNS server you're using is reachable. With fake-ip mode enabled, if certain apps can't handle virtual IPs correctly, this can also show up in logs as the destination address behaving oddly. In that case, add the affected domains to fake-ip-filter so that traffic resolves to a real IP instead of a virtual one.

The overall troubleshooting approach boils down to three steps: check the level first to gauge severity — only error demands immediate action; then read the error text to determine whether it's a network-layer issue (timeout, refused, no route) or a logic-layer issue (match, health check); finally, use the destination address and node name in context to pin the problem down to a specific node, rule, or local network issue, rather than vaguely assuming "the whole proxy is broken."