How to Read Clash Runtime Logs: Common Error Messages and Troubleshooting

First, confirm which logs you are viewing

A Clash client usually includes both a graphical interface and a proxy core. The interface handles configuration imports, node switching, and settings, while cores such as Clash Meta (mihomo) listen on ports, resolve DNS, match rules, and establish connections. When troubleshooting network issues, the core runtime log is usually more useful than installation records or interface crash reports.

A typical log entry includes the time, level, connection source, destination address, matched rule, and final egress. Formatting varies slightly between clients, but the meaning is broadly consistent. For example:

2026-06-02 14:32:18 INFO [TCP] 127.0.0.1:51842
--> api.example.com:443
match DomainSuffix(example.com) using Proxy[Node-A]

This entry means that a TCP connection was started from local port 51842 to api.example.com:443. The DOMAIN-SUFFIX,example.com rule matched, the connection was assigned to the Proxy policy group, and Node-A was selected within that group. It confirms that the traffic reached Clash and shows the rule and egress selection, but it does not by itself prove that the target website returned valid content.

The difference between interface logs and core logs

• Core logs: Include TCP, UDP, DNS, rule matching, proxy handshakes, and TUN inbound events. They are the primary source for connection troubleshooting.
• Interface logs: Record configuration saves, tray actions, window loading, update checks, and other events. Use them when the client will not start or a button does not respond.
• Service logs: Some Windows clients install a system service to manage TUN or elevate permissions. If the service fails to start, check its logs as well.
• Subscription update records: Show whether a remote configuration request returned 200, 401, 403, 404, or timed out. They are not the same as routine proxy connection logs.

How to choose a log level

The log-level setting in a Clash configuration controls how much the core outputs. Common mihomo 1.19.x levels include silent, error, warning, info, and debug. Some graphical clients abbreviate warning as Warn or place the setting under “Core Settings.”

Info is enough for most issues. Debug output can grow to thousands of lines within minutes, while browser background connections may hide the request that actually failed. Enable it only before reproducing the issue, then switch back to Info immediately after one test.

When editing YAML directly, set it at the top level:

log-level: info

Using Clash Verge Rev 2.3.x as an example, open “Settings” → “Clash Settings” → “Log Level” and select Info. To review entries, open “Logs.” Some minor versions may label the entry “Core Logs” or “Runtime Logs.” If a change made in the interface has no effect, check whether the current configuration is subscription-managed and whether switching configurations overwrote the local setting.

Breaking down the connection path in one entry

When reading logs, do not search only for red Error entries. Many website access failures appear as ordinary Info records because the core accepted the request successfully, but the subsequent dialing stage timed out. A more effective approach is to read each entry through five stages: inbound, destination, rule, policy, and result.

1. Inbound source: Confirm whether the request came through HTTP, SOCKS, Mixed, or TUN. A common local listening address is 127.0.0.1, and Mixed is often configured on port 7890.
2. Destination address: Check whether the destination is a domain or IP address, and whether the port is 80, 443, 53, or an application-specific port.
3. Rule match: Identify Domain, DomainSuffix, GeoIP, IPCIDR, RuleSet, or the final Match.
4. Policy egress: Confirm whether the traffic uses DIRECT, REJECT, or a proxy group and which node was selected.
5. Connection result: Check nearby entries at the same time for timeout, refused, TLS, DNS, or EOF.

How to tell whether the system proxy is not handling traffic

After clearing the logs, visit a website you have not opened before. If no new TCP or UDP connection appears at all, the problem likely occurred before the request reached the core. First check that the system proxy is enabled, then verify that the application is not bypassing it. On Windows, check the manual proxy status under “Settings” → “Network & Internet” → “Proxy.” A common HTTP proxy address is 127.0.0.1:7890; use the port shown by your client.

If the browser has a separate proxy extension, its port must also match Clash’s current listening port. When the log is empty, repeatedly switching nodes usually achieves nothing because the nodes never received the request. With TUN mode enabled, also confirm that the logs show TUN inbound startup and that the virtual network adapter has been created.

How to identify a wrong rule match

The destination may appear in the log even when the egress differs from what you expected. Focus on the rule after match. For example, a destination that should use a proxy might show:

INFO [TCP] 198.18.0.1:42116 --> service.example.com:443
match GeoIP(CN) using DIRECT

198.18.0.1 may be a Fake-IP mapping address and does not mean that the real server is located there. The key detail is that GeoIP matched and the connection used DIRECT. If a domain rule should take priority, check the rule order, whether the rule set loaded successfully, and whether the domain was resolved to an IP too early. Clash evaluates rules from top to bottom and stops at the first match.

What common errors mean

i/o timeout and context deadline exceeded

Both messages indicate a timeout, but the timeout may occur at different stages. A timeout while connecting to a node address is commonly caused by an offline node, an unreachable port, network blocking, or unavailable UDP. A timeout while connecting to the target site may indicate a problem between the node and the destination. Check the address in the error first: if it is the node server’s IP and port, switch to another node that has passed a latency test; if it is the target domain on port 443, compare DIRECT with the proxy egress.

An 80 ms latency test does not guarantee that a node is usable. Some tests access only a fixed URL, while a real website also involves DNS, TLS, and destination-server policies. Run three consecutive tests. If the results swing sharply between 80 ms, 450 ms, and timeouts, the node path itself is unstable.

connection refused

connect: connection refused means the destination host explicitly rejected the connection, usually returning faster than a timeout. If the refused address is 127.0.0.1:7890, the application is connecting to a local proxy port with no process listening on it; the core may not be running or the port may have changed. If a remote node port was refused, common causes include a stopped server process, a changed port, or expired node information in the subscription.

On Windows, run netstat -ano | findstr 7890 to inspect the port. On macOS or Linux, run lsof -i :7890. If there is no LISTEN entry, restore the core first; there is no need to inspect rules yet.

no such host, server misbehaving, and DNS timeouts

no such host usually means the domain did not receive a usable resolution result. Possible causes include a misspelled domain, an upstream DNS server returning NXDOMAIN, or Clash being unable to reach the configured nameserver. server misbehaving often indicates an abnormal upstream DNS response or an interrupted request flow. If the logs also contain lookup, exchange failed, or deadline exceeded, troubleshoot DNS before checking nodes or rules.

First verify the DNS switches and listening address in the configuration, for example:

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

Here, 1053 is Clash’s DNS listening port, not the browser proxy port. If the system or another program needs to send DNS requests to it, make sure the port is not already in use. With DoH, also account for the initial resolution of the DoH domain itself. If necessary, use default-nameserver to provide an IP-based DNS server that can be reached directly.

TLS handshake timeout and certificate-related messages

TLS handshake timeout means the TCP connection may have been established, but the TLS handshake did not finish within the allowed time. Possible causes include node quality, a slow target website, packet loss on the path, or an incorrect system clock. Check the system date, time zone, and automatic time synchronization first, then test again with another node. If only one domain fails, the issue is more likely specific to the destination or that domain’s route.

x509, certificate signed by unknown authority, and domain mismatch errors indicate certificate validation failure. Do not disable certificate verification as a long-term fix. Check the system time, local traffic-inspection software, enterprise network certificates, and the content returned by the node to confirm that the connection was not redirected to the wrong server.

EOF, connection reset by peer, and broken pipe

EOF means the data stream ended early. A single occurrence is not necessarily a fault; browser-cancelled requests can also produce EOF. connection reset by peer means the remote side actively reset the connection, while broken pipe means the local side continued writing after the peer had closed the connection. If these entries appear only when closing a page, they can be ignored. If they recur within 1–2 seconds on every visit, switch nodes, disable QUIC and retry, then check whether the destination restricts the current egress IP.

Locate nodes, rules, and DNS by symptom

Node latency is normal, but the website will not open

1. Set the log level to Info and clear the existing entries.
2. Visit only one HTTPS website, and note the destination domain and time of the test.
3. Confirm that the destination domain appears in the logs, then check the policy group and node actually used.
4. Search for timeout, TLS, reset, and EOF entries within the same minute.
5. Keep the same rule and test with another node. Avoid changing multiple variables at once.
6. If every node fails, switch to DIRECT for comparison and check the DNS resolution result.

If the connection recovers immediately after switching nodes, the issue is concentrated in the original node or its upstream route. If every node fails during resolution, check DNS first. If the log shows DIRECT when a proxy was expected, inspect the rule order or policy-group selection.

Only one application cannot connect

If the browser works but one application produces no log entries at all, it usually is not using the system proxy. Some games, command-line tools, and store apps establish connections directly. In that case, enable TUN mode to handle more traffic. After enabling it, check that the TUN device started, routes were added, and no permission errors appeared.

If the application produces logs but UDP keeps failing, confirm that the selected node supports UDP and that the policy group permits UDP. TUN’s MTU can also affect specific networks. If the default value causes fragmentation, compare a setting of 1400 with 1500 within the range supported by the client; do not change it repeatedly without evidence from the symptoms.

Rule mode fails, but Global mode works

This usually points to a rule-matching issue. Global mode bypasses most rule evaluation and uses the selected proxy group directly, proving that the node has at least basic connectivity. Switch back to Rule mode, search for the destination domain, and inspect the matched entry. If it falls through to MATCH,DIRECT, check the final rules. If an outdated rule set matched, check whether its provider failed to download.

Rule-set loading problems often appear with HTTP 404, 403, timeouts, or YAML parse errors. After correcting the remote URL, use “Configuration” → “Update” in the client, or run the corresponding rule-set update action, then confirm that the logs show a successful load. Renaming a policy group without updating rule references can make rules point to a nonexistent policy.

What else to check in TUN mode logs

TUN mode receives traffic at the system network layer, so logs may include virtual adapter, routing, DNS hijacking, and interface-selection details. If no TUN device is created after the core starts, common causes include insufficient permissions, a stopped system service, a virtual-adapter conflict, or another VPN holding the route.

• Permission error at startup: Check the client service status and grant administrator privileges as required by the operating system.
• Startup succeeds but the entire network goes offline: Check default-interface detection, the DNS hijacking target, and whether routes were added correctly.
• LAN devices cannot be reached: Check whether private network ranges were incorrectly sent through the proxy. Common ranges include 192.168.0.0/16, 10.0.0.0/8, and 172.16.0.0/12.
• Some UDP applications malfunction: Confirm that the node protocol supports UDP and watch for timeouts or network-unreachable errors.
• Network does not recover after exit: Fully close the core first, then check whether the system proxy, DNS, or default route still retains old values.

Prepare a useful troubleshooting record

When reporting to a configuration provider or client project, a full-screen screenshot is often less useful than a cleaned-up text excerpt. Keep the core version, client version, operating system, time of occurrence, proxy mode, destination domain, matched policy, and consecutive error lines. You can find the mihomo core version on the client’s “About” or “Core” page, such as mihomo v1.19.x; record the client version down to the minor release.

Before submitting, remove subscription URLs, authentication parameters, node-server credentials, and LAN device names. Public destination domains, error types, and rule names usually need to remain, or it will be impossible to determine where the request failed. Use the following format:

System: Windows 11 24H2
Client: Clash Verge Rev 2.3.x
Core: mihomo 1.19.x
Mode: Rule + TUN
Time: 2026-06-02 14:32
Symptom: Browser requests to the destination domain keep timing out
Match: DomainSuffix → Proxy → Node-A
Error: dial tcp 203.0.113.10:443: i/o timeout
Comparison: Connection recovered after switching to Node-B

This record narrows the scope to Node-A or its route; there is no need to attach every background connection from several minutes of logs. If DNS may be involved, add the nameserver type, Fake-IP or Redir-Host mode, and the query failure message.

Log troubleshooting order summary

A reliable order is: first confirm that traffic entered Clash, then verify the destination and port, inspect the matched rule, policy group, and actual node, and finally read the error that follows. If the log is empty, check system-proxy or TUN interception; if the egress is wrong, check rules; if you see lookup or no such host, check DNS; for timeout, refused, TLS, or reset, then assess the node or remote route.

Info suits most situations; enable Debug briefly only when key details are missing. Restore the original setting after reproducing the issue, and keep a concise log with timestamps and version details. This avoids repeatedly changing configurations by guesswork and helps identify whether the problem lies with the client, rules, DNS, node, or destination website.