FlClash 節點逾時、無法連線怎麼辦？訂閱、時間同步與 DNS 逐步排查

1. 先分清節點測試逾時與實際連線失敗

FlClash 節點測試失敗，不一定代表所有網頁都無法開啟。測試會連線至指定的檢測網址；網址遭到封鎖、回應異常，或回應時間超過測試時限，都可能顯示逾時。反過來說，測試成功也只表示這次探測可用，無法證明所有網域、UDP 要求與應用程式連線都正常。

排查時先保留現況：記下 FlClash 版本、作業系統版本、目前設定檔名稱、出站模式，以及某次失敗的時間。接著以相同網址和相同方式重試，每次只變更一項設定。不同版本的選單位置可能有所不同，以下以設定項目名稱和可確認的系統操作為準；範例連接埠不代表用戶端的預設值。

先暫停其他代理用戶端和 VPN，避免多個程式同時變更系統代理或路由。若需要連線公司網路，請勿自行停用受管理的安全軟體，應先向管理員確認允許的連線方式。

2. 確認訂閱更新成功，且目前使用的是正確設定

更新成功後，也要確認目前使用的是哪份設定

1. 開啟 FlClash 的設定檔清單，找到預計使用的訂閱並執行更新，記下更新結果和時間。
2. 確認目前選取的設定檔就是剛更新的那一份。清單中有新設定檔，不代表核心已切換至該設定檔。
3. 檢查代理頁面是否顯示預期的策略群組與節點。若策略群組是空的，請先查看設定載入錯誤，不要直接修改 DNS。
4. 在目前規則所引用的策略群組中手動選取一個節點，再測試同一網址。自動選擇群組可能在測試時重新選取出站節點，導致前後結果無法比較。

訂閱下載失敗和節點連線失敗是兩條不同的流程。前者是用戶端取得設定的過程，後者是 mihomo 核心依據設定連線至伺服器的過程。舊設定仍可能繼續運作，因此「訂閱更新失敗，但網頁還能開啟」並不矛盾。

依回傳的錯誤處理，勿反覆匯入相同網址

• HTTP 401 或 403：檢查訂閱是否過期、連結是否已重設，以及伺服器是否限制存取；這些狀態碼也可能由閘道器回傳，請一併確認回應來源。
• HTTP 200，但設定解析失敗：回應內容可能是登入頁、驗證頁或不相容的資料。狀態碼成功不代表取得了有效設定。
• 網域解析失敗或連線逾時：先確認目前網路能否連線至訂閱所在的網域。訂閱更新是否經由代理，取決於用戶端版本和相關設定，不能單憑瀏覽器的結果判斷。
• 更新後部分節點消失：確認方案狀態和服務商是否有變更，再檢查設定中引用的策略群組，避免繼續選用已失效的項目。

3. 檢查基本網路連線與系統時間

先關閉 FlClash 的系統代理和 TUN，再確認一般直連網頁能否開啟。若網路需要入口網站驗證，請先完成 Wi-Fi 登入。也可以將電腦改連手機熱點，維持設定和測試網址不變：若同一節點只在特定網路下失敗，應優先檢查該網路的出口限制、路由或 UDP 支援，而不是重新安裝用戶端。

時間偏差可能影響 TLS 與部分通訊協定的驗證

請分別確認系統日期、顯示的時區和實際時間。時區顯示不同不一定會造成驗證失敗，但系統時鐘偏離實際時間，可能讓憑證被判定為尚未生效或已過期；部分具有時間校驗的通訊協定也會因此拒絕連線。

• Windows 11：前往「設定」→「時間與語言」→「日期與時間」，開啟「自動設定時間」，然後選取「立即同步」。
• Android：通常可在「設定」→「系統」→「日期與時間」開啟自動設定；不同廠牌可能將此選項放在「更多設定」中。
• macOS：前往「系統設定」→「一般」→「日期與時間」，確認已開啟自動設定日期與時間。

同步後重新連線，確認憑證錯誤是否消失。若時間正確但仍出現 TLS 錯誤，請繼續檢查伺服器網域、憑證及設定中的 TLS 參數。不要將略過憑證驗證當作一般修復方式；這會降低連線身分驗證的安全性，也無法解決伺服器無法連線的問題。

4. 檢查混合連接埠、核心啟動狀態與防火牆

系統代理只是將支援代理的應用程式指向本機監聽連接埠。如果 mihomo 尚未啟動，或監聽連接埠已被其他程式占用，即使瀏覽器顯示已設定代理，也無法透過 FlClash 建立連線。先查看用戶端記錄是否出現 address already in use、bind 或設定載入失敗等訊息。

使用實際混合連接埠進行明確代理測試

在 FlClash 設定中找到「混合連接埠」，並記下數值。以下統一以 7890 為例；只有用戶端顯示的連接埠也是 7890 時，才能直接執行。測試網址可替換為目前確實需要連線且允許存取的 HTTPS 網站。

# Windows PowerShell：查看 7890 的監聽程序
Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

# Windows：透過本機 HTTP 代理明確發送要求
curl.exe -I --proxy http://127.0.0.1:7890 --connect-timeout 8 --max-time 20 https://example.com/

# macOS / Linux：檢查監聽狀態並執行相同要求
lsof -nP -iTCP:7890 -sTCP:LISTEN
curl -I --proxy http://127.0.0.1:7890 --connect-timeout 8 --max-time 20 https://example.com/

此處的 8 秒是連線階段的逾時上限，20 秒是整個要求的總時限，並非節點品質標準。curl -I 會傳送 HEAD 要求，有些網站可能回傳 403 或 405；收到 HTTP 回應表示連線已進入伺服器回應階段，但仍須一併確認 TLS 是否完成，以及用戶端的連線記錄。

• 立即顯示連線遭拒：優先確認本機連接埠是否正確，以及核心是否正在執行。通常無法只靠更換遠端節點解決。
• 連接埠由其他程序監聽：依程序 ID 確認是哪個程式，正常結束衝突程式，或變更 FlClash 連接埠並同步更新應用程式的代理設定。不要直接終止不明的系統程序。
• 本機代理連線成功，之後逾時：繼續檢查遠端連線、規則和 DNS，並查看同一時間的記錄。

依程式與網路範圍設定防火牆允許規則

防火牆或端點安全軟體可能會限制核心的對外連線。請檢查封鎖記錄，並針對實際執行檔設定允許規則；升級後若檔案位置變更，也要確認規則仍然有效。本機代理測試通常不需要開啟「允許區域網路連線」，也不必開放公用網路的輸入連接埠。不要長期以停用整套防火牆作為處理方式。

5. 查看記錄，分辨 DNS 解析失敗與遠端連線逾時

網域至少涉及兩個必須區分的對象：代理伺服器的網域，以及最終要造訪的網站網域。若伺服器網域無法解析，連線會在抵達代理伺服器前就失敗；網站網域的解析路徑則取決於規則、出站通訊協定和 DNS 設定。看到 DNS 錯誤時，先確認發生錯誤的是哪個網域，再決定要調整哪一層。

系統查詢只能檢查系統 DNS 路徑

# 查詢範例網站的系統 DNS 結果
nslookup example.com

如果系統查詢也失敗，可以先檢查網路是否正常，以及系統 DNS 是否可用。若查詢成功，但 FlClash 記錄仍顯示 no such host 或解析逾時，表示仍須另外確認用戶端核心使用的 DNS 路徑。設定中的 nameserver、proxy-server-nameserver 和 direct-nameserver 用途各不相同，不能因系統查詢成功就認定這些路徑都正常。

• 節點伺服器網域解析失敗：確認用來解析代理伺服器網域的解析器是否可連線，並避免解析器本身必須仰賴尚未連通的代理才能使用。
• DNS-over-HTTPS 要求逾時：檢查解析服務網域的引導解析、HTTPS 連線和路由是否正常。將所有解析器改成同一個位址，可能會擴大故障範圍。
• 出現 198.18.0.0/15 範圍內的位址：在 Fake-IP 模式下，這可能是預期的對應結果，不能只憑位址格式就判定解析錯誤。
• 只有一個網站異常：先確認該網域命中的規則、DNS 回應和目標服務狀態，避免為了單一網站的問題修改整份設定。

調整 DNS 後，透過用戶端提供的重新載入或重新啟動核心功能套用設定，再關閉舊連線並重新測試。Windows 的 ipconfig /flushdns 只會清除系統 DNS 快取，不代表 mihomo 的 DNS 快取和既有連線也已清除。每次只修改一項，並保留可還原的原始設定。

6. 確認出站模式、規則命中與 TUN 接管範圍

規則模式失敗時，可用全域模式縮小排查範圍

規則模式會依照由上而下的順序比對，命中第一條規則後就採用對應的出站方式。若瀏覽器要求命中 DIRECT，即使節點測試成功，該要求也不一定經過選取的節點。開啟用戶端的連線記錄，比對目標網域、命中規則和最終出站方式，確認發生問題的要求實際經過哪條路徑。

1. 維持相同節點和測試網址，暫時切換至全域模式，並確認全域策略群組已選取該節點。
2. 若全域模式可用、規則模式失敗，請檢查相關規則是否指向錯誤的策略群組、DIRECT 或 REJECT。
3. 若兩種模式都失敗，請繼續檢查伺服器連線和 DNS，不要只調整規則順序。
4. 測試完成後請還原原本的模式。全域模式只用於比較測試，不代表適合所有流量。

系統代理與 TUN 處理的是不同問題

明確代理測試成功，但特定應用程式仍無法連線時，應檢查該應用程式是否遵循系統代理。部分應用程式會自行建立連線或使用 UDP，不會因為開啟系統代理就自動透過用戶端連線。TUN 可透過虛擬網路介面接管更多流量，但仍會受到路由、權限和排除規則影響，無法保證接管所有流量。

啟用 TUN 前，先確認一般代理連線正常。桌面系統可能需要管理員權限或服務支援；Android 則需要授予 VPN 連線權限，而且通常無法與另一個使用 VPN 的應用程式同時執行。啟用 TUN 後若整台裝置都無法上網，請先關閉 TUN 以恢復網路，再檢查虛擬介面、路由和其他 VPN 是否衝突。不要同時修改 TUN、DNS 和規則，否則難以確認是哪項設定造成影響。

7. 整理排查結果：何時更換節點，何時提交記錄

完成上述比對後，結論應能指向具體層級，而不是只剩下「FlClash 無法使用」。如果單一節點在不同網路下都失敗，而其他節點可用，較適合向服務商確認伺服器狀態和憑證；如果所有節點只有在同一個網路下失敗，應優先檢查本機網路限制。若明確代理可用、系統代理卻無法使用，請著重檢查系統設定是否被其他程式覆寫。

提交問題前，請保留以下六項資訊

• FlClash 版本、系統版本，以及記錄中顯示的 mihomo 核心版本。
• 失敗時間與時區，方便比對伺服器端記錄。
• 訂閱是否更新成功，以及目前的設定檔是否載入成功。
• 系統代理與 TUN 的啟用狀態、實際混合連接埠，以及目前的出站模式。
• 同一網址透過明確代理、規則模式和全域模式測試的結果。
• 包含一次失敗前後的簡短記錄，並隱藏訂閱權杖、帳戶憑證和不宜公開的位址。

需要重新確認初始設定時，可先閱讀入門指南；需要依照故障現象繼續排查時，可參閱問題診斷。更新用戶端前，請保留目前設定檔和重要設定；更新後重複相同的測試，才能判斷變化是否來自版本或設定。