Clash 節點逾時無法連線怎麼辦：依這個順序排查最快

先分類：全部逾時還是個別節點逾時

排查前先停止反覆點擊延遲測試。節點逾時只是結果，不能直接表示節點已失效。訂閱過期、目前網路中斷、系統時間錯誤、DNS 異常、連接埠衝突與設定參數不相容，都可能顯示為 timeout。先確認故障範圍，才能縮短後續檢查時間。

所有節點逾時

如果同一份訂閱中的香港、日本、美國等不同地區節點同時逾時，應優先檢查共用環節。共用環節包括訂閱狀態、直連網路、Clash 核心是否執行、系統代理或 TUN 是否建立，以及目前網路是否限制相關協定。數十個節點同時故障的機率，通常低於本機環境整體異常。

切換任意策略組後，所有節點都顯示 timeout。
延遲測試等待 5 至 10 秒後全部失敗。
日誌中連續出現網路無法連線、DNS 解析失敗或連線遭拒。
關閉 Clash 後，一般網頁也無法透過直連網路開啟。

只有部分節點逾時

如果同一份訂閱中仍有節點能測出 45 ms、120 ms 等延遲，表示客戶端核心、基本網路與訂閱格式大致可用。此時應將重點轉向故障節點本身：伺服器離線、連接埠變更、協定參數異動、線路遭目前電信業者封鎖，或健康檢查網址無法透過該節點連線。

現象	優先檢查層級	下一步
所有節點同時逾時	訂閱、直連網路、核心執行狀態	依本文順序從第一步開始
同一地區少數節點逾時	節點伺服器與地區線路	更換同地區其他節點交叉測試
延遲正常但網頁無法開啟	規則、策略組、DNS、系統代理	檢查請求實際使用的出口
Wi-Fi 逾時，手機熱點正常	路由器、區域網路 DNS、電信業者線路	保留熱點結果並檢查目前網路

第一步：確認訂閱仍有效且設定已更新

先進入客戶端的訂閱或設定頁面。常見入口名稱有「訂閱」「設定」「Profiles」或「設定管理」。查看目前設定的更新時間、剩餘流量與到期時間。不同客戶端的選單略有差異，例如可沿著「設定」→「訂閱管理」或「Profiles」→目前設定→「更新」尋找。

確認訂閱尚未到期，剩餘流量不是 0 GB。
手動更新一次訂閱，記下更新成功或失敗的提示。
更新成功後重新載入該設定，不要只停留在舊設定上。
進入代理群組，確認節點清單確實已重新整理。
不要將訂閱網址貼到公開測速網站或截圖中。

如何判斷訂閱更新失敗

更新時出現 HTTP 401 或 403，通常表示訂閱憑證失效、連結已重設或受到伺服器端限制。HTTP 404 表示網址不存在。持續回傳 5xx，則要考慮訂閱服務端暫時異常。若提示 connection timeout，請繼續檢查直連網路是否能存取訂閱網址，因為不少客戶端預設透過直連方式更新設定。

更新成功也不代表節點參數一定有效。開啟設定詳細資訊，檢查節點數量是否異常變成 0，或新設定是否仍引用舊的 provider 快取。使用代理集合的設定可能包含以下結構，實際節點清單來自 provider 檔案，而不是主設定本身：

proxy-providers:
  provider-main:
    type: http
    url: "訂閱網址"
    path: ./providers/provider-main.yaml
    interval: 3600
    health-check:
      enable: true
      interval: 600
      url: https://www.gstatic.com/generate_204

interval: 3600 表示每 3600 秒嘗試更新一次；健康檢查的 interval: 600 表示每 600 秒檢查一次。主設定已更新，但 provider 快取仍是舊的，也可能繼續看到已失效節點。可在客戶端的代理提供者頁面手動更新一次，再重新啟動核心。

第二步：關閉代理，驗證直連網路

Clash 需要依賴目前網路建立與代理伺服器的連線。底層網路已中斷時，所有節點自然會逾時。先在客戶端中關閉「系統代理」；如果正在使用 TUN 模式，也暫時關閉 TUN。完全退出瀏覽器後重新開啟，造訪一個平常可直連的網站。

進行兩組最小測試

關閉系統代理與 TUN，使用目前 Wi-Fi 開啟直連網站。
保持 Clash 設定不變，將電腦或手機切換至手機熱點，再測試同一批節點。

如果目前 Wi-Fi 下全部逾時，但在手機熱點下立即恢復，例如節點延遲從 timeout 變成 80 至 250 ms，故障層就在原本的網路、路由器或電信業者路徑，而不在 Clash 設定。此時先重新啟動光纖數據機或路由器，檢查路由器的上網狀態與 DNS 設定，再詢問網路管理員是否啟用了出口限制。

Windows 也可以開啟終端機執行基本連通性測試。這裡測試的是本機網路與 DNS，不是代理節點速度：

ping 1.1.1.1
nslookup example.com

ping 被封鎖不一定代表網路中斷，但如果網域解析失敗、瀏覽器直連也無法開啟網頁，就應先修復網路。macOS 與 Linux 可在終端機使用相同指令；部分系統需要以 dig example.com 取代 nslookup。

公共 Wi-Fi 的額外檢查

飯店、機場與校園網路通常有驗證頁面。連上 Wi-Fi 後看似已連線，實際上仍需在瀏覽器完成登入。關閉代理後造訪一般 HTTP 頁面，確認是否跳轉至驗證入口。完成驗證前，Clash 發出的連線通常會被攔截或重新導向，表現為所有節點逾時。

第三步：校準系統時間，再檢查核心與本機連接埠

系統時間誤差會破壞握手

TLS 憑證驗證依賴日期與時間。系統時間相差數分鐘甚至數小時，可能導致訂閱請求、WebSocket TLS、gRPC TLS 或其他加密連線失敗。進入 Windows「設定」→「時間與語言」→「日期與時間」，開啟自動設定時間與自動設定時區，然後點擊立即同步。macOS 可進入「系統設定」→「一般」→「日期與時間」，開啟自動設定。

同步後完全退出客戶端，再重新啟動。不要只切換節點，因為舊連線與 DNS 快取可能仍留在核心程序中。若日誌出現 certificate has expired、not yet valid 或 handshake failure，應將時間與憑證鏈列為重點。

確認 Clash 或 mihomo 核心正在執行

圖形介面能開啟，不代表核心程序正常。進入「設定」→「核心」或「設定」→「Clash 核心」，檢查狀態是否為執行中。採用 Clash Meta 後續核心 mihomo 的客戶端，日誌與程序名稱可能顯示 mihomo。若核心反覆啟動失敗，先開啟日誌查看第一個 error，而不是只看最後一則重試訊息。

檢查連接埠是否衝突

常見的本機 HTTP 與 SOCKS 混合連接埠是 7890，控制連接埠常見為 9090。具體數值以目前 YAML 與客戶端設定為準。以下是常見的設定形式：

mixed-port: 7890
external-controller: 127.0.0.1:9090
allow-lan: false
mode: rule
log-level: info

如果另一個代理程式已佔用 7890，Clash 可能無法監聽該連接埠。Windows 可在終端機執行：

netstat -ano | findstr :7890
netstat -ano | findstr :9090

macOS 或 Linux 可執行：

lsof -nP -iTCP:7890
lsof -nP -iTCP:9090

發現連接埠被舊程序佔用後，先退出舊代理程式，或在「設定」→「連接埠設定」中將 mixed port 改為未使用的連接埠，例如 7891。修改後還要讓系統代理同步使用新連接埠。只修改 YAML 而不更新系統代理，會導致瀏覽器繼續連線至舊的 127.0.0.1:7890。

第四步：核對節點協定參數與設定相容性

當訂閱有效、直連正常且核心也在執行時，再檢查節點參數。不要根據節點名稱手動猜測協定，應以伺服器端提供的內容為準，重點核對伺服器位址、連接埠、UUID 或密碼、傳輸方式、TLS、SNI、ALPN 與 Reality 參數。

容易造成逾時的參數差異

server 與 port：伺服器搬遷後仍使用舊位址或舊連接埠。
network：伺服器端使用 WebSocket，客戶端卻依 TCP 直連。
servername 或 sni：TLS 握手使用了錯誤網域名稱。
ws-opts.path：WebSocket 路徑缺少開頭斜線或仍是舊值。
grpc-opts.grpc-service-name：gRPC 服務名稱與伺服器端不一致。
Reality 參數：public-key、short-id 或 servername 不相符。
UDP：節點未啟用 UDP，卻被用於依賴 UDP 的請求。

舊版 Clash 核心不認識部分新欄位時，可能在載入設定階段直接報錯，也可能略過不相容節點。遇到設定包含 Reality、Hysteria2、TUIC 等類型時，應確認客戶端使用支援對應協定的 mihomo 版本。版本過舊時，優先透過客戶端內建的「設定」→「核心」→「更新核心」完成更新，並在更新後重新載入設定。

如果日誌中出現 unsupported proxy type、field not found 或設定解析失敗，問題發生在設定載入層，尚未進入節點連線層。此時反覆進行延遲測試沒有意義，應先處理核心相容性或訂閱格式。

健康檢查逾時不等於所有網站都無法使用

客戶端延遲測試通常會造訪指定 URL，例如回傳 HTTP 204 的輕量頁面。測試網址可能只受到節點出口、DNS 或目前網路其中一環的限制。可以暫時將測試 URL 更換為另一個穩定的 HTTPS 位址進行交叉驗證，但不要使用大型檔案下載網址作為健康檢查，否則會增加流量與測試時間。

要判斷節點是否真的能使用，應同時查看三項：健康檢查延遲、日誌中的連線結果，以及實際網頁請求。單次 5000 ms 逾時只能表示該測試未在限定時間內完成。連續三次逾時，且實際請求也失敗，才較接近節點或線路故障。

第五步：檢查系統代理、TUN 與 DNS 所在層級

系統代理模式

系統代理模式主要接管遵循系統代理設定的應用程式。先進入客戶端「設定」→「系統代理」，關閉後再重新開啟一次，並核對代理位址為 127.0.0.1，連接埠與 mixed port 一致。瀏覽器擴充功能、其他代理軟體與手動 PAC 設定可能覆蓋系統設定，排查時應暫時停用這些額外入口。

若節點測試正常，但只有某個應用程式無法連線，故障通常不在節點。檢查該應用程式是否讀取系統代理，或是否自行指定了代理連接埠。可先用瀏覽器驗證，再與故障應用程式比較。

TUN 模式

TUN 模式透過虛擬網路介面接管更多流量，通常需要管理員權限。啟用失敗時，客戶端日誌可能出現 interface、route、permission 或 device 相關錯誤。Windows 可使用管理員權限啟動客戶端；macOS 首次啟用時需要核准網路延伸功能或 VPN 設定。若系統中還有其他 VPN，請先完全退出，以免路由表與虛擬網卡衝突。

排查 TUN 時使用二分法：關閉 TUN，只啟用系統代理。如果瀏覽器恢復正常，節點本身可用，問題集中在 TUN 權限、路由或 DNS；如果兩種模式都逾時，繼續查看節點與線路層。

辨識 DNS 異常的方法

節點延遲正常，但輸入網域名稱後無法開啟；直接造訪已知 IP 卻有回應，這類現象應檢查 DNS。mihomo 設定中常見 dns.enable、nameserver、fallback、fake-ip 等欄位。不要在不了解原設定的情況下同時修改所有 DNS 項目。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

連接埠 1053 也必須未被佔用。若使用 TUN 與 fake-ip，關閉 TUN 後應重新測試，避免舊路由與快取造成干擾。Windows 可執行 ipconfig /flushdns 清除系統 DNS 快取；macOS 可在重新啟動網路或系統後再次測試。清除快取只是輔助動作，無法修復錯誤的上游 DNS 設定。

第六步：最後再更換節點，並用日誌確認結論

前面的共用環節都正常後，才進入更換節點階段。先在同一地區選擇 2 至 3 個不同節點，每個節點連續測試三次，間隔約 10 秒。不要一次測試數十個節點，因為並行健康檢查可能觸發網路限速，也會讓日誌難以閱讀。

選擇節點 A，測試延遲並開啟一個實際網頁。
選擇同地區節點 B，重複相同操作。
切換至其他地區的節點 C，判斷是否為地區線路問題。
再切換至手機熱點，保留一組不同網路的對照結果。

如果節點 A、B 在家用寬頻下逾時，但在手機熱點下正常，結論偏向目前電信業者的路徑。如果同一節點在兩種網路下都逾時，而同一份訂閱中的其他節點正常，結論偏向節點伺服器或連接埠。如果所有地區在兩種網路下都逾時，則應回到訂閱與協定參數層重新核對。

日誌中要看哪些關鍵字

i/o timeout：連線或讀寫未在限定時間內完成。
connection refused：目標位址可到達，但對應連接埠拒絕連線。
network is unreachable：本機路由或網路介面無法到達目標。
no such host：網域解析失敗。
TLS handshake timeout：TLS 握手逾時，需要檢查線路、SNI、時間與伺服器端。
authentication failed：驗證參數不一致或憑證已失效。

日誌層級先使用 info。只有在資訊不足時才短暫切換至 debug，重現一次後恢復。分享日誌前，應移除訂閱網址、UUID、密碼、權杖、伺服器憑證與個人網路資訊。

常見誤判與最快處理方式

誤判一：看到 timeout 就立即重新安裝

重新安裝只能重設客戶端檔案，無法修復訂閱到期、伺服器離線、電信業者線路或系統時間錯誤，還可能遺失原有日誌，使問題更難定位。應先匯出必要設定，再完成基本分層檢查。

誤判二：延遲數字越小就一定能連線

延遲測試只反映特定測試請求。40 ms 的健康檢查不保證目標網站一定可存取，也不保證規則會將請求送至該節點。網頁載入失敗時，請進入連線日誌，確認網域命中了哪條規則、進入哪個策略組，以及最後選用了哪個節點。

誤判三：只切換策略組，不確認實際選擇

在規則模式下，請求會先比對規則，再進入指定的策略組。手動切換了名為「節點選擇」的群組，但目標網域可能命中另一個「自動選擇」群組。日誌中應能看到類似 DOMAIN-SUFFIX、MATCH 等規則結果。排查時可暫時使用全域模式進行交叉測試，但測試完成後應恢復原本的規則模式。

十分鐘分流檢查清單

第 1 分鐘：確認是全部逾時還是個別逾時。
第 2 分鐘：查看訂閱到期時間、剩餘流量與更新時間。
第 3 分鐘：關閉代理與 TUN，驗證直連網路。
第 4 分鐘：切換手機熱點進行網路對照。
第 5 分鐘：同步系統時間並重新啟動核心。
第 6 分鐘：核對 7890 等本機連接埠是否被佔用。
第 7 分鐘：查看日誌中的第一個錯誤。
第 8 分鐘：核對協定、TLS、SNI 與傳輸參數。
第 9 分鐘：關閉 TUN，只使用系統代理重新測試。
第 10 分鐘：選擇不同地區的節點進行最後交叉測試。

這套順序的核心，是先檢查所有節點共用的環節，再檢查單一節點。全部逾時時優先處理訂閱、網路、核心與連接埠；個別逾時時優先處理節點伺服器、協定參數與線路。每一步都保留測試結果，下次遇到同類故障時就能直接跳到對應層級。