本文目錄
能上網卻測不出延遲時，測速結果與實際連線需要分別記錄。訂閱更新後，舊選擇可能仍指向已改名的節點；保留原設定，從介面重選現有節點、等待儲存，並重新啟動檢查，才能確認新選擇在重新啟動後仍保留。
訂閱更新後能上網，為什麼節點頁仍顯示 Timeout？
記錄訂閱改名前後，FlClash 是否仍能開啟網頁，以及同一手動選擇群組與引用它的上層群組是否持續顯示 Timeout。這裡的測速是對測試位址探測延遲，不是頻寬測試。
專案 issue #2635 在 Windows 的 FlClash 0.8.99+2026100301 上報告了這種現象。本次核對時它仍是使用者報告，沒有維護者確認的通用修復版本；現有定位與恢復建議依據 v0.8.99 原始碼，不能把所有 Timeout 歸為同一原因。
v0.8.99 測試 select 群組時，會先讀取 Profile 中的 selectedMap，也就是先前儲存的節點名稱，再找到真正要測試的節點。舊名稱已不在目前配置時，找不到測試對象也會回傳 value: -1；這不能單獨說明實際網路等待逾時。
適用線索是：同一 Profile 更新後節點名稱改變，實際請求仍經過預期代理成功，異常集中在原選擇組或引用它的組。已知報告來自 Windows；其他平台只能在自己的名稱與請求對照吻合後參考，不能推斷全部平台受影響。
節點單獨測試、組測與實際請求的對照
先建立本機備份，保留目前的 Profile、覆寫與設定，記錄完整客戶端版本、群組名稱、改名前後的節點名稱及測試網址。訂閱連結可能包含認證資訊，備份與原始設定檔只留在本機。
固定使用同一網路、Profile 與測試網址，在節點頁展開有問題的手動選擇群組，確認新名稱確實出現在目前成員清單中。分別對新節點與這個群組執行一次延遲測試，等這次測試完成再比較，避免連續批次重新整理掩蓋差異。
使用該群組目前的選擇，開啟平時可用的 HTTPS 網頁，並查看 FlClash 連線記錄。只有請求進入 FlClash、使用預期的代理且完成存取，才能作為連線正常的比對依據；瀏覽器繞過代理後成功開啟網頁不算。
若看得到的日誌提到舊節點名稱不在 applied config 中，請與目前成員清單比對。看不到這則日誌也不代表沒有保留舊選擇，單一失敗數值同樣無法確定原因。不要為了蒐集證據直接操作資料庫，或把控制介面開放到區域網路。
不同結果應採取不同排查方式
| 對照結果 | 下一步 |
|---|---|
| 新節點單獨測試成功，原群組測試失敗，實際代理請求成功 | 優先確認群組儲存的選擇，依照下一節從介面重新選擇現有成員。 |
| 新節點與群組測試都失敗，實際代理請求也失敗 | 改查節點、測試網址、DNS 與目前網路，不要直接歸因於舊名稱。 |
| 實際請求正常，多個獨立節點都無法連到同一測試網址 | 檢查目前網路或規則是否阻擋測試網址；換成另一個可信且已確認可連線的網址做比對。 |
| Windows 上舊版 FlClash 僅整批測試失敗，單節點測試正常，且未曾更改節點名稱 | 參考本站的批次延遲測試文章，區分 v0.8.95 的既有問題。 |
從介面重新選擇現有成員，並確認是否已儲存
在節點頁重新選擇目前清單中的有效節點，等待儲存和切換完成。若出現資料庫寫入失敗或切換失敗通知，停止重複點選並保存錯誤。
v0.8.99 會將選擇存入 selectedMap，也會在儲存或核心切換失敗時還原。只重啟程式未必能清除舊紀錄；按下方步驟重選後再確認，但不要把 v0.8.99 當成這份回報的已確認修復。
保留原設定的復原順序
選擇有效的新名稱
在出問題的 select 組中，主動點選目前清單裡的一個有效新節點。若上層組引用這個手動組，先修正底層選擇，再確認上層仍指向你需要的組；不要把自動組改成手動組來繞過問題。記錄新名稱，不選已經從訂閱移除的舊項。
確認儲存時沒有錯誤
等待選擇操作完成，檢查目前群組與應用程式通知。若出現寫入或切換失敗，停止重複點擊並保留原始錯誤。
重新測試節點與群組
使用原測試網址，分別測試新節點、手動群組及受影響的上層群組，並再次確認實際 HTTPS 請求的出站路徑。
完整結束程式後再檢查
透過應用程式或系統匣正常結束程式，再重新啟動。確認選擇仍是有效的新名稱，重做同一群組的測試與實際請求。只有結束程式後仍能正確保留選擇，才記錄為本機已復原。
重新選擇仍未儲存時，保留原 Profile 做獨立比對
若重新啟動後又出現舊選擇，先保留備份與原 Profile。透過正常的新增檔案或 URL 匯入入口，將同一個可信訂閱新增為另一個 Profile，使用不同且容易辨識的名稱；不要刪除原項目，也不要藉由還原整份應用程式備份來建立這個比對。
v0.8.99 的新匯入會建立獨立 Profile，儲存的選擇預設為空，可與原 Profile 持續保留的選擇比對。訂閱本身包含的規則仍會隨內容匯入，但不能假設舊 Profile 綁定的額外規則、腳本或自訂設定已經移轉；應用程式層級的覆寫也可能影響副本，應先核對實際執行的設定。
先檢查新副本的節點清單與必要規則，再選擇有效成員，準備妥當後才短暫切換驗證。若副本正常而原項目可重現問題，可將副本保留為暫時復原選項，並逐項核對必要的自訂設定；這仍無法取代維護者對根本原因的確認。
如果新副本也失敗，還原先前可用的 Profile 與本次更改的設定。停止 FlClash 接管後，確認一般網路可用；必須透過代理的業務則先暫停存取，避免把直接連線視為同等的復原方式。不要清空全部資料、手動修改資料庫、關閉安全軟體，或保證重新安裝舊版能解決問題。
怎麼確認已復原，並向上游提供失敗證據？
復原結果應同時符合：名稱正確、延遲測試與實際請求的比對結果合理，以及完整結束程式後仍保留選擇。綠色的延遲數值只代表一次探測成功，不代表所有網站與協定都能使用；即使測試網址無法連線，實際請求正常也應另外記錄。
若仍異常，向 FlClash 專案回報完整版本、系統版本、節點改名前後的對應關係、目前群組成員、同一網址的單節點與群組測試、實際請求的出站路徑，以及從介面重新選擇和結束程式再重啟後的結果。公開資料中，群組與節點應使用一致的占位名稱，遮蓋訂閱認證資訊、密碼、個人位址與控制介面的 secret。
與 issue #2635 特徵一致可補充脫敏對照；若是 YAML 無效、節點本身斷連或純批次失敗，應單獨描述差異。