FlClash Log Errors Explained

Isolate a single failed request first

FlClash logs usually come from the Clash Meta (mihomo) core and the client itself. A warning in the log does not necessarily mean the proxy is down: background apps, node health checks, subscription updates, and browser requests can all generate log entries at the same time. Start troubleshooting by matching one failed log entry to a specific action.

1. Note the active profile, outbound mode, selected policy-group node, and whether the system proxy and TUN are enabled.
2. Open the FlClash log, pause other downloads, and visit a single URL that reliably reproduces the issue.
3. Note when you performed the action and keep about 10 seconds of logs around it. Look for the destination domain and port, matched rule, policy group, and final outbound.
4. Change one setting at a time, then retry the same URL. For example, switch nodes first without also changing DNS or the TUN stack.

The logs below illustrate field meanings; they are not from a real-world test. Field order and wording may vary by core version. 192.0.2.10 is a documentation-only address, not a reachable node. 127.0.0.1:7890 is also an example local port; replace it with the port your current configuration actually listens on.

Log levels: check the request before the severity

Common mihomo log-level values include debug, info, warning, error, and silent. The level controls how much is logged; it does not identify the cause. A warning might be a failed health check, while an info entry could reveal that a request took the wrong outbound route.

To get more detail, temporarily change the log level in the client settings. If you edit the configuration, check that the effective config contains log-level: debug. Avoid editing only a cached subscription file: the client may regenerate the configuration or overwrite your changes when the subscription updates. When you're done troubleshooting, switch back to info to limit ongoing request logging.

dial tcp timeout: identify the remote endpoint

dial tcp 192.0.2.10:443: i/o timeout
dial tcp 127.0.0.1:7890: connect: connection refused

dial tcp means a TCP connection is being established. The key detail is not just the subsequent timeout, but whether the preceding address belongs to a proxy node, a directly accessed destination, or the local proxy service. When traffic goes through a proxy, the error may show the node server's address; with DIRECT, it may show the destination website's address. This line alone does not prove that a website is blocked or a subscription is invalid.

i/o timeout vs. connection refused

• i/o timeout: A connection or related network operation did not complete before the deadline. An unreachable node, packet loss, routing problems, or a firewall silently dropping traffic can all cause a timeout.
• connection refused: The connection was actively rejected. Common causes include no service listening on the port, a mismatched server port, or a device explicitly refusing the connection.
• network is unreachable: The system has no usable route to the destination network. If this appears only for IPv6 addresses, check local IPv6 connectivity separately.

Narrow it down with two comparisons

Keep the network unchanged, manually select another node, and make a new request. If only one node keeps timing out, check that node's server address, port, and service status first. Then keep the node unchanged and switch from Wi-Fi to a mobile hotspot. If the issue occurs only on the original network, focus on the local connection or ISP route. These comparisons can narrow down the cause, but cannot by themselves prove which device is at fault.

A successful node latency test does not mean every website will load. The test usually checks a specific probe address over a single connection path; it is not a substitute for a real request. After switching policy groups, existing long-lived connections may still use the previous outbound. Reload the page or establish a new connection before drawing conclusions.

DNS resolution failures: distinguish node domains from website domains

lookup example.com: no such host
dns resolve failed: context deadline exceeded

no such host usually means the resolver reports that the name does not exist or could not return a usable address. context deadline exceeded means the operation exceeded its deadline; it is not specific to DNS, so check nearby DNS fields for context. First determine whether the failed domain belongs to the node server or the destination: the impact differs.

Node server domain fails to resolve

The node address must resolve before a proxy connection can be established. If the DNS upstream used to resolve it is itself configured to go through that node, you may create a dependency loop. Check node-domain resolution settings such as proxy-server-nameserver in the effective configuration, and make sure the relevant DNS upstream has a reachable bootstrap path. Do not blindly route every DNS request through a proxy that is not yet connected.

Website domain fails to resolve

Check nameserver and nameserver-policy in the dns section, as well as fallback if configured. If respect-rules is enabled, also check which rules DNS requests follow. DoH uses HTTPS, but setting an address to https:// does not guarantee it is reachable on your current network.

• Only one domain fails: check its spelling, domain-specific DNS policies, and the upstream response.
• All destination domains fail but the node connects: check destination DNS resolution and the DNS upstream first.
• Failures begin only after enabling TUN: check DNS hijacking, the system resolver, and interactions with other network software.

Handshake failures: distinguish certificates, protocols, and disconnects

tls: failed to verify certificate: x509: certificate has expired or is not yet valid
tls: first record does not look like a TLS handshake
EOF

A successful TCP connection only confirms that the transport-layer endpoint is reachable. The node protocol, TLS, authentication, or connection to the destination website can still fail later. A TLS error in the logs may come from proxy transport, a DNS upstream, or another HTTPS request, so identify what the error refers to first.

• Certificate expired or not yet valid: Check the system date, time, and time zone first, then check the certificate's validity period on the server. An incorrect device clock can also cause validation to fail.
• Certificate name mismatch: Check that the node's servername, the actual server certificate, and the subscription parameters agree. Do not substitute the server IP for a required domain name.
• First record does not look like TLS: The connection may have reached a non-TLS service, or an intermediary may have returned different content. Check the port and TLS setting; this message alone does not mean the password is wrong.
• EOF or connection reset by peer: The remote end closed the connection or it was reset. Neither message explains why; check the logs before and after the handshake and the server status.

If all similar nodes fail right after a subscription update, first confirm that the bundled core supports the protocol and its parameters, then check the requirements from the subscription provider. Do not treat skip-cert-verify: true as a general fix: skipping certificate verification weakens identity checks and will not resolve a wrong port, authentication, or transport type.

Rule not matched: check the mode, then the final outbound

“Rule not matched” is often a user's description of what happened, not a specific core error. In Rule mode, rules are generally checked in order, and the matching rule selects a policy. GLOBAL and DIRECT modes do not route traffic through the regular rule list in the same way. Check the current mode first, then inspect the matched rule type and policy chain in the connection log.

proxy-groups:
  - name: Web
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,Web
  - MATCH,DIRECT

This illustrates how rules relate; it is not a complete, usable subscription. A request to www.example.com matches DOMAIN-SUFFIX and enters the Web policy group, but that group contains only DIRECT here, so the final route is still direct. In other words, matching a proxy group does not mean traffic goes through a remote proxy node. Check the group's current selection rather than stopping at the rule name.

• The log shows a MATCH rule: check whether an earlier rule takes precedence for the domain, whether external rule sets loaded successfully, and whether the app preserved the domain name when it connected.
• A domain rule does not match: the app may have connected directly to an IP address. Sniffing cannot recover domain names for every protocol, so do not count on it as a guaranteed fix.
• The rule points to REJECT: check whether the traffic is meant to be blocked. Address the rule's intent rather than switching nodes first.
• Traffic still follows the old route after a change: make sure the updated Profile is active, then test with a new connection.

To review how rules reference one another, see the rules guide in Advanced Config. Before editing subscription rules, confirm how your changes are persisted so a subscription update does not overwrite them.

TUN and port issues: check the local entry point

listen tcp 127.0.0.1:7890: bind: address already in use
operation not permitted

address already in use means another process is using the same listening address and port. Exit other proxy clients, check whether an old process is still running, then confirm FlClash's actual port. If you change the listening port, also update the system proxy and any apps with a manually configured proxy address; changing just one number in the config is not enough.

If operation not permitted appears while creating a virtual network interface or changing routes, check permissions first. TUN on desktop systems may require administrator approval or a companion service from the client; Android usually requires VPN connection permission. Other VPN or security software may also be intercepting network traffic.

1. Note the current state, then temporarily turn off other VPNs and proxy clients.
2. Turn off TUN and test a browser using only the system proxy to see whether the node and basic proxy entry point work.
3. Then enable TUN by itself and check for interface, permission, or routing errors.
4. If only TUN fails, focus on the local traffic interception path. Do not immediately reset all subscriptions and DNS settings.

A successful system proxy test confirms only that the tested app's route works; it does not prove that all UDP traffic, games, or background apps will work. Compare TUN stacks based on the operating system and core support. There is no single option that works best on every device.

When sharing troubleshooting details: include context and redact credentials

Useful reports should make the issue reproducible, not just attach a screen full of errors. Include the operating system and architecture, FlClash version, core version, current mode, TUN status, time of failure, and the results of testing another node and another network. Use the version shown in the client; the article date is not a guide to software versions.

• Action: For example, “Opened the same HTTPS URL; a new connection failed after about 10 seconds.” Use the time you actually observed.
• Scope: Does one node fail or do all nodes fail? Does one website fail or do most websites fail?
• Logs: Include relevant entries from before and after the failure, including the rule, outbound, and final error. Do not share only the last line.
• Privacy: Redact subscription links, tokens, passwords, UUIDs, and sensitive domains. Do not publish a complete subscription configuration.

Finally, trace the issue by stage: no request in the logs—check the traffic entry point; node domain fails to resolve—check the bootstrap resolution path; node TCP connection times out—check the node and network; handshake fails—check the protocol and certificate; outbound differs from expectations—check the mode, rules, and policy group. Following one request through each stage is more likely to produce a repeatable diagnosis than changing several settings at once.