Clash 節點逾時無法連線：從訂閱到 DNS 的排查順序

先確認「逾時」發生在哪一層

Clash 用戶端顯示 Timeout，不一定代表節點本身已失效。訂閱下載、設定載入、節點握手、DNS 查詢、規則比對、系統代理轉送與 TUN 路由，都可能產生類似現象。先記錄故障範圍，再逐項檢查，通常比立即刪除設定或重新安裝更快。

第一步應區分三種現象：訂閱是否能更新、節點延遲測試是否有結果，以及瀏覽器或其他應用程式是否能存取目標網站。三者對應的連線路徑並不相同。訂閱更新失敗多半與訂閱網址、網路入口或憑證時間有關；所有節點延遲同時逾時，常見原因包括目前網路限制、DNS、核心未執行或測試網址無法連線；只有部分節點失敗，則較接近節點線路、連接埠或協定參數問題。

第一段：檢查訂閱有效性與設定載入結果

訂閱是設定來源，不等同於節點本身。訂閱網址過期、帳戶狀態變更、下載回傳登入頁面或服務端暫時發生錯誤，都可能讓用戶端取得空內容或錯誤格式。此時繼續測試節點沒有意義，應先確認用戶端確實下載到可解析的 YAML 設定。

查看更新時間與錯誤訊息

1. 在設定或訂閱頁面查看最近更新時間，確認這次更新是否真正成功。
2. 如果用戶端顯示 HTTP 狀態碼，請分別記錄 401、403、404、429 或 5xx。不同狀態分別代表授權、網址、頻率限制或服務端故障，處理方向也不同。
3. 確認訂閱名稱下存在代理節點與策略群組，而不是只顯示空白設定。
4. 更新後重新選取一次目前設定，並確認 Clash 核心沒有回報 YAML 解析錯誤。

設定解析失敗常見於縮排、重複欄位、無法識別的代理類型，或用戶端核心版本不支援訂閱使用的欄位。使用 Clash Meta（mihomo）設定時，應由支援相應欄位的用戶端載入。經典 Clash 核心與 mihomo 的功能範圍不同，不能只看用戶端外殼名稱判斷相容性。

如果曾手動編輯設定，可先切回服務端原始訂閱進行比對。YAML 使用空格表示層級，Tab、錯誤縮排及複製時混入的符號，都可能導致載入失敗。對於由用戶端管理的訂閱，直接編輯快取檔案也可能在下次更新時被覆寫，因此自訂規則應放在用戶端支援的覆寫、擴充或設定合併位置。

第二段：判斷節點、連接埠與目前網路是否可達

節點延遲測試通常會透過指定節點請求測試 URL，並測量回應時間。測試失敗可能發生在網域解析、TCP 建立連線、TLS 握手、代理協定握手或目標網頁回應階段。部分用戶端只顯示 Timeout，需要搭配日誌才能找出具體位置。

先進行交叉測試

• 在同一份訂閱中選擇三到五個不同地區、不同入口的節點，避免只測試單一節點。
• 在同一台裝置上切換家用網路與手機熱點。若熱點可用而原本的網路全部逾時，應重點檢查原網路的 DNS、路由、連接埠限制與閘道設定。
• 在同一網路上使用另一台裝置測試。若只有一台裝置失敗，問題通常位於本機權限、代理設定或防火牆。
• 如果用戶端允許更換延遲測試網址，可選擇穩定的 HTTPS 網址重新測試。單一測試網站無法連線時，節點未必已失效。

不要把 ping 結果直接等同於代理節點狀態。伺服器可能不回應 ICMP，但仍允許代理協定使用的 TCP 或 UDP 連接埠；反過來，能 ping 通伺服器，也不表示對應代理連接埠已開放，更不表示驗證與協定握手成功。

區分 TCP 與 UDP 問題

一般網頁主要依賴 TCP 與 TLS，而部分遊戲、語音、QUIC 與 DNS 情境會使用 UDP。網頁能開啟但特定應用程式逾時，可能是節點或協定未提供可用的 UDP 轉送，也可能是 TUN 的 UDP 路由未生效。應先用一般 HTTPS 網頁確認 TCP 代理，再單獨驗證需要 UDP 的應用程式，避免混淆兩種問題。

若所有節點在某個網路下同時失敗，而切換網路後立即恢復，通常不需要逐一刪除節點。可先重新啟動路由器、斷開後重新連線網路，並檢查是否啟用了其他 VPN、加速器或安全軟體的網路過濾功能。多個工具同時建立虛擬網卡或修改路由表時，資料可能沒有進入預期的 Clash 介面。

第三段：校準系統時間與憑證驗證環境

代理連線、訂閱下載與 HTTPS 存取都可能涉及 TLS 憑證驗證。系統日期、時區或時間偏差過大時，憑證會被判定為尚未生效或已經過期，用戶端日誌中可能出現 certificate、x509、handshake 等文字，也可能只呈現連線失敗。

1. 開啟系統的自動設定日期與時間功能。
2. 確認時區與所在地一致，尤其留意手動選取的 UTC 偏移。
3. 執行一次立即同步，然後完全退出並重新啟動 Clash 用戶端。
4. 如果裝置受機構政策管理，確認時間同步服務能夠存取，並檢查系統憑證儲存區是否正常。

雙系統裝置、長時間休眠的筆記型電腦、恢復原廠設定後的手機，以及長時間未連網的裝置，更容易出現明顯時間偏差。校準時間後，應重新更新訂閱並測試節點，而不是只重新整理瀏覽器頁面。

第四段：排查 DNS 解析、Fake-IP 與污染快取

DNS 故障常見的表現是：節點延遲偶爾正常，但開啟網域時逾時；直接存取已知 IP 有回應，存取網域卻失敗；日誌連續出現 lookup、resolve、nameserver 或 context deadline exceeded。Clash 的 DNS 模組既可能解析代理節點伺服器網域，也可能處理經過規則分流的目標網域，因此 DNS 出錯會影響多個階段。

先確認系統 DNS 能否正常運作

退出代理或暫時關閉系統代理後，使用系統內建工具查詢一般網域。命令只用於觀察解析是否回傳網址，不代表該網站一定能完成存取。

nslookup www.example.com

如果查詢本身逾時，可嘗試重新連線網路、重新整理系統 DNS 快取，或在路由器與裝置網路設定中檢查 DNS 位址。若系統查詢正常而 Clash 日誌中的 DNS 查詢失敗，再檢查設定中的 dns、nameserver、fallback、proxy-server-nameserver 等欄位是否受目前核心支援。

理解 Fake-IP 模式的適用範圍

mihomo 常見的增強 DNS 模式包括 fake-ip 與 redir-host。Fake-IP 會先向應用程式回傳保留位址，再由核心儲存網域對應並完成後續分流。看到保留位址不一定代表解析錯誤；真正需要檢查的是請求是否進入 Clash、對應是否存在，以及目標網域是否依規則選擇正確出口。

某些區域網路裝置探索、企業內網網域、印表機位址，以及依賴真實 DNS 回傳值的程式，不適合直接使用 Fake-IP。可依實際需求設定 Fake-IP 過濾規則，或對內網網域使用指定解析器。過濾範圍應盡量明確，過寬的萬用字元規則會削弱網域對應與分流效果。

節點伺服器網域需要單獨解析

如果代理節點的伺服器欄位本身是網域，核心必須先在建立代理通道前解析它。此時若設定讓該查詢依賴尚未連線的代理，就可能形成循環等待。mihomo 提供用於解析代理伺服器網域的相關 DNS 設定能力，但具體欄位需要與目前核心版本相符。排查時可觀察日誌是否一直停留在節點伺服器網域解析階段。

第五段：核對系統代理、規則模式與 TUN 接管範圍

節點可用但應用程式沒有經過代理，通常是接管方式的問題。Clash 的系統代理開關主要為遵循作業系統代理設定的程式提供 HTTP 或 SOCKS 入口；部分遊戲、命令列程式、商店應用程式及自行實作網路堆疊的軟體可能忽略系統代理。TUN 模式透過虛擬網卡與路由接管更多流量，但需要額外權限，也更容易與其他 VPN 或虛擬網卡發生衝突。

先以規則模式驗證策略選擇

在 Rule 模式下，流量會依設定中的規則由上到下比對，命中後進入相應策略群組。即使節點本身可用，如果規則將目標網域送往 DIRECT、REJECT 或未選取有效節點的策略群組，存取仍會失敗。開啟連線記錄或日誌，確認目標網域命中了哪條規則，最後使用了哪個策略群組與節點。

Global 模式會將大部分流量交給指定策略，但適合用於診斷，不適合取代規則排查。若 Global 可用而 Rule 不可用，應檢查規則順序、規則集載入狀態與策略群組選擇；若兩種模式都失敗，再回頭檢查節點、DNS 與本機連接埠。

系統代理排查順序

1. 確認 Clash 核心正在執行，而不只是用戶端視窗已開啟。
2. 確認系統代理開關已開啟，並查看作業系統代理位址是否指向本機監聽連接埠。
3. 確認設定中的 mixed-port、port 或 socks-port 與用戶端顯示一致。
4. 關閉瀏覽器內個別安裝或設定的其他代理入口，避免請求被轉送到舊連接埠。
5. 重新啟動目標應用程式。部分程式只會在啟動時讀取系統代理設定。

TUN 模式排查順序

1. 確認用戶端已取得建立虛擬網卡、修改路由或安裝網路服務所需的系統權限。
2. 暫時退出其他 VPN、虛擬機器網路工具與加速器，再重新啟用 TUN。
3. 查看系統中是否出現對應的虛擬網卡，並確認預設路由沒有反覆被其他程式覆寫。
4. 如果啟用 TUN 後整個網路中斷，先關閉 TUN 恢復網路，再檢查 DNS 劫持、路由排除項與介面自動選擇。
5. 區域網路存取異常時，檢查私有位址是否應直接連線，以及區域網路網段是否被錯誤送入代理。

系統代理可用而 TUN 不可用，通常表示節點與基本代理協定沒有問題，應將重點放在權限、虛擬網卡、路由與 DNS 接管。TUN 可用而系統代理不可用，則應核對本機監聽連接埠、系統代理位址，以及應用程式是否會讀取代理設定。

第六段：檢查本機監聽連接埠、防火牆與連接埠衝突

Clash 核心需要在本機監聽 HTTP、SOCKS 或 mixed 連接埠。若連接埠被其他程序占用，核心可能啟動失敗，也可能自動退出；若本機安全策略阻止程式監聽或連線，使用者介面仍可能存在，但請求無法完成。

先在用戶端日誌中尋找 address already in use、bind、permission denied、connection refused 等資訊。address already in use 通常表示連接埠衝突；在存取 127.0.0.1 時出現 connection refused，通常表示對應連接埠沒有服務監聽；遠端連線出現 refused，則可能是節點連接埠關閉或伺服器主動拒絕。

若設定使用常見的 7890 作為 mixed 連接埠，可使用下方的請求驗證本機代理入口。實際執行時必須將連接埠改為用戶端目前顯示的值。

curl -x http://127.0.0.1:7890 https://www.example.com/ -I

此請求成功，表示命令列程式能連線到本機代理連接埠，並完成一次 HTTPS 請求；如果瀏覽器仍然失敗，應檢查瀏覽器代理、憑證提示或擴充功能設定。如果請求立即顯示無法連線到本機連接埠，應先處理核心狀態與連接埠監聽，不要繼續更換遠端節點。

防火牆檢查重點

• 確認目前的 Clash 用戶端及其核心程式已獲允許存取目前類型的網路。
• 用戶端升級後，可執行檔路徑可能變更，需要重新確認系統防火牆規則。
• 公司或校園網路可能限制部分外連連接埠，可透過手機熱點進行交叉判斷。
• 路由器上的家長監護、存取控制與 DNS 過濾，也會影響節點伺服器或訂閱網址。
• 如果只有在開啟「允許區域網路連線」後出現異常，請檢查監聽位址與區域網路防火牆規則，不要將本機代理連接埠暴露於不受信任的網路。

第七段：用日誌定位階段，再進行最小化重新測試

日誌的價值在於確認失敗發生在哪個階段。將日誌層級暫時調整為 info 或 debug 後重現一次問題，接著恢復原本層級，避免長時間產生大量記錄。分享日誌前，應遮蓋訂閱網址、驗證資訊、節點憑證，以及可能包含個人存取記錄的內容。

建立最小化測試路徑

1. 保留一份可以正常載入的原始訂閱設定。
2. 選擇一個已確認可用的節點與一個穩定的 HTTPS 測試網址。
3. 先關閉 TUN，只使用系統代理驗證瀏覽器存取。
4. 系統代理通過後，再啟用 Rule 模式並檢查規則命中。
5. 最後開啟 TUN，測試不讀取系統代理的應用程式。
6. 每一步都記錄日誌變化，發現故障後停止加入新變數。

這套順序能將問題分為設定來源、遠端節點、網域解析、本機代理與全域接管五個範圍。若最小化設定在多個網路下仍對所有節點逾時，應向訂閱服務提供者確認節點狀態與協定參數；若只有原設定失敗，則應重點比較 DNS、規則、覆寫與 TUN 欄位。

節點逾時排查清單

遇到 Clash 節點無法連線時，可依照下方的固定順序執行。前一項確認正常後，再進入下一項，通常不需要反覆安裝用戶端。

1. 確認裝置本身能直接連線一般網站，目前網路沒有中斷。
2. 確認訂閱更新成功，設定中存在節點與策略群組，核心載入沒有 YAML 錯誤。
3. 測試多個節點，並使用另一個網路或另一台裝置進行交叉驗證。
4. 開啟自動時間與時區同步，排除 TLS 憑證驗證異常。
5. 分別檢查系統 DNS、Clash DNS 與節點伺服器網域解析。
6. 確認策略群組選擇、規則命中與代理模式符合預期。
7. 先驗證系統代理，再單獨檢查 TUN 權限、虛擬網卡與路由。
8. 核對本機監聽連接埠，處理連接埠占用與防火牆限制。
9. 根據日誌關鍵字定位失敗階段，完成最小化重新測試。