本文目錄
延遲顯示 Timeout，只能說明探測請求沒有按時回傳
Clash 的延遲按鈕會存取設定指定的測試位址，並在規定時間內等待結果。Timeout 可能來自節點不可達、測試 URL 被攔、DNS 失敗或目前網路阻斷；這個結果不能說明整台電腦已經斷網，也不能直接代表影片、下載和 UDP 的實際表現。
反過來，延遲幾十毫秒也不保證長連線穩定。檢查節點時要把「健康檢查結果」和「實際業務請求」分開記錄，否則會被一個漂亮數字帶偏。
兩種測試回答的問題
| 測試 | 能說明什麼 |
|---|---|
| 節點延遲 / health check | 測試 URL 在超時時間內是否有回應 |
| 瀏覽器開啟目標網站 | 網頁請求是否按預期規則從所選出口完成 |
| 長下載或串流回覆 | 連線持續性、封包遺失與中途切換 |
| 遊戲或語音 | UDP 支援、抖動與實際線路品質 |
關閉自動選擇，手動切換節點做一次對照
在主要策略群組中選一條具體節點，不使用 url-test、fallback 或 load-balance。模式保持 Rule，開啟 Connections，然後重複同一個網頁或應用動作。固定出口後，成功和失敗才來自同一條路徑。
記錄目標網域、命中的規則、節點名稱和日誌錯誤。連線頁沒有請求，說明應用未經過 Clash；顯示 DIRECT，說明規則沒有走該節點；確認請求已經交給節點後仍超時，再檢查節點連線。
一次有效重新測試應保留
- 固定的節點名稱與協議類型
- 同一個目標位址或應用動作
- Connections 中的規則和出口
- 日誌中的 timeout、reset 或 DNS 錯誤
一條失敗先換節點，全部失敗先看訂閱狀態
- 只有一條節點超時
- 更像單節點下線、擁堵或伺服器端連接埠變化；換同地區另一節點對照。
- 同一種協議全部超時
- 檢查目前核心是否支援設定欄位，以及該協議是否被本機網路限制。
- 同一訂閱所有節點超時
- 先看訂閱是否過期、流量是否用完、服務是否有公告，再決定要不要繼續測速。
- 多個訂閱在目前 Wi-Fi 都失敗
- 切手機熱點做對照，範圍已靠近本機網路、DNS 或防火牆。
- 網頁能用，遊戲或語音失敗
- 單獨驗證 UDP 與 TUN 接管，不能用網頁延遲替代。
範圍確定後再動設定。例如只有一條節點壞了，調整 DNS 和 TUN 反而會製造新問題；所有訂閱都在同一網路失敗，繼續購買新節點也很難說明原因。
timeout、refused、reset 和 DNS error 不要混著處理
i/o timeout / context deadline exceeded
路徑在時限內沒有完成，比較節點、網路和目標位址。
TLS handshake timeout / handshake failed
連線到達握手階段但沒有完成，核對節點協議、系統時間、核心相容和目前網路。
connection refused
目標主機可達但連接埠拒絕，節點服務或連接埠設定可能已變。
connection reset by peer
連線建立後被對端或中間裝置重置，檢查協議相容和網路穩定性。
no such host / DNS error
網域解析未完成，轉去檢查 Clash DNS 和系統 DNS 路徑。
unsupported / parse error
設定與核心能力不匹配，這不是網路延遲。
日誌時間要與剛才的測試動作對應。背景訂閱更新、健康檢查和瀏覽器請求可能同時寫日誌，只截最後一行很容易拿錯對象。
換一次熱點，判斷問題在目前網路還是節點
同一固定節點在家庭 Wi-Fi 和手機熱點各請求一次同一目標。熱點成功、Wi-Fi 失敗，說明節點本身仍能工作，應檢查路由器 DNS、防火牆、IPv6 或營運商路徑；兩邊都失敗，再換同訂閱的另一節點。只有晚高峰明顯變慢、白天恢復，則把測試時間和持續速度記錄下來，更像線路擁塞而不是設定突然寫錯。
若同一協議整組失敗而其他協議正常，記錄協議類型與核心版本，向訂閱提供方核對設定。不要把 Reality、XTLS Vision 之類傳輸或 flow 名稱當成獨立節點品質指標，真正有用的是同一環境下的對照結果。
最少變數的四次對照
節點 A + Wi-Fi
重複固定目標，留下日誌。
節點 A + 手機熱點
只更換接入網路。
節點 B + 原 Wi-Fi
只更換節點，盡量保留同一協議。
另一協議節點 + 原 Wi-Fi
只在前面仍無法區分時使用。
頻繁斷一下又恢復，要看策略群組有沒有在換出口
url-test 會根據探測結果選擇延遲較低的節點，fallback 會在目前節點不可用時按順序切換。探測間隔過短、tolerance 太小或測試 URL 不穩定，可能讓出口頻繁變化；登入會話、下載和串流連線就會被打斷。
把策略群組臨時改為 select 並固定一條節點。如果斷流消失，問題不一定是節點本身，而可能是健康檢查參數或自動切換方式。恢復自動組時，使用穩定的測試 URL，合理拉長 interval，並給 url-test 留出 tolerance。
proxy-groups:
- name: 自动选择
type: url-test
include-all: true
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 80
lazy: true回到原來的業務，確認超時真的消失
網頁問題要完成登入與頁面載入，下載問題要觀察一段持續傳輸，語音或遊戲則看 UDP 和會話是否穩定。Connections 應持續顯示預期規則與固定出口，日誌裡不再出現同一錯誤。
如果只能證明某個測試 URL 變綠，而原情境仍超時，這次檢查還沒有結束。保留節點、網路、時間和錯誤四項資訊交給訂閱提供方，他們才有條件定位線路或伺服器端。