Clash 節點逾時、測速失敗怎麼辦？從更新訂閱到 DNS 的排查步驟

先釐清：測速失敗、節點無法連線，還是規則未命中

看到 timeout 時，先別急著重新安裝用戶端。測速結果只代表核心未能在指定時間內，透過選定節點完成對測試網址的請求。測試網址無法連線、節點連線失敗或 DNS 解析異常，都可能造成相同的逾時結果。先判斷故障範圍，再調整設定。

保留可供比對的現況紀錄

1. 記下用戶端版本、核心名稱與版本、目前使用的設定檔名稱，以及故障發生時間。
2. 儲存設定檔副本，並截圖記錄目前的代理模式、策略組選擇、系統代理與 TUN 開關狀態。
3. 選定一個節點、一個測試網址和一個實際網頁，之後每次只調整一項設定。
4. 開啟用戶端的「日誌」與「連線」頁面。不同用戶端的選單名稱可能不同，請以實際介面為準。

測速單位通常是毫秒，表示該次測試請求所花的時間，不代表下載頻寬。可暫時將逾時門檻從 3000 毫秒調至 10000 毫秒，判斷是否只是連線建立較慢；這兩個數值僅為診斷設定範例，不代表實際效能，也無法修復失效節點。

步驟一：確認訂閱有效，且已啟用最新設定檔

先前往用戶端的「訂閱」或「設定檔」頁面，手動更新一次。確認更新完成時間已變更，再檢查目前啟用的是否為剛更新的設定檔。清單中有新設定檔，不代表核心已載入該設定檔。

依更新結果採取相應處理

• 回應 401 或 403：檢查訂閱網址是否完整、存取權杖是否已更換，以及訂閱帳戶狀態。實際原因請以伺服器提示為準。
• 回應 404：確認路徑是否已失效，並從原本的訂閱管理頁面重新複製網址，避免使用舊書籤。
• 回應 200，但匯入失敗：確認回應內容是否其實是登入頁面或錯誤網頁。HTTP 請求成功，不代表取得了可用的設定檔。
• 顯示 YAML 解析錯誤：檢查縮排、欄位格式及用戶端支援的訂閱格式。不要將單一節點連結當成完整設定檔載入。
• 下載訂閱時逾時：確認更新請求是否依賴目前已失效的代理。如果用戶端提供訂閱更新代理選項，可暫時切換請求方式後重試。

更新後也要確認節點名稱、數量與策略組成員是否符合預期。伺服器端可能已替換節點位址，本機覆寫規則也可能篩除新節點。如果設定檔顯示載入失敗，請先解決載入問題，不要反覆測速。

步驟二：校正系統時間，排除基本網路問題

確認裝置可以正常連上網路，再檢查系統日期、時間與自動同步狀態。憑證驗證需要準確的時間，部分認證機制也會受時間誤差影響。時區顯示不同不一定代表故障，重點是系統時間是否準確。

• Windows：開啟「設定」→「時間與語言」→「日期與時間」，檢查「自動設定時間」，再按「立即同步」。
• macOS：開啟「系統設定」→「一般」→「日期與時間」，檢查自動設定日期與時間的選項。
• Android：前往系統設定中的「日期與時間」，啟用自動設定時間；選單位置會因系統版本與裝置而異。

如果日誌出現 certificate has expired 或 certificate is not yet valid，請先確認本機時間，再檢查伺服器憑證的有效期限。不要直接關閉憑證驗證來避開錯誤，這會掩蓋真正的問題並降低連線安全性。

切換網路，判斷故障範圍

維持相同節點與設定，將電腦從目前網路切換至手機熱點，再測試一次。如果熱點可用、原網路不可用，應優先檢查原網路的存取限制、認證頁面與路由器設定。如果兩種網路都無法連線，再檢查本機與節點。切換網路只能縮小排查範圍，不能僅憑一次結果就判定伺服器故障。

步驟三：檢查核心執行狀態、連接埠占用與系統代理

確認用戶端介面顯示核心運作正常。圖形介面已開啟，不代表 mihomo 已成功啟動。日誌中的 address already in use 通常表示監聽位址或連接埠已被占用；請先處理啟動錯誤，再測試節點。

確認實際監聽的連接埠

mixed-port 同時提供 HTTP 與 SOCKS5 代理入口。以下以本機混合連接埠 7890 為例；實際連接埠請從用戶端設定或目前生效的設定檔確認，不要將範例數值視為所有用戶端的預設值。

# 設定片段範例，並非完整設定
mixed-port: 7890
allow-lan: false

在 Windows 命令提示字元中檢查監聽狀態：

netstat -ano | findstr LISTENING | findstr :7890

在 macOS 或具備相關工具的 Linux 系統中檢查：

lsof -nP -iTCP:7890 -sTCP:LISTEN

如果連接埠被其他程序占用，請先透過程序編號確認程式身分，再正常結束不需要的程式，或為 Clash 更改連接埠。不要直接終止不明的系統程序。更改後，也要同步更新應用程式中手動填寫的代理位址。

區分本機代理入口與遠端節點

在 Windows 中，可使用下列指令，明確透過本機 HTTP 代理發送請求。測試網址僅用於說明指令格式，請改用已確認可連線的 HTTPS 網址進行比對。

curl.exe -I --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://example.com/

在 macOS 或 Linux 中，將指令開頭的 curl.exe 改為 curl。如果立即顯示無法連線至 127.0.0.1:7890，請優先檢查本機監聽狀態與連接埠。如果請求已進入核心，再查看連線面板，確認最後使用的策略與節點。明確指定代理只能證明請求進入代理入口，不保證規則一定會選擇遠端代理。

明確指定代理後測試可用，但瀏覽器仍無法連線時，再檢查用戶端的「系統代理」開關、瀏覽器個別的代理設定，以及其他網路工具是否覆寫系統代理。TUN 模式還涉及服務權限與路由，不建議在此階段和系統代理一起反覆切換。

步驟四：分別檢查伺服器網域與目標網域的 DNS

DNS 故障至少要分兩處檢查：一處是將節點的伺服器網域解析為位址，另一處是解析準備造訪的網站網域。前者失敗時，代理連線可能根本無法建立；後者失敗時，則可能出現節點測速正常、特定網頁無法開啟的情況。

先檢查節點伺服器網域

在目前的設定檔中查看節點的 server 欄位。如果填寫的是網域，可使用 nslookup 或 Resolve-DnsName 檢查系統解析結果。指令中應填入實際的伺服器網域，不要貼上整段訂閱連結或含路徑的網址。

• 系統解析失敗，用戶端也回報解析錯誤：先檢查本機 DNS 與網路連線。
• 系統解析正常，但用戶端解析失敗：檢查核心使用的 DNS 上游及其存取方式；兩者不一定使用相同的解析路徑。
• 已設定加密 DNS：確認端點本身可連線，並留意端點網域也可能需要引導解析。
• 使用 mihomo 時：檢查適用版本中的 proxy-server-nameserver 設定；此設定用來指定代理伺服器網域的解析上游，實際支援情況請以目前核心的設定文件為準。

接著檢查 Fake-IP 與應用程式快取

在 Fake-IP 模式下，DNS 回傳合成位址可能是正常現象。常見設定會使用 198.18.0.0/16 範圍，看到這類位址不能直接判定解析錯誤。請搭配核心連線紀錄，確認應用程式請求是否已正確接管，以及網域對應是否仍然有效。

瀏覽器的安全 DNS、應用程式內建解析與系統 DNS 可能使用不同路徑。如果只有特定應用程式異常，請先檢查該應用程式的 DNS 設定，而不是立刻重寫整份設定檔。可暫時關閉應用程式自訂解析進行比對，記下結果後，再決定長期設定。

每次只調整一項 DNS 設定，重新載入設定檔後，關閉並重新開啟測試應用程式。Windows 可使用 ipconfig /flushdns 清除系統 DNS 快取，但這不會自動清除瀏覽器自己的快取，也不能取代核心的快取管理。若在 Fake-IP 與其他模式間切換，也要留意舊連線與舊對應。

步驟五：逐項核對協定參數與傳輸條件

如果只有少數節點無法連線，請著重檢查這些節點本身。先從訂閱來源重新更新，避免手動拼湊參數。Clash 圖形用戶端與核心屬於不同層級：介面能顯示某種節點類型，不代表目前執行的核心版本一定支援該類型或所有欄位。

以 QUIC 為基礎的節點傳輸通常需要 UDP。如果目前網路限制 UDP，修改本機 HTTP 代理連接埠無法解決遠端傳輸問題。可切換網路進行比對，或測試伺服器提供的其他傳輸類型。一般 TCP 連接埠測試也無法證明 UDP 節點可用。

即使 TCP 連線成功，也只能證明連線已建立至某個監聽連接埠。認證失敗、TLS 交握錯誤或傳輸路徑不符，仍會導致代理無法使用。不要因為「連接埠連得上」就認定整個協定運作正常。

最後驗證：搭配規則、日誌與實際請求縮小問題範圍

修復後不要只看測速顏色。開啟實際網頁，並在連線面板確認目標網域、命中的規則、策略組與最後使用的節點。規則模式可能會將測試網頁指定為 DIRECT，此時網頁能開啟，不代表選定的代理節點可用。

透過日誌判斷故障階段

• connection refused：目標端明確拒絕連線。檢查位址、連接埠及服務是否正在監聽。
• i/o timeout：請求在某個階段未能及時完成。搭配前後日誌，判斷是解析、連線還是交握逾時。
• no such host：優先檢查網域拼字與解析路徑。
• authentication failed：核對認證參數與帳戶狀態，不要只是不斷更換 DNS。
• unsupported proxy type：檢查設定類型與核心相容性，先解決載入問題。

確實需要暫時提高日誌層級時，只記錄一次可重現的操作，之後再恢復日常層級。排查結束後，請還原暫時更動的測試網址、代理模式與應用程式 DNS 設定，只保留確實有效的修改，避免將診斷用狀態當成長期設定。

回報問題時請提供以下資訊

提供用戶端與核心版本、作業系統、故障範圍、切換網路後的結果、錯誤時間，以及已遮蔽敏感資訊的相關日誌片段。說明訂閱是否能更新、本機連接埠是否正在監聽，以及請求是否進入核心。依照這個順序記錄，比只說「節點全紅」更容易判斷問題出在本機設定、解析路徑還是節點服務。

排查步驟可以簡化為一條路徑：確認訂閱已更新並啟用 → 時間與網路正常 → 核心已啟動且連接埠可用 → DNS 路徑正常 → 協定參數相符 → 實際請求使用預期節點。在哪個步驟出現可重現的失敗，就先停下來處理該步驟。