本文目錄
確認是整組測速誤報
本文只處理 Windows 版 FlClash 的整組延遲測試異常：一次重新整理後大量節點顯示 Timeout，但點開其中一個節點單獨測試能回傳延遲，選中它也能完成實際存取。
官方 issue #2314 在 v0.8.95 上記錄了這一組對照，同一份設定和網路回到 v0.8.94 後批次測試正常。v0.8.96 的發布說明隨後明確列出 Windows 整組延遲測試修復。
如果單節點測試、實際請求和同組其他節點都失敗，不能把它當成介面誤報。此時更可能是節點、測試位址、DNS 或目前網路真的不可用。
先把 Timeout 分成兩類
| 觀察結果 | 更可能的結論 | 下一步 |
|---|---|---|
| 批次顯示 Timeout，單獨測試和實際存取正常 | Windows 整組測速誤報 | 記錄版本並準備升級 |
| 批次與單獨測試都失敗，實際存取也失敗 | 節點或網路故障 | 轉查節點、DNS 與測試位址 |
| 只有一個代理群組異常 | 該組規模或設定差異 | 固定同一組做版本對照 |
| 開啟 TUN 後整機斷網 | 不是測速顯示問題 | 先恢復系統代理並檢查 TUN |
儲存設定並固定測試條件
升級前先匯出 Profile、覆寫與應用設定，記錄 FlClash 版本、Windows 版本、測試代理群組和測試時間。訂閱連結可能包含 token，截圖和日誌中必須脫敏。
本輪只改變用戶端版本，不同時更新訂閱、切換網路、開啟嚴格 DNS 覆寫或調整 TUN。測試條件不變，才能判斷 Timeout 是否由整組測速鏈路造成。
準備一組可重複的樣本
備份目前 Profile
保留訂閱來源、覆寫與目前策略選擇，確認備份可以在本機找到。
記錄應用版本
在關於或設定頁面確認是否為 Windows v0.8.95，並儲存版本截圖。
固定一個代理群組
選擇包含較多節點、能夠穩定復現大量 Timeout 的同一代理群組。
挑選三個紅色節點
記錄節點名稱，後續分別做單獨測試、實際存取和升級後的重新測試。
用單獨測試與實際存取做對照
從批次結果中選一個顯示 Timeout 的節點，先單獨點一次延遲測試，再把目前策略切到它並開啟一個穩定網頁。最後查看連線記錄是否出現成功連線和實際出站。
再用另外兩個紅色節點重複。若多個節點都能單獨測試或完成實際請求，說明批次徽章不能代表節點存活狀態；不要立即刪除訂閱、重置規則或更換全部節點。
完成三層對照
單獨測試節點
等待本次結果完成，不連續按一下整組重新整理，記錄是否回傳具體延遲。
固定目前節點
在手動選擇組中選中該節點，避免自動策略在請求期間切換出口。
發起實際請求
開啟平時可穩定存取的頁面，並觀察是否載入完成。
核對連線記錄
確認請求進入 FlClash，並顯示剛才選擇的節點和成功連線。
單獨測試有延遲，實際請求成功
節點可用，批次 Timeout 可以按本文處理。
單獨測試失敗，實際請求成功
檢查延遲測試位址與測試鏈路，不要按節點故障刪除。
單獨測試成功，實際請求失敗
轉查規則、DNS、協議和目標網站，不是單純批次測速問題。
兩者都失敗
先換網路或固定其他節點，按通用節點超時流程檢查。
理解 Windows 批次測試回歸
issue #2314 把問題限定在 v0.8.95 的 Windows 桌面鏈路：批次請求透過桌面 IPC 傳送時可能擁塞，傳送失敗又被介面統一顯示為 Timeout，因此單節點測試不一定復現。
官方修復提交減少了每批併發節點數量，並調整桌面 RPC 的等待與回應處理。這個改動位於 FlClash 的批次測試鏈路，不是更換節點協議或修改訂閱內容。
這能解釋 v0.8.95 的特定回歸，但不能證明所有 FlClash Timeout 都來自 IPC。只有完成單獨測試與實際請求對照，才適合繼續升級驗證。
三個層次不要混在一起
| 層次 | 失敗時看到什麼 | 能否說明節點損壞 |
|---|---|---|
| 整組測速介面 | 大量節點同時變成 Timeout | 不能單獨證明 |
| 單節點延遲測試 | 一個節點無法回傳延遲 | 仍需實際請求 |
| 實際連線記錄 | 請求無法建立或節點發生錯誤 | 更接近實際可用性 |
升級到 FlClash v0.8.96
FlClash v0.8.96 於 2026 年 8 月 17 日發布，官方說明明確包含 Windows 整組延遲測試失敗修復。符合前述特徵時，應優先升級到 v0.8.96 或更新的穩定版。
從專案官方 Release 取得與 Windows 架構匹配的安裝套件。不要關閉安全軟體或忽略來源告警來強行安裝；無法核對檔案來源時，先留在目前可用版本。
按可還原順序升級
確認備份可用
檢查 Profile、覆寫和目前選擇已經匯出，並記錄舊版本安裝套件位置。
完全退出 FlClash
從系統匣退出應用，避免舊處理程式仍持有核心、設定或桌面服務。
安裝官方穩定版
從官方 Release 選擇正確架構，完成安裝後再啟動應用。
核對版本與設定
確認顯示 v0.8.96 或更新穩定版，原 Profile 與策略選擇仍然存在。
用同一代理群組驗證修復
保持原網路、訂閱、測試位址和代理群組不變，再執行一次整組延遲測試。重點觀察升級前記錄的三個紅色節點，不能只看整體顏色變少。
隨後逐個選擇這些節點發起實際請求，並查看連線記錄。整組結果恢復、樣本節點有延遲且請求成功，才能確認本機的批次誤報已經閉環。
修復完成標準
- 應用版本為 v0.8.96 或更新穩定版
- 同一代理群組不再大面積同時顯示 Timeout
- 升級前記錄的樣本節點能夠回傳延遲
- 至少一個樣本節點完成實際網頁請求
- 連線記錄顯示請求使用了目前選擇的節點
- 訂閱、覆寫、DNS 與 TUN 設定沒有被意外重置
升級後仍有 Timeout 怎麼分流
少量不可用節點並不等於修復失敗。穩定版只處理已確認的 Windows 整組測試問題，實際節點下線、測試位址不可達、DNS 異常和目前網路限制仍會產生正常的 Timeout。
官方 issue #2253 還記錄了嚴格 DNS 覆寫開啟後批次測速異常的另一種情境，它沒有被證明與 v0.8.95 的 IPC 回歸完全相同。不要為追求全綠長期關閉必要的 DNS 設定。
只有少數固定節點失敗
分別單獨測試併發起實際請求，確認節點或測試位址是否不可達。
批次與單獨測試仍全部失敗
檢查測試 URL、DNS、系統時間和目前網路，再換熱點對照。
只在嚴格 DNS 覆寫開啟時異常
儲存設定後做開關對照，並跟蹤獨立 issue，不把它歸為已修復回歸。
開啟 TUN 後所有請求中斷
先關閉 TUN 恢復系統代理，再檢查路由、虛擬網路介面卡和 DNS 劫持。
介面正常但自動組仍選錯
查看核心的健康檢查位址、間隔與策略群組類型。
異常時還原到已知可用版本
若 v0.8.96 在本機無法啟動、Profile 丟失或引入新的實際連線故障，先完全退出應用，再恢復升級前備份。不要在執行中反覆覆蓋設定目錄。
issue #2314 的對照環境中，v0.8.94 的整組測試正常，因此它可以作為該特定回歸的臨時還原點。還原會失去 v0.8.96 的修復，不應成為長期停止更新理由。
恢復可用狀態
退出全部處理程式
確認系統匣、介面和核心都已退出，再開始更換版本。
安裝已驗證舊版
使用升級前保留的官方安裝套件，必要時回到本機已驗證的 v0.8.94。
恢復設定備份
只恢復自己的 Profile 與覆寫，不匯入來源不明的完整目錄。
驗證實際連線
先用系統代理完成一次請求，再檢查整組測速與連線記錄。