節點逾時或無法連線？依序排查

1. 分辨測速逾時與實際連線失敗

FlClash 的延遲測試通常是透過節點向指定測試網址發出請求，不是單純對節點伺服器執行 ping。顯示「逾時」代表這次探測未能在時限內完成；問題可能出在節點入口、網域解析、協定交握，也可能只是測試網站無法連線。先記下實際狀況，再判斷要檢查哪個環節。

2. 本機網路：先確認關閉接管後能否直連

先在 FlClash 中關閉系統代理與 TUN，再連線至平時可直連的網站。如果作業系統仍保留手動代理設定，也要檢查並還原；只退出用戶端可能會留下指向本機連接埠的代理設定。此時瀏覽器會繼續連線至已停止監聽的連接埠，看起來就像整個網路中斷。

檢查網路入口與系統時間

1. 完成網路登入。飯店、校園或公共 Wi-Fi 可能需要先在瀏覽器完成登入驗證。確認系統沒有顯示「需要登入網路」的提示。
2. 檢查系統代理。Windows 11 可前往「設定」→「網路和網際網路」→「Proxy」，確認手動代理與設定指令碼；macOS 可前往「系統設定」→「網路」→目前使用的網路→「詳細資訊」→「代理伺服器」。
3. 校正系統時間。Windows 11 的路徑為「設定」→「時間與語言」→「日期與時間」。日期、時區或時鐘偏差可能影響 TLS 憑證驗證及部分代理協定的驗證。
4. 切換網路。保持節點不變，將電腦從原本的 Wi-Fi 切換至手機熱點。如果透過熱點可以連線，優先檢查原網路的 DNS、防火牆或出口限制。

一般網站可以直連，只能表示基本網路連線正常，不能證明節點連接埠也能連通。反過來說，ping 沒有回應也不足以證明伺服器已離線，因為伺服器或電信網路可能會封鎖 ICMP。接下來需要針對訂閱中的伺服器位址與實際連接埠進一步確認。

3. 訂閱狀態：分辨下載成功、設定生效與帳戶可用

在 FlClash 的「設定檔」頁面找到目前使用的訂閱，手動更新，並確認選取的仍是這份設定檔。不同版本的按鈕名稱可能略有差異，請以目前介面為準。更新完成後，再前往「代理」頁面確認節點清單及所選策略組，避免測試到舊設定檔或其他群組中的節點。

分三個層面檢查

• 訂閱請求：若回應 HTTP 401 或 403，請優先檢查連結憑證與伺服器端的存取限制；若回應 404，請確認網址是否已過期或路徑是否變更。HTTP 200 只表示請求成功，回應內容也可能是登入頁面，而非設定檔。
• 設定檔解析：查看記錄中是否出現 YAML 語法錯誤、未知的代理類型或設定載入失敗。可供其他用戶端使用的分享連結，不一定能直接匯入作為完整的 mihomo 設定檔。
• 服務帳戶：前往訂閱服務提供者的網站，確認到期日、剩餘流量、裝置數量及維護公告。帳戶失效時，本機仍可能保留完整的節點清單。

如果設定檔使用遠端代理集合，也要確認相關集合是否更新成功。主設定檔下載成功，不代表每個遠端資源都已更新。需要重新匯入時，請參考訂閱匯入步驟；訂閱來源說明請參閱訂閱來源與使用範圍。

4. 系統代理與 TUN：確認連線確實進入 FlClash

系統代理主要影響遵循系統代理設定的應用程式；TUN 則透過虛擬網路介面與路由接管流量。兩者的排查起點不同。先選擇一種方式進行最小化測試，比同時啟用多個用戶端、瀏覽器代理擴充功能與 TUN 更容易找出問題。

桌面版：先測試本機代理連接埠

關閉 TUN，讓 FlClash 核心繼續執行，並確認用戶端顯示的實際監聽位址、混合連接埠及系統代理開關。以下以本機混合連接埠 7890 為例；若設定檔使用其他連接埠，請改用實際值。請勿只憑教學內容猜測連接埠號碼。

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

在 Windows PowerShell 中，可將命令開頭改為 curl.exe，避免舊版環境將 curl 解讀為其他命令。執行時同時查看 FlClash 的連線記錄：收到 HTTP 回應，表示這次代理請求已送達目標；若本機連接埠拒絕連線，應先檢查監聽連接埠、核心執行狀態或連接埠占用情況。

• 命令可連線，瀏覽器卻不行：優先檢查系統代理、瀏覽器擴充功能、瀏覽器本身的代理設定，以及是否使用了另一份自動代理設定指令碼。
• 連線已進入用戶端，但出口不正確：檢查「代理」頁面的模式與策略組選擇。規則模式可能會將目標分流至 DIRECT；測速成功也不代表實際瀏覽網頁時使用了該節點。
• 連線記錄完全沒有請求：先確認應用程式是否繞過代理。此時不要反覆修改遠端節點參數。

TUN 路徑：檢查權限、路由與 VPN 衝突

停止其他 VPN 或同類型的 TUN 用戶端，依系統提示授予所需權限，再單獨啟用 FlClash 的 TUN。查看記錄是否明確指出虛擬介面建立失敗、權限不足或路由寫入失敗。桌面環境可能需要系統管理員權限或用戶端提供的服務支援，實際需求依作業系統與版本而異。

Android 上請確認已允許 VPN 連線，並檢查應用程式存取控制是否排除了目標應用程式。如果系統設定了其他「永遠開啟的 VPN」或「封鎖未使用 VPN 的連線」，也請一併確認。不要長期關閉防火牆來測試；可查看封鎖記錄，並為已確認可信任的用戶端建立範圍明確的規則。

5. DNS 設定：分別檢查節點網域與目標網域

代理連線通常涉及兩種網域解析：一種是將節點伺服器網域解析為入口 IP，另一種是解析要造訪的網站網域。節點入口解析失敗時，連線尚未抵達代理伺服器；目標網域解析失敗時，則可能出現節點測速正常、部分網頁無法開啟的情況。判斷時應搭配錯誤記錄中的實際主機名稱。

先以系統 DNS 解析結果作比較

nslookup example.com

將命令中的網域換成實際發生錯誤的網站網域，或設定檔中的節點伺服器網域。逾時、查無記錄與回傳異常位址，分別代表不同的排查方向。nslookup 的結果只反映這次查詢所使用的解析路徑，不能直接視為 mihomo 的最終結果；啟用 TUN DNS 劫持時，查詢也可能由用戶端接管。

• 記錄出現解析錯誤：先確認 DNS 上游本身可以連線。使用加密 DNS 時，也必須先解析其伺服器網域，並確保相關流量的路由正常。
• 記錄出現循環連線或反覆解析：檢查是否將解析節點入口所需的 DNS 請求，又交由尚未成功連線的同一個代理處理。
• 只有瀏覽器發生異常：檢查瀏覽器的「安全 DNS」或自訂解析設定，暫時改回使用系統解析作比較，再重新開啟相同網址。
• 回傳 Fake-IP 位址：若設定檔使用 Fake-IP 模式，出現常見設定範圍內的 198.18.0.0/16 位址，不代表解析必然出錯；請繼續檢查位址對應與接管鏈路。

mihomo 設定中的 nameserver 與 proxy-server-nameserver 用途不同，後者用於解析代理節點網域。若設定由訂閱或覆寫功能管理，請先備份並確認最終生效的內容，再修改對應欄位。隨意貼上一整段 DNS 設定，容易同時變更解析模式、路由行為與規則比對條件。

6. 節點本身：從入口連線檢查到協定交握

完成前面的本機測試後，再檢查遠端節點。先固定同一個節點，分別透過原網路與手機熱點測試；接著固定網路，改用入口不同的節點。名稱看似不同的節點可能共用同一台伺服器，因此應比對伺服器位址，而不只看地區名稱。

依錯誤階段判讀記錄

使用 TCP 入口的節點，可在 Windows PowerShell 中測試實際伺服器連接埠是否可連線。以下僅示範命令格式，使用的是保留用途的範例網域，執行結果不能代表真實節點狀態：

Test-NetConnection -ComputerName node.example.com -Port 443

請換成設定檔中的實際位址與連接埠，且只測試有權使用的服務。TcpTestSucceeded 為 True，只表示 TCP 連線已建立，不代表密碼、TLS、WebSocket 路徑或完整代理協定設定正確。Hysteria2、TUIC 等使用 UDP 傳輸的節點，也不能依 TCP 測試結果判斷是否可用。

若 TCP 可連線但協定交握失敗，應優先重新取得服務提供者的設定，並確認伺服器名稱、驗證資訊與傳輸參數。遇到憑證錯誤時，應修正系統時間、憑證鏈或伺服器名稱設定，避免長期以略過憑證驗證的方式處理。

7. 恢復驗證：記錄結果，再還原日常設定

節點恢復後，切回日常使用的規則模式，重新啟用系統代理或實際需要的 TUN 接管方式。依序測試一個直連網站、一個需要代理的網站及一個常用應用程式，並在連線記錄中確認出口策略。全域模式下可以連線，只能證明該次代理鏈路正常；規則模式的分流結果仍須另行確認。

1. 記錄環境：作業系統、FlClash 版本、核心版本，以及故障發生的日期與時間。版本資訊請以用戶端實際顯示為準。
2. 記錄比較結果：原本的 Wi-Fi 與手機熱點是否有差異、同一節點能否在其他裝置使用，以及其他入口是否正常。
3. 記錄連線方式：使用系統代理或 TUN、實際監聽連接埠、出口模式，以及請求命中的策略組。
4. 保存錯誤資訊：只擷取與這次問題重現相關的記錄片段，並隱藏憑證、訂閱連結及不必要的瀏覽記錄。

如果所有節點只在某個網路下失敗，優先處理該網路的 DNS 解析與出口限制；如果某個節點在不同網路、不同裝置上都無法使用，則應將入口資訊與記錄交由服務提供者檢查。依層次找出問題後再修改設定，才能釐清因果關係。更多流量接管與分流概念，請參考協定詳解。