本文目錄
手動選取節點後網頁能開啟，延遲測試卻失敗，自動選擇也不願選它。這時先別重新匯入訂閱：Mihomo 曾有一個適用情況很窄的計時問題，測試目標在不足 1 毫秒內回應時，成功請求的耗時會被截成 0。
節點能用，為什麼測速還是失敗？
官方 #3316 記錄的現象是：同一節點的測試歷史出現 alive: true 與 delay: 0，單節點延遲介面卻回傳 503，自動群組還可能把這個 0 視為沒有有效延遲。這類測試目標通常在同一主機、區域網路或很近的邊緣節點，並不涵蓋所有測速失敗。
圖形用戶端可能把核心錯誤一律顯示為失敗或逾時，畫面不一定直接顯示 0ms。只看到一個 Timeout，或只看到 alive: true，都不足以確認這個缺陷；必須核對同一節點、同一測試 URL 與相近時間的結果。
先分清三種看似相近的情況
| 現象 | 應如何處理 |
|---|---|
| 測試很快完成，舊核心卻記成 0，同時顯示失敗 | 核對 #3316 的計時情況，再透過支援的管道取得修正。 |
| DNS、TLS、連線失敗，或實際請求超過 timeout | 依對應日誌排障，不能用亞毫秒修正解釋所有逾時。 |
| Provider 更新後自動群組不切換，但沒有上述計時證據 | 保留當時紀錄，另外檢查群組狀態；不能視為同一個已修正問題。 |
v1.19.33 修正的是計量，不是網路速度
v1.19.33 正式發行說明列入 #3316。固定版本原始碼在 URLTest 正常回傳的路徑上，先把耗時換算為整毫秒；若結果為 0，就記錄為 1，避免與「沒有有效延遲」的 0 混淆。啟用 unified-delay 時，第二次成功請求的計時也經過這項共同處理。
這個 1ms 是計量下限，不代表網路真的用了整整 1 毫秒，更不是加速保證。測試請求仍須經過連線、HTTP 請求與設定的狀態碼判斷；測試目標、節點與用戶端的實際情況仍要分別檢查。
調大 timeout 只會改變等待時間，tolerance 則影響自動群組的切換容差，都無法補回截成 0 後失去的有效計時。不要靠反覆修改這兩個值來驗證本修正。
先記下哪個節點、哪個 URL 失敗
各用戶端的選單名稱不同，使用應用程式原有的核心資訊、啟動日誌、節點測速與連線紀錄入口即可，不必為了核對而啟用 external-controller、對外開放連接埠或分享 secret。用戶端版本也不能代替執行中的 Mihomo 版本。
將測速結果對應到實際連線
確認實際核心與目前設定
從核心資訊或本次啟動日誌記錄完整版本，記下啟用的設定、節點名稱與測試 URL。不要用另一個目錄下的核心檔案版本代替。
分清單節點、自動群組與 Provider 檢查
查看實際生效設定中的測試入口、url、timeout、interval、expected-status 與 unified-delay。群組的 url 用於其 proxies；透過 use 引入的 Provider 另有健康檢查，不能假定它們使用同一目標。
在相同條件下少量重測
選取同一節點，執行用戶端原有的單節點測試，並從連線紀錄確認一次實際請求確實經過該節點。記錄時間與錯誤；網頁能成功開啟，與測速請求原本就是兩種不同的觀察。
只採用實際取得的證據
若原有的本機診斷能顯示 delay/history，就對照同一節點與 URL 的 0 和失敗結果；看不到時，保留畫面與日誌並標為待確認，不從 UI 的 Timeout 推斷亞毫秒耗時。
若測試 URL 回傳的狀態碼不符合 expected-status，或日誌顯示解析、憑證、連線錯誤，先處理這些明確原因。不要為了製造小於 1ms 的結果而架設服務、密集重測或關閉憑證驗證。
如何取得修正，並確認真的生效？
先獨立備份目前設定、用戶端資料與可還原的原版本。應用程式支援單獨更新核心時，透過其認可的正式管道選擇包含 #3316 的版本；不支援時，使用維護者確認已整合修正的正式用戶端套件，不覆寫應用程式內部檔案。
更新後使用相同的測試對象
確認真正啟動了新核心
v1.19.33 已確認收錄修正。更新並依用戶端要求重新啟動後，再讀取核心資訊或新日誌，不只看應用程式的更新成功提示。
重測相同節點與相同目標
恢復同一設定與測試 URL，先執行單節點測試，再觀察原本的自動群組或 Provider 檢查。各入口分別比較，不能用不同目標的結果作為升級前後對照。
同時驗證使用中的請求
確認用戶端的連線紀錄仍指向預期節點，再驗證之前能使用的網頁或應用程式請求。若原有診斷可見，核對該測試是否已不再因有效耗時被記成 0 而誤報；不要要求所有節點都顯示 1ms。
若暫時沒有受支援的修正套件，可在確認節點實際可用後手動選取它，作為暫時使用方式。這不會修正計時，也不能證明自動故障切換已恢復；無法確認時，保留原設定並等待正式更新，不刪除訂閱或重寫整份設定。
通過哪些檢查，才算處理完成？
逐項核對，不只看一個綠色數字
- 已記錄執行中核心的完整版本，並確認更新管道與實際載入的設定。
- 升級前後使用同一節點與同一測試 URL，已分清各檢查入口的狀態碼要求與時間單位。
- 沒有同時修改 DNS、TLS 驗證、timeout、tolerance 或訂閱，避免把其他變化誤認為修正效果。
- 已複查原有單節點測速與實際請求；自動群組或 Provider 的健康檢查另外觀察，沒有只憑一次手動測試就推斷全部恢復。
- 仍失敗時，保存具體錯誤、時間與去識別化結果，分別記錄真正逾時、狀態碼不符及 Provider 更新問題。
本文依官方修正與固定版本原始碼解釋計時情況，沒有下載核心或替你的環境實機重現。若升級後仍顯示失敗，應沿著新的具體錯誤繼續排查，不能把 v1.19.33 視為解決所有延遲測試問題的承諾。
更新後出現其他異常，如何還原？
停止受影響的操作，透過原本支援的更新方式還原保存的原版本，再還原與它對應的獨立備份。不要讓兩個版本同時寫入同一個資料目錄，也不要覆寫唯一備份。還原後，檢查實際核心、設定、手動選取與實際請求。
還原舊版可能讓計時缺陷再次出現，只適合用來恢復可用環境。向維護者回報時，附上系統、核心完整版本、測試入口、去識別化 URL、時間與具體錯誤；移除訂閱權杖、控制金鑰與私人資訊。不要只憑 issue 已關閉，就判斷手上的安裝套件包含修正。