本文目錄
要確認選中了哪個出口，名稱和延遲數字都不夠。同名節點可能來自不同的集合，介面能點選後，也要用新請求查看實際出口。保留目前設定，依來源核對群組成員，才能判斷升級是否解決了自己的選擇問題。
節點變灰並顯示 ambiguous，是訂閱出問題了嗎？
在 Clash Verge Rev 節點頁記錄 ambiguous 提示、變灰無法選擇的項目，或測速對應另一來源的節點。接著確認這些節點是否由多個代理集合提供，而且名稱相同。
2026 年 10 月 9 日發布的官方 v2.5.8 明確修復這兩類問題。issue #8021 有舊版使用者回報：節點無法點選，但原有連線仍可使用。這份回報不代表所有灰色節點都屬於同一問題，也不能據此斷言所有舊版本與平台都受影響。
對應線索是執行設定含多個 proxy-providers、不同來源節點重名，並出現介面或測速差異。若集合未載入、節點本身不可用或設定解析失敗，應先處理對應錯誤，不把它們統稱為 ambiguous。
核對 Provider 範圍並匯出獨立備份
記錄完整用戶端版本、系統、目前的 Profile、異常代理群組及同名節點。對照訂閱原文與執行中的設定：proxy-providers 下的集合名稱、各集合的節點名稱，以及異常代理群組的 use 清單。集合鍵名重複屬於另一種設定錯誤，不能靠升級修正。
同時檢查 include-all-providers、include-all 與 exclude-type。在固定版本的實作中，前兩項會納入所有集合，不能宣稱只填 use 就能隔離來源；排除類型也會改變候選節點。沒有這些條件時，再依代理群組本身使用的集合範圍比較。
先確認集合已載入且確實存在同名節點，再分別測試該節點與代理群組，使用同一個可信的測試位址記錄結果。透過原本的選擇發出新的 HTTPS 請求，查看連線記錄是否經過預期的代理群組與出站節點；瀏覽器略過代理後連線成功，不能作為對照。
在設定中的 Verge 進階設定開啟備份設定，在手動備份選擇本機備份並建立紀錄，再從查看紀錄匯出這份升級前的備份，存到應用程式資料目錄之外。介面譯文可能不同；只建立本機紀錄，不等於已取得獨立的離線副本。
官方備份實作包含 profiles 內的一般檔案與應用程式設定，但不是整個資料目錄的鏡像備份。外部 Provider 檔案及其他自行管理的資源，應另外保存安全副本；訂閱權杖、密碼和原始備份只留在自己的裝置上，不作為公開錯誤回報的附件。
不要因為介面異常就刪除仍在工作的訂閱。
升級 v2.5.8 後，如何確認選擇與延遲測試已恢復？
v2.5.8 會按策略群組實際使用的 Provider 查找節點，避免把其他集合的同名節點誤當成本群組成員。它調整的是用戶端對群組成員與來源的對應關係；同一群組中的兩個完全同名出口能否分別選取，仍要用實際連線確認，不能只看顯示恢復。
從文末的官方 Release 取得符合系統與架構的 v2.5.8，依專案正常的升級方式操作，保留設定及已匯出的備份。本站提供的用戶端備份版本與上游最新版本是不同紀錄；不能用本站的舊備份版本代替這次修復版本的查核。
使用原設定驗證修復
確認實際執行的版本
升級並正常啟動後，在應用程式內核對完整版本為 v2.5.8；不要只憑安裝檔名稱判斷。保持使用同一個 Profile 與原代理模式。
檢查代理群組成員並主動切換
重新套用設定，等待集合載入結束，再開啟原本異常的代理群組。確認原 ambiguous 項目已可使用，成員符合本組的 Provider 範圍；點選目標可用節點，等待切換完成並核對目前的選擇。
分別測試節點與代理群組
用原測試位址分別測試相關節點與代理群組，等這輪測試結束再比較。延遲數字只是探測結果，不能證明實際業務連線已使用對應來源。
用新連線驗證，再重新啟動檢查
關閉舊測試連線後發出新的 HTTPS 請求，查看請求依序經過的策略群組和實際出口；若已有可驗證的出口資訊，也一併對照。正常結束後重新啟動，再核對節點、選擇和新請求。
若同一組仍含有來自多個集合、名稱完全相同的節點，介面可以點選，也不能證明能獨立切換到第二個出站節點。v2.5.8 的選擇呼叫仍傳入代理群組名稱與節點名稱；證據不足時應記為尚未確認，不要用重複的延遲測試或既有長連線推斷切換成功。
若升級後集合仍為空，或出現下載、解析錯誤，先保留第一條錯誤並排查集合來源。若成員與選擇已正確，但新請求失敗，再檢查節點連線、規則及測試目標，不要繼續將所有失敗歸因於用戶端的成員對應。
同一組需要區分同名出站節點時，如何保留原設定？
升級後已恢復所需選擇時，不必再更改節點名稱。若確實需要在同一組區分兩個同名出站節點，可在自己管理的本機設定副本中，為對應集合分別設定 override.additional-prefix，例如 A- 與 B-；這是 Mihomo 官方支援的來源前綴，不是修改遠端訂閱服務。
將 additional-prefix 合併到該集合原有的 override，保留其他欄位。設定中明確列出的 proxies 引用、名稱篩選、腳本及已儲存的選擇，可能仍指向舊名稱，需要一併核對；不要直接覆蓋整份 override，也不要將 A-、B- 當成所有訂閱都適用的固定值。
透過正常匯入入口新增名稱不同的本機副本，保留原 Profile。先檢查語法、節點、規則及所需的自訂設定，再短暫切換，驗證新名稱與實際出站節點。若無法判斷執行中的設定或腳本會受何影響，就停止改名，保留已移除敏感資訊的證據交給上游。
失敗時切回原本可用的 Profile，並還原這次確實更改過的應用程式設定。副本中的前綴不會自動移轉到其他訂閱；訂閱更新後，也要重新核對執行中的設定，不能將一次測試通過當成永久保證。
失敗後如何恢復，並提供可供查核的回報？
若設定損毀而需要還原，先保留目前資料，再到備份紀錄匯入升級前匯出的檔案，選擇對應紀錄執行還原備份；匯入只會新增紀錄，不會自動套用。還原後，重新檢查訂閱、規則、代理模式與實際請求。
回退應用程式版本前，先核對備份相容性與官方安全公告。不要照抄 issue 中回到 v2.5.2 的使用者建議，尤其是 Windows 服務：相關安全公告已明確列出受影響版本與修復組建。新版本產生的備份，也不能假設舊版可以讀取；優先還原已驗證可用的設定。
若沒有可用設定，正常停止代理接管並檢查一般網路；必須透過代理存取的業務則暫緩使用。不要清空全部資料或關閉安全軟體來試錯，也不要使用其他來源的安裝檔繞過官方升級。
若仍異常，向上游提供完整版本、系統、已移除敏感資訊的集合與代理群組範圍、同名關係、單一節點與代理群組測試、新連線路徑，以及結束程式再重新啟動後的結果。使用一致的代稱保留結構，遮蓋訂閱認證資訊、個人位址及 secret，說明自己觀察到的差異，不要將尚未驗證的出站選擇寫成修復成功。