On this page
Confirm that the entire group is a batch-test false result
This article covers one Windows FlClash batch-latency anomaly: after one refresh, many nodes show Timeout, but testing any one of them separately returns a latency and selecting it allows real traffic to succeed.
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.
Divide Timeout results into two categories first
| 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
Before upgrading, export the Profile, overrides, and app settings. Record the FlClash version, Windows version, test proxy group, and test time. Subscription links can contain a token, so redact screenshots and logs.
In this comparison, change only the client version. Do not update the subscription, switch networks, enable a strict DNS override, or adjust TUN at the same time. Only unchanged test conditions can show whether the whole-group test path caused 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
Confirm on the About or Settings page whether this is Windows v0.8.95, and save a screenshot of the version.
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.
Compare an individual test with real browsing
Select a node that shows Timeout in the batch results. Run one individual latency test, switch the current policy to that node, and open a reliable webpage. Finally, check whether connection records show a successful connection and the actual egress.
Repeat with the other two red nodes. If several nodes pass individual tests or complete real requests, the batch badge does not represent node availability. Do not immediately delete the subscription, reset rules, or replace every node.
Complete a three-layer comparison
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; handle the batch Timeout as described in this article.
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.
Understand the Windows batch-test regression
issue #2314 limits the problem to the Windows desktop path in v0.8.95: batch requests can congest when sent over desktop IPC, and send failures are all shown as Timeout in the UI, so an individual node test may not reproduce the issue.
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.
This explains the specific regression in v0.8.95, but it does not prove that every FlClash Timeout comes from IPC. Continue to upgrade validation only after comparing individual tests with real requests.
Do not mix the three layers
| Layer | What you see when it fails | Does this prove the node is broken? |
|---|---|---|
| Whole-group test UI | Many nodes change to Timeout at once | No, not by itself |
| Individual node latency test | One node does not return a latency | A real request is still required |
| Real connection records | The request cannot connect or the node reports an error | Closer to actual availability |
Upgrade to FlClash v0.8.96
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.
Next, select each sample node and make a real request, then inspect connection records. The local false-result issue is resolved only when the group results recover, sample nodes return latency, and requests succeed.
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
How to branch if Timeout remains 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 setting on and off, and track the separate issue instead of treating it as the fixed regression.
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.