Clash 節點逾時、無法連線怎麼辦？從訂閱到 DNS 的逐步排查指南

先分清測速逾時與實際連線失敗

Clash 用戶端顯示「Timeout」，通常表示測試請求未能在限定時間內完成。這不代表伺服器一定離線：測試網址無法連線、DNS 查詢失敗或節點認證失效，都可能出現類似結果。反過來說，測速有延遲數值，只能證明當下測試請求成功，不代表所有網站、UDP 流量和應用程式都能正常使用。

排查的目標是找出失敗發生在哪個環節：取得設定、本機監聽、網域解析、節點交握，還是規則選擇。先備份目前的設定與日誌，再固定一個節點、一個目標網站和一種連線方式，避免同時更新訂閱、修改 DNS、啟用 TUN，導致無法判斷哪項變更有效。

建立基本測試紀錄

• 環境：記錄作業系統、Clash 用戶端版本、核心版本，以及使用 Wi-Fi、行動網路或有線網路。介面版本與 mihomo 核心版本請分開記錄。
• 設定：記錄目前的 Profile 名稱、訂閱上次成功更新的時間、代理模式，以及策略組目前選取的節點。
• 現象：分清楚是「所有節點都逾時」、「只有一個節點失敗」、「測速成功但瀏覽器失敗」，還是「瀏覽器正常但某個應用程式失敗」。
• 時間：例如在 14:30:00 發出請求，接著擷取該時間點前後 30 秒的日誌。這只是紀錄方式，不代表預設的測試結果。

第一步：確認訂閱有效，且設定已套用

訂閱連結是設定的來源，不等同於節點連線本身。訂閱更新成功不代表節點一定可用：取得的設定可能包含已過期的帳號資訊，或是服務商正在維護線路。先開啟 Clash 用戶端的設定檔清單，確認目前啟用的 Profile，再更新該設定檔，並檢查更新結果與時間。

1. 確認帳號狀態。前往訂閱服務商的帳戶頁面，確認有效期限、剩餘流量與裝置數量限制。流量用盡或帳號停用時，在本機調整連接埠通常沒有幫助。
2. 檢查訂閱回應。HTTP 401 或 403 通常與授權或存取政策有關；404 可能表示網址已失效；429 則代表請求受到限制。如果回傳的是登入頁面，而非設定內容，就不能將它當成 YAML 匯入。
3. 確認載入結果。更新後確認節點清單有如預期變更，並留意是否出現 YAML 語法錯誤、未知欄位或不支援的協定提示。有些 Clash 用戶端在更新失敗時，會繼續沿用舊設定。
4. 檢查最終生效的設定。設定合併、覆寫與腳本都可能變更連接埠、DNS 或規則。後續排查應以實際載入的結果為準，而非只看訂閱原文。

所有節點失敗與單一節點失敗的判斷方式

只有單一節點失敗時，先改選同一策略組中的另一個節點重測，再檢查原節點的伺服器位址、連接埠與認證資訊。若所有節點都失敗，優先檢查共用環節：本機網路、系統時間、DNS 與本機核心。若不同節點實際使用相同的伺服器網域，也可能受到同一個解析問題影響。

遠端規則集與代理集合可能透過 rule-providers、proxy-providers 分別取得。主訂閱更新成功，不代表這些資源也已下載。查看日誌中的資源下載錯誤，尤其留意資源下載需要代理，但啟動時又沒有可用代理的相依問題。

第二步：校正系統時間並確認基本網路

系統日期與時間若明顯有誤，可能導致 TLS 憑證效期驗證失敗，也可能影響依賴時間的認證流程。這類錯誤有時出現在節點交握階段，有時則發生在下載訂閱時。先確認年月日與實際時間，不要只看工作列顯示的時刻。

• Windows 11：前往「設定」→「時間與語言」→「日期與時間」，開啟「自動設定時間」，再於「同步時鐘」區域選取「立即同步」。
• macOS：前往「系統設定」→「一般」→「日期與時間」，開啟自動設定日期與時間。不同系統版本的選項名稱可能略有差異。
• Linux：使用 timedatectl status 查看時間與同步狀態；若系統使用 systemd 且支援時間同步，可執行 sudo timedatectl set-ntp true 開啟同步。

暫停 Clash 用戶端的系統代理與 TUN，再試著直接連線到目前網路允許存取的網站，確認基本網路正常。若使用公共 Wi-Fi 且需要登入網頁認證，請先完成認證。基本網路尚未連通時，繼續修改代理規則只會增加干擾。

切換網路進行比對

在同一台裝置、同一份設定下，分別使用原本的網路與手機熱點測試。如果只有原本的網路失敗，問題較可能與該網路的 DNS、對外連線限制或防火牆有關；如果兩種網路都失敗，再檢查裝置與設定。這種比對只能縮小排查範圍，無法直接證明是哪一種封鎖機制。

ping 沒有回應，不能單獨作為節點離線的證據；伺服器可能不回應 ICMP。節點可能透過 TCP、UDP 或其他傳輸方式運作，應搭配實際協定的連線日誌判斷。

第三步：檢查代理連接埠與連線方式

瀏覽器無法連上本機代理，與遠端節點逾時是兩種不同問題。前者常見原因包括核心未啟動、監聽連接埠遭占用，或系統代理仍指向舊連接埠。開啟目前生效的設定，找到 mixed-port，或分別查看 port 與 socks-port。以下以混合連接埠 7890 為例；這只是範例，請替換為實際監聽的連接埠。

查看監聽中的程序

在 Windows 的 PowerShell 中執行下列指令；根據輸出中的 OwningProcess 查詢程序，確認監聽程序是否為預期的核心。

Get-NetTCPConnection -LocalPort 7890 -State Listen
Get-Process -Id (Get-NetTCPConnection -LocalPort 7890 -State Listen).OwningProcess

macOS 可使用 lsof，Linux 可使用 ss；權限不足時可能無法查看程序資訊。

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -ltnp 'sport = :7890'

如果沒有監聽結果，先查看核心啟動日誌。若出現 address already in use，請關閉占用相同連接埠的舊程序，或修改目前 Clash 用戶端的監聽連接埠。不要直接結束不熟悉的系統程序，請先確認其名稱與來源。修改後也要同步檢查系統代理位址，否則瀏覽器可能仍連到舊連接埠。

明確指定代理進行測試：略過系統代理開關

下列指令會直接指定本機 HTTP 代理，用來確認監聽連接埠、代理轉送與目標請求是否連通。Windows 建議使用 curl.exe，避免部分 PowerShell 環境將 curl 解讀為其他指令；macOS、Linux 則可將指令名稱改為 curl。

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

• 立即拒絕連線：優先檢查本機監聽位址、連接埠與核心狀態，不要先急著更換節點。
• 收到 HTTP 回應：表示這次請求已完成。若瀏覽器仍無法連線，請檢查系統代理、瀏覽器代理設定或擴充功能。
• 等待後逾時：查看同一時間的日誌，分辨是連線節點伺服器失敗、TLS 交握失敗，還是目標網站回應逾時。

此處的 10 秒是連線階段的時間上限，20 秒是整體請求的時間上限，不是延遲測量值。測試結果也會受到目前規則影響：若目標命中 DIRECT，只能證明直連路徑可用。要測試指定節點，請暫時選取對應策略並確認連線紀錄，完成後再還原原本模式。

第四步：沿著實際 DNS 路徑檢查解析

排查 DNS 問題時，至少要分清兩件事：節點伺服器的網域能否解析，以及目標網站的網域能否解析。前者失敗時，無法建立節點連線；後者失敗時，節點可能測速正常，但特定網站仍無法存取。日誌中的 no such host、DNS 查詢逾時與解析器連線失敗，比介面統一顯示的「逾時」更有助於定位問題。

先檢查系統解析，再檢查核心解析

# Windows PowerShell：檢查系統 DNS 回應
Resolve-DnsName example.com

# 一般桌面系統可用的基本查詢
nslookup example.com

將範例網域替換為日誌中實際解析失敗的網域。系統查詢成功，不代表 Clash 用戶端核心使用的解析器也能正常運作；核心啟用自有 DNS、TUN 接管 DNS，或應用程式使用加密 DNS 時，解析路徑都可能不同。請對照有效設定中的 dns.enable、nameserver 與日誌逐項確認。

上述欄位的支援範圍與行為取決於核心版本，修改前請查閱對應版本的文件。不要將某份 mihomo 設定直接套用在不支援這些欄位的舊版核心上。也不要只因為加入多個公用 DNS 就認定問題已解決；解析器可連線性、分流策略與引導解析都需要逐一驗證。

Fake-IP 位址不是節點伺服器位址

啟用 Fake-IP 時，解析結果可能是設定的映射位址範圍，例如 198.18.0.0/16。這是用來關聯網域與連線的內部映射，看到這類位址不代表 DNS 遭到污染。關鍵在於後續連線是否回到同一個核心，並正確還原網域。

切換 DNS 模式後，若應用程式仍使用舊快取，請先重新啟動受影響的應用程式，再依作業系統的方式清除 DNS 快取。Windows 可執行 ipconfig /flushdns，但這不會自動清除瀏覽器本身的快取或核心映射。若區域網路服務確實與 Fake-IP 不相容，可依據日誌設定具體的 fake-ip-filter，不必先讓所有網域都略過 Fake-IP。

第五步：確認規則命中與策略組選擇

節點有延遲，但網頁無法開啟，常見原因是請求沒有使用預期的節點。規則模式會依設定順序比對；網域規則、IP 規則、程序規則與最後的兜底規則，可能將不同請求導向不同策略。查看 Clash 用戶端的連線紀錄，至少確認目標網域、命中的規則、最終策略鏈，以及實際使用的出口節點。

1. 固定一個節點。在手動選擇的策略組中指定節點，避免自動測速策略組在排查期間切換出口。
2. 重新建立連線。關閉舊分頁或重新啟動應用程式後再測試。既有的長連線不一定會在切換策略後立即改用新節點。
3. 確認 DIRECT 與 REJECT。請求若命中直連或拒絕策略，更換代理節點不會改變結果，應先檢查對應規則。
4. 短暫切換至全域模式比對。確認全域策略也選取了待測節點。若全域模式可用、規則模式失敗，應優先檢查規則與策略組；測試完成後請還原規則模式。

全域模式也不會自動接管所有應用程式。只啟用系統代理時，不遵循系統代理設定的應用程式仍可能直接連線。若明確指定代理的指令運作正常，但某個遊戲、命令列程式或即時通訊應用程式失敗，請先確認它是否支援 HTTP/SOCKS 代理，再決定是否使用 TUN。

分別測試 TUN 與 UDP

TUN 會將系統 IP 流量交由虛擬網路介面處理，因此需要相應的權限、路由與 DNS 接管設定。瀏覽器可以使用，但 TUN 無法運作時，請檢查服務安裝狀態、管理員權限、虛擬介面，以及是否與其他 VPN 發生路由衝突；不要把所有問題都歸因於節點失效。

HTTPS 網頁測試主要驗證 TCP 路徑，無法證明 UDP 可用。遊戲、語音與部分 QUIC 連線還取決於節點協定支援、伺服器轉送能力與本機網路環境。請分別測試相關應用程式並檢查 UDP 日誌；單純將設定中的 UDP 開關設為啟用，無法讓不支援 UDP 轉送的伺服器端突然具備此能力。

最後：查看日誌，排查交握與伺服器問題

確認訂閱、時間、連接埠、DNS 與規則都沒有問題後，再排查節點交握與伺服器。可暫時將日誌層級調整為 debug，重現一次問題後再恢復常用層級。不同 Clash 用戶端的操作入口各有差異，請先在日誌頁面尋找匯出功能，不必猜測固定目錄。

連接埠、密碼、UUID、SNI、WebSocket 路徑與 Reality 參數等需要伺服器端配合的欄位，應以訂閱服務商提供的有效設定為準。任意修改其中一個欄位，都可能讓原本可用的節點無法完成交握。若只有一個節點在兩種網路下都持續失敗，而其他節點正常，可先改用可用節點，再向服務商回報問題。

回報問題時請保留以下四項證據

• 作業系統、Clash 用戶端與核心的具體版本，以及問題開始時間。
• 是所有節點還是部分節點失敗，以及使用系統代理或 TUN 時哪種方式出現問題。
• 明確指定代理的測試結果、規則命中結果，以及切換網路後的比對結果。
• 涵蓋單次失敗請求前後、已遮蔽敏感資訊的日誌，不要只附一張「Timeout」截圖。

若要重新整理匯入與連線步驟，請參閱使用說明；若涉及 DNS、規則與 TUN 參數，請繼續閱讀進階設定。每次只變更一個項目，並保留可還原的設定，比反覆重新安裝更有助於找出問題。