How to fix FlClash connection timeouts and connection failures: a step-by-step guide from subscriptions and clock sync to DNS

1. Tell node test timeouts apart from connection failures

A failed node test in FlClash doesn’t necessarily mean that no websites will load. The test sends a request to a specific URL; a blocked URL, an unexpected response, or a response that exceeds the test timeout can all result in a timeout. Conversely, a successful test only confirms that the probe worked at that moment. It doesn’t guarantee that every domain, UDP request, or app connection will work.

Before troubleshooting, capture the current state: note the FlClash version, OS version, active configuration name, outbound mode, and time of a failed attempt. Then retry the same URL using the same method, changing only one setting at a time. Menu locations may differ between versions, so use the setting names and verifiable system steps below as a guide. Example port numbers are not FlClash defaults.

Temporarily quit other proxy clients and VPNs to prevent multiple apps from changing system proxy settings or routes at the same time. If you need access to a corporate network, don’t disable managed security software without permission. Ask your administrator which connection method is approved.

2. Check that the subscription and active configuration match

After a successful update, confirm which configuration is in use

1. Open the configuration list in FlClash, find the subscription you expect to use, update it, and note the result and update time.
2. Make sure the selected configuration is the one you just updated. A new configuration appearing in the list doesn’t mean the core has switched to it.
3. Check the proxy page for the expected proxy groups and nodes. If a group is empty, review configuration load errors before changing DNS.
4. In the proxy group used by the current rule, manually select a node and test the same URL again. An automatic group may select a different outbound during testing, making the results hard to compare.

A failed subscription download and a failed node connection happen at different stages. The first is the client fetching the configuration; the second is the mihomo core connecting to a server using that configuration. An older configuration may still be running, so “the subscription update failed, but websites still load” is possible.

Use the error to guide your next step; don’t keep importing the same URL

• HTTP 401 or 403: Check whether the subscription has expired, the URL has been reset, or the service restricts access. These status codes can also come from a gateway, so check where the response originated.
• HTTP 200, but configuration parsing fails: The response may be a sign-in page, verification page, or unsupported content. A successful status code doesn’t mean the response contains a valid configuration.
• DNS lookup fails or the connection times out: First check whether the current network can reach the subscription’s domain. Whether subscription updates use a proxy depends on the client version and settings; browser results alone aren’t enough to tell.
• Some nodes disappear after an update: Check your plan status and any changes made by the provider, then review the proxy groups referenced in the configuration. Don’t keep selecting entries that are no longer available.

3. Check your network connection and system clock

Turn off the system proxy and TUN in FlClash, then check whether regular, direct web access works. If the network requires a captive portal, sign in to Wi-Fi first. You can switch your computer to a phone hotspot while keeping the configuration and test URL unchanged. If the same node fails only on one network, suspect that network’s egress restrictions, routing, or UDP support before reinstalling the client.

Clock drift can affect TLS and authentication for some protocols

Check the system date, displayed time zone, and actual time separately. A different displayed time zone doesn’t necessarily cause authentication failures, but a system clock that’s out of sync can make certificates appear not yet valid or expired. Some protocols that check timestamps may also reject the connection.

• Windows 11: Go to Settings → Time & language → Date & time, turn on Set time automatically, then select Sync now.
• Android: Go to Settings → System → Date & time and turn on automatic time. Some manufacturers place this option under Additional settings.
• macOS: Go to System Settings → General → Date & Time and make sure Set time and date automatically is enabled.

After syncing, reconnect and check whether the certificate error is gone. If the clock is correct but TLS errors persist, check the server domain, certificate, and TLS settings in the configuration. Don’t routinely skip certificate verification: it weakens server authentication and won’t fix an unreachable server.

4. Check the mixed port, core startup, and firewall

The system proxy directs proxy-aware apps to a local listening port. If mihomo isn’t running or another process has occupied that port, the browser can show that a proxy is configured but still fail to connect through FlClash. Check the client logs for address already in use, bind, or configuration load errors.

Test the explicit proxy using the actual mixed port

Find Mixed port in FlClash settings and note the value. The examples below use 7890; run them as written only if the port shown in the client is also 7890. You can substitute an HTTPS site you need to access and are permitted to use.

# Windows PowerShell: check which process is listening on port 7890
Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

# Windows: send a request explicitly through the local HTTP proxy
curl.exe -I --proxy http://127.0.0.1:7890 --connect-timeout 8 --max-time 20 https://example.com/

# macOS / Linux: check the listener and run the same request
lsof -nP -iTCP:7890 -sTCP:LISTEN
curl -I --proxy http://127.0.0.1:7890 --connect-timeout 8 --max-time 20 https://example.com/

The 8-second value is the connection timeout; 20 seconds is the total request timeout. Neither is a node quality benchmark. curl -I sends a HEAD request, which some sites may answer with 403 or 405. An HTTP response means the request reached the server response stage, but you should also check whether TLS completed and review the client’s connection logs.

• Connection refused immediately: Check that the local port is correct and the core is running. Switching remote nodes alone is unlikely to help.
• Another process is listening on the port: Identify it by process ID, exit the conflicting app normally, or change the FlClash port and update the app’s proxy settings to match. Don’t terminate an unfamiliar system process.
• Local proxy connection succeeds, then times out: Check the remote connection, rules, and DNS next, and review logs from the same time.

Allow the firewall rule for the right app and network

A firewall or endpoint security app may restrict outbound connections from the core. Review its block logs and allow the actual executable. After an upgrade, verify that the rule still applies if the file has moved. Testing the local proxy usually doesn’t require enabling Allow LAN or opening an inbound port on public networks. Don’t leave the entire firewall disabled as a workaround.

5. Use logs to tell DNS lookup failures from remote connection timeouts

At least two different domains may be involved: the proxy server’s domain and the website you’re trying to reach. If the server domain can’t be resolved, the connection fails before it reaches the proxy server. How the website domain is resolved depends on the rules, outbound protocol, and DNS settings. When you see a DNS error, first identify which domain failed, then decide which layer to check.

System lookups only test the system DNS path

# Look up the example site's system DNS results
nslookup example.com

If the system lookup also fails, first check the network connection and whether system DNS is working. If the lookup succeeds but FlClash logs still show no such host or a DNS timeout, check the DNS path used by the client core separately. nameserver, proxy-server-nameserver, and direct-nameserver in the configuration serve different purposes; a successful system lookup doesn’t confirm that all these paths work.

• Proxy server domain lookup fails: Check whether the resolver used for the proxy server’s domain is reachable. Avoid relying on a resolver that itself requires the not-yet-established proxy connection.
• DNS-over-HTTPS request times out: Check that bootstrap resolution for the resolver’s domain, its HTTPS connection, and its route are all working. Changing every resolver to the same address may make the problem affect more traffic.
• An address in the 198.18.0.0/15 range appears: In Fake-IP mode, this may be an expected mapping. The address format alone doesn’t mean DNS resolution failed.
• Only one website has a problem: Check the rule matched for that domain, its DNS response, and the destination service status. Avoid changing the entire configuration to fix one site.

After changing DNS, use the client’s reload or core restart option to apply the configuration, then close existing connections and test again. Windows ipconfig /flushdns only clears the system DNS cache; it doesn’t clear the mihomo DNS cache or existing connections. Change one setting at a time and keep a restorable copy of the original configuration.

6. Check outbound mode, rule matches, and TUN coverage

Use Global mode to narrow down failures in Rule mode

In Rule mode, rules are checked from top to bottom, and the first match determines the outbound. If a browser request matches DIRECT, it may bypass the selected node even if the node test succeeds. Open the client’s connection log and check the destination domain, matched rule, and final outbound to see where the request actually went.

1. Keep the same node and test URL, switch briefly to Global mode, and make sure the global proxy group has that node selected.
2. If Global mode works but Rule mode fails, check whether the matching rule points to the wrong proxy group, DIRECT, or REJECT.
3. If both modes fail, continue checking the server connection and DNS; don’t just reorder the rules.
4. Restore the original mode after testing. Global mode is useful for comparison, but it isn’t suitable for all traffic.

System proxy and TUN solve different problems

If an explicit proxy test succeeds but an app still can’t connect, check whether the app follows the system proxy. Some apps make connections directly or use UDP, so enabling the system proxy won’t automatically route their traffic through the client. TUN can capture more traffic through a virtual network interface, but routing, permissions, and exclusion rules still apply. It doesn’t guarantee that every connection will be captured.

Before enabling TUN, make sure the regular proxy connection works. Desktop systems may require administrator permissions or service support. Android requires VPN permission and generally can’t run another VPN-based app at the same time. If enabling TUN cuts off network access for the whole device, turn it off to restore connectivity, then check for conflicts involving the virtual interface, routes, or other VPNs. Don’t change TUN, DNS, and rules all at once, or it’ll be hard to tell which setting made a difference.

7. Summarize the findings: when to switch nodes and when to share logs

After these checks, you should be able to identify the layer causing the problem, rather than just concluding “FlClash doesn’t work.” If one node fails on multiple networks while other nodes work, ask the provider to check the server status and credentials. If all nodes fail only on one network, focus on local network restrictions. If the explicit proxy works but the system proxy doesn’t, check whether another app has overridden the system settings.

Keep these six details before reporting an issue

• FlClash and OS versions, plus the mihomo core version shown in the logs.
• When the failure occurred and your time zone, so the provider can check its server logs.
• Whether the subscription updated successfully and the current configuration loaded successfully.
• Whether the system proxy and TUN are enabled, the actual mixed port, and the current outbound mode.
• Results for the same URL using the explicit proxy, Rule mode, and Global mode.
• A short section of logs covering a failed attempt. Redact subscription tokens, account credentials, and any addresses you shouldn’t share publicly.

To review the initial setup, start with the getting started guide. To continue troubleshooting based on symptoms, see troubleshooting. Before updating the client, keep your current configuration and key settings. Repeat the same tests after updating to find out whether the version or configuration made a difference.