On this page
Many timeout messages in the list do not necessarily mean every subscription node is broken. Compare the batch display, individual latency tests, and actual web access. If real requests still succeed, do not rush to delete nodes or reset the configuration. Record the same sample group, confirm that the known version issue applies before upgrading, then check that both the display and connections recover.
The whole group shows Timeout, but individual nodes and webpages work
In FlClash for Windows, save the group’s Timeout results, test one of its nodes individually, then select it and open a web page. The pattern described here applies only if the individual test returns a latency value and real access also succeeds.
Official issue #2314 documents this comparison on v0.8.95; batch tests work with the same configuration and network after returning to v0.8.94. The v0.8.96 release notes later explicitly listed a fix for Windows whole-group latency testing.
If an individual node test, real request, and other nodes in the same group all fail, do not treat it as a UI false result. The node, test address, DNS, or current network is more likely genuinely unavailable.
Timeout comparisons and what to do next
| Observed result | More likely conclusion | Next step |
|---|---|---|
| Batch test shows Timeout, while the individual test and real request work | False results from Windows whole-group testing | Record the version and prepare to upgrade |
| Both batch and individual tests fail, and real browsing fails | Node or network failure | Investigate the node, DNS, and test address |
| Only one proxy group is affected | A difference in the group's size or configuration | Use the same group for a version comparison |
| The entire computer loses connectivity after TUN is enabled | This is not a latency-test display issue | Restore the system proxy first, then troubleshoot TUN |
Save the configuration and hold test conditions constant
For a version comparison, change only the client version. Keep the subscription, network, strict DNS override and TUN settings unchanged so you can tell whether group latency testing is responsible for Timeout.
Prepare a repeatable sample group
Back up the current Profile
Keep the subscription source, overrides, and current policy selection, and confirm that the backup is available locally.
Record the app version
On the About or settings page, record the FlClash and Windows versions, check whether it is v0.8.95, and save the test time and a version screenshot.
Pin one proxy group
Choose the same group with many nodes that reliably reproduces a large number of Timeout results.
Select three red nodes
Record their names for individual tests, real requests, and post-upgrade retesting.
Test each red node and its actual outgoing connection
Follow the steps below for one red node, then repeat them for two others. If multiple nodes pass individual tests or complete real requests, the batch display does not tell you whether the nodes are usable. Do not immediately delete the subscription, reset rules, or replace every node.
Compare individual latency tests, real access, and connection records
Test the node individually
Wait for this result to finish; do not repeatedly refresh the entire group. Record whether a specific latency is returned.
Pin the current node
Select the node in a manual-selection group so an automatic policy cannot change the egress during the request.
Make a real request
Open a page that is normally reliable and see whether it finishes loading.
Check connection records
Confirm that the request enters FlClash and shows the selected node and a successful connection.
The individual test returns a latency, and the real request succeeds
The node works; investigate batch Timeout as a group-testing problem.
The individual test fails, but the real request succeeds
Check the latency-test address and test path; do not delete the node as broken.
The individual test succeeds, but the real request fails
Investigate rules, DNS, protocol, and the destination website; this is not just a batch-testing problem.
Both fail
Switch networks or pin another node first, then follow the general node-timeout workflow.
Upgrade to FlClash v0.8.96
IPC is how the desktop app communicates with its background process. In issue #2314, the problem affects Windows batch tests in v0.8.95: congestion or a request that fails to send can appear as Timeout in the interface, while individual node tests may not reproduce it.
The official fix reduces the number of concurrent nodes per batch and adjusts waiting and response handling in the desktop RPC. This change is in the FlClash batch-test path, not in the node protocol or subscription contents.
FlClash v0.8.96 was released on 8/17/2026, and the official notes explicitly include the Windows whole-group latency-test fix. If the earlier symptoms match, upgrade first to v0.8.96 or a newer stable release.
Download the installer matching your Windows architecture from the project's official Release. Do not disable security software or ignore source warnings to force installation. If you cannot verify the file's source, remain on the current working version.
Upgrade in rollback-safe order
Confirm the backup is usable
Check that the Profile, overrides, and current selections were exported, and record the location of the old installer.
Exit FlClash completely
Quit the app from the system tray so the old process does not retain the core, configuration, or desktop service.
Install the official stable release
Choose the correct architecture from the official Release, finish the installation, and then start the app.
Verify the version and configuration
Confirm that v0.8.96 or a newer stable release is shown and that the original Profile and policy selection remain.
Validate the fix with the same proxy group
Keep the original network, subscription, test address, and proxy group, then run one whole-group latency test. Focus on the three red nodes recorded before the upgrade; do not look only for an overall reduction in red badges.
Then select each of these nodes, make a real request, and check the connection records. Only when the group’s results return to normal, the sample nodes return latency values, and requests succeed can you confirm that the incorrect batch results on this computer have been resolved.
Completion criteria
- The app is v0.8.96 or a newer stable release
- The same proxy group no longer shows widespread Timeout at once
- The sample nodes recorded before the upgrade return latency
- At least one sample node completes a real webpage request
- Connection records show that the request used the currently selected node
- The subscription, overrides, DNS, and TUN settings were not reset unexpectedly
Where should you look if Timeout persists after upgrading?
A few unavailable nodes do not mean the fix failed. The stable release addresses only the confirmed Windows whole-group test issue; nodes that are actually offline, an unreachable test address, DNS problems, and current network restrictions can still produce legitimate Timeout results.
Official issue #2253 records another batch-test scenario after a strict DNS override is enabled; it has not been shown to be identical to the IPC regression in v0.8.95. Do not disable required DNS settings indefinitely just to make every badge green.
Only a few specific nodes fail
Test each one individually and make a real request to confirm whether the node or test address is unreachable.
Both batch and individual tests still fail for every node
Check the test URL, DNS, system time, and current network, then compare on a mobile hotspot.
The problem occurs only with a strict DNS override enabled
Save the configuration, compare with the switch on and off, and follow the separate issue. Do not classify it as the already fixed group latency-test failure.
Every request stops after TUN is enabled
Disable TUN first to restore the system proxy, then inspect routing, virtual adapters, and DNS hijacking.
The UI works, but an automatic group still chooses the wrong node
Inspect the core's health-check address, interval, and policy-group type.
Roll back to a known working version if the upgrade causes problems
If v0.8.96 does not start on this machine, the Profile disappears, or a new real connectivity failure appears, exit the app completely and restore the pre-upgrade backup. Do not repeatedly overwrite the configuration directory while it is running.
In the comparison environment from issue #2314, whole-group tests worked on v0.8.94, making it a temporary rollback point for this specific regression. Rolling back gives up the v0.8.96 fix and should not become a reason to stop updating permanently.
Restore a working state
Exit every process
Confirm that the tray app, UI, and core have all exited before changing versions.
Install the verified older release
Use the official installer saved before the upgrade, returning to the locally verified v0.8.94 if necessary.
Restore the configuration backup
Restore only your own Profile and overrides; do not import an entire directory from an unknown source.
Validate a real connection
Complete one request with the system proxy first, then check the whole-group test and connection records.