Clash 節點逾時無法連線：從用戶端設定到本機網路的排查順序

先判斷是哪一種「逾時」

Clash 顯示逾時，不代表問題一定發生在節點伺服器。測速請求依序經過用戶端核心、網域解析、本機網路、節點入口與測試網址，其中任何一步未在限定時間內回應，都可能顯示 Timeout。先縮小範圍再修改設定，比反覆更新訂閱更有效。

透過對照測試區分節點問題與本機問題

1. 保持目前訂閱不變，連續測試至少 3 個不同地區、不同入口的節點。
2. 關閉 Clash 的系統代理與 TUN，直接開啟平時可以存取的網站，確認基礎網路正常。
3. 重新啟動 Clash 核心，只開啟系統代理，再測試瀏覽器存取。
4. 將同一訂閱暫時匯入另一台裝置或切換到其他網路，例如手機熱點，比較測試結果。

如果同一節點在家用寬頻下逾時、使用手機熱點卻可用，問題較可能出在本機、路由器或目前的網路出口。如果多台裝置、不同網路都只有同一個節點失敗，而同一訂閱的其他節點正常，通常可將範圍縮小到該節點的入口、連接埠或協定參數。

第一步：確認用戶端核心、設定與代理連接埠

排查所有節點逾時時，先確認 Clash Meta（mihomo）核心已成功啟動。圖形介面能夠開啟，不代表核心正在監聽連接埠。若記錄出現 address already in use、configuration file test failed 或持續重新啟動，應先處理連接埠衝突與設定錯誤。

檢查核心狀態與目前設定

以 Clash Verge Rev 2.4.2 的常見介面為例，可在「設定」→「Clash 設定」查看目前核心與連接埠，在「訂閱」中確認正在使用的設定。不同用戶端的名稱可能是「核心」、「設定」或「Profiles」，判斷標準一致：設定處於啟用狀態，核心狀態為執行中，記錄沒有循環報錯。

• Mixed Port：常見值為 7890，同時接受 HTTP 與 SOCKS5 請求。
• HTTP Port：舊設定中常見 7890。
• SOCKS Port：舊設定中常見 7891。
• External Controller：常見監聽位址為 127.0.0.1:9090，這是控制介面，不是應用程式代理連接埠。

不要將瀏覽器代理填寫為控制連接埠 9090。如果設定只宣告 mixed-port: 7890，瀏覽器或系統代理應指向 127.0.0.1:7890。修改連接埠後，也要同步更新系統代理、瀏覽器擴充功能與其他手動設定。

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

排除連接埠占用

Windows 可在 PowerShell 中檢查 7890 連接埠是否已有程序監聽：

Get-NetTCPConnection -LocalPort 7890 -ErrorAction SilentlyContinue
Get-Process -Id (Get-NetTCPConnection -LocalPort 7890).OwningProcess

macOS 與 Linux 可使用：

lsof -nP -iTCP:7890 -sTCP:LISTEN
ss -lntp | grep 7890

如果舊版 Clash、其他代理工具或殘留的背景程序占用同一連接埠，應先結束衝突程式，再重新啟動目前的用戶端。不要同時讓兩個程式寫入系統代理，否則介面顯示的連接埠可能與作業系統實際使用的連接埠不一致。

第二步：從系統代理縮小到 TUN 模式

基礎排查應先使用系統代理，不要一開始就啟用 TUN。系統代理鏈路較短，方便確認節點是否能建立連線。以 Clash Verge Rev 2.4.2 為例，進入「設定」→「系統設定」→「系統代理」，啟用後檢查系統代理伺服器是否為 127.0.0.1，連接埠是否與 Mixed Port 一致。

瀏覽器正常但應用程式仍直接連線

系統代理只對主動讀取作業系統代理設定的應用程式生效。部分遊戲、命令列工具、虛擬機器和使用自有網路堆疊的軟體會忽略系統代理。此時瀏覽器可以正常存取，並不代表所有應用程式都已被接管。

• 先在 Clash 的「連線」面板中搜尋目標網域或程序。
• 看不到任何記錄，通常表示流量沒有進入 Clash。
• 看得到記錄但狀態反覆顯示正在連線，請繼續檢查節點入口與 DNS。
• 記錄顯示 DIRECT，應檢查規則命中結果，而不是更換節點。

啟用 TUN 後全部逾時

TUN 模式透過虛擬網卡與路由規則接管更多流量。Windows 通常需要系統管理員權限與可正常載入的虛擬網卡驅動程式；macOS 首次啟用時需要核准網路延伸功能；Linux 則需要 /dev/net/tun 與相應的網路管理權限。

如果關閉 TUN 後系統代理可用，表示節點本身大致正常。此時應單獨排查 TUN，而不是繼續修改訂閱。請依以下順序恢復：

1. 關閉 TUN，結束用戶端，確認系統網路恢復。
2. 重新啟動用戶端，先驗證 Mixed Port 代理可用。
3. 以所需權限啟動用戶端，再啟用 TUN。
4. 檢查是否同時執行 VPN、虛擬機器橋接、流量過濾器或另一套 TUN 軟體。
5. 若出現網域無法開啟但 IP 可以存取，請轉入 DNS 排查。

第三步：檢查 DNS 與節點入口網域

節點位址可能是 IP，也可能是網域。使用網域作為伺服器位址時，Clash 必須先透過本機解析器或設定中的預設解析器取得入口 IP。如果入口網域解析失敗，所有依賴同一入口的節點都會一起逾時，即使代理協定參數完全正確。

先在作業系統層級檢查解析

Windows 可執行：

nslookup node.example.com
Resolve-DnsName node.example.com

macOS 或 Linux 可執行：

dig node.example.com
nslookup node.example.com

node.example.com 應替換為設定中節點的實際 server 值。如果回傳 NXDOMAIN、逾時或沒有 A/AAAA 記錄，應先確認訂閱中的入口網域是否仍然有效。若多個失敗節點共用同一入口網域，這項檢查尤其重要。

區分入口解析與代理內部 DNS

Clash 的 DNS 設定既負責應用程式網域解析，也可能參與節點入口解析。mihomo 設定中的 default-nameserver 主要用於解析 DNS 伺服器本身及節點入口等基礎目標，通常應填寫可直接存取的 IP 格式 DNS 位址，避免形成「需要代理才能解析代理入口」的循環依賴。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8
  nameserver:
    - https://1.1.1.1/dns-query

這段內容僅用於說明設定層級，並不表示每個網路都適合相同的解析器。企業網路、校園網路或含有內部網域的環境，可能必須保留區域網路 DNS。修改前應先備份原設定，修改後重新載入，並觀察記錄中是否出現 lookup、no such host 或 DNS 請求逾時。

如果只有 IPv6 入口失敗，可以暫時確認目前網路是否具備可用的 IPv6 路由。解析取得 AAAA 記錄不代表本機一定能連線至 IPv6。不要長期依賴隨意關閉 IPv6 來掩蓋問題，應進一步確認路由器、電信業者鏈路與節點入口的實際支援情況。

第四步：單一節點逾時時核對協定參數

只有一個節點失敗，而同一訂閱的其他節點可用時，本機系統代理與基礎 DNS 通常沒有大問題。重點應轉向該節點的伺服器位址、連接埠與協定欄位。重新匯入訂閱可以排除手動編輯造成的欄位遺失，但無法修復伺服器離線或訂閱來源本身的資料錯誤。

不要憑經驗隨意切換 tls、udp 或 skip-cert-verify。這些欄位必須與伺服器端設定相符。尤其不應把略過憑證驗證當作通用修復方式；它可能暫時掩蓋錯誤，卻無法解決 SNI、憑證期限或系統時間不正確等問題。

檢查本機時間

TLS 握手需要準確的時間。Windows 可進入「設定」→「時間與語言」→「日期與時間」，啟用自動設定時間並執行立即同步。macOS 可進入「系統設定」→「一般」→「日期與時間」，開啟自動設定。系統時間偏差數分鐘，就可能導致判定憑證尚未生效或已經過期。

確認節點連接埠是否可達

Windows PowerShell 可針對節點伺服器與連接埠執行 TCP 探測：

Test-NetConnection node.example.com -Port 443

macOS 或 Linux 可使用：

nc -vz node.example.com 443

TCP 測試成功只表示入口連接埠可以建立連線，不代表 UUID、密碼、TLS 或傳輸參數正確。測試失敗則可能是伺服器未監聽、入口位址失效、防火牆丟棄封包或目前網路有限制。部分 UDP 協定也無法直接用 TCP 探測判斷，需結合核心記錄與其他網路對照測試。

第五步：排查防火牆、路由器與目前網路

當所有節點都失敗，而設定在另一台裝置上可以正常使用時，應檢查本機安全性原則。Windows 防火牆可能允許圖形介面連線，卻阻止實際執行的 mihomo 核心；第三方安全軟體也可能依程序路徑建立規則，用戶端升級後核心檔案路徑變更，舊有放行規則便不再符合。

Windows 檢查順序

1. 開啟「Windows 安全性」→「防火牆與網路保護」→「允許應用程式通過防火牆」。
2. 確認目前 Clash 用戶端與 mihomo 核心在正在使用的網路類型下取得存取權限。
3. 進入「設定」→「網路和 Internet」→「代理」，檢查是否殘留失效的手動代理。
4. 結束其他 VPN、代理與網路過濾程式，再重新啟動 Clash。
5. 使用手機熱點重新測試，判斷問題是否只出現在目前的路由器或寬頻。

暫時關閉防火牆只能作為短時間的對照測試。確認是規則造成後，應恢復防火牆並為實際核心程式建立明確規則，而不是長期保持關閉。

路由器與網路出口

路由器的家長監護、訪客網路隔離、企業出口 ACL、公共 Wi-Fi 認證頁面都可能影響節點連線。先開啟一般 HTTP 與 HTTPS 網站，確認認證流程已完成。若切換至手機熱點後立即恢復，可依序檢查路由器 DNS、IPv6、MTU、存取控制與上游網路限制。

MTU 問題通常表現為 TCP 可以建立連線，但在 TLS 或大封包階段卡住。TUN 環境下若小型網頁偶爾能開啟、圖片和下載長時間停滯，可將 MTU 列為後續檢查項目，但不要在沒有對照結果時隨意修改。先記錄原值，再依用戶端支援的設定逐步調整，每次變更控制在小幅範圍內。

如何閱讀記錄：用錯誤關鍵字定位階段

將記錄層級暫時設為 info 通常已經足夠。只有需要追蹤規則與握手細節時，才短時間使用 debug，完成後恢復原設定，避免記錄快速增加。重現問題時記下準確時間、節點名稱與目標網域，再搜尋同一時間附近的資訊。

i/o timeout 只是結果，無法直接指出責任方。必須結合前面的目標位址判斷：如果逾時目標是節點入口，檢查節點與本機出口；如果目標是 DNS 伺服器，檢查解析鏈路；如果只在延遲測試網址出現，而其他連線正常，則應檢查測速位址。

固定排查順序與恢復標準

完整流程可以濃縮為八個步驟。請依序執行，並在每一步記錄結果：

1. 確認直連網路：關閉系統代理與 TUN，驗證基礎網路正常。
2. 確認核心執行：檢查設定載入、連接埠監聽與啟動記錄。
3. 只啟用系統代理：使用 127.0.0.1:7890 等實際 Mixed Port 進行測試。
4. 交叉測試節點：比較至少 3 個節點，區分單一節點與全域故障。
5. 檢查入口解析：查詢節點網域，核對 IPv4、IPv6 與 DNS 記錄。
6. 核對協定欄位：只針對單一節點檢查連接埠、TLS、SNI 與傳輸參數。
7. 更換網路重新測試：使用手機熱點區分本機、路由器與目前出口。
8. 最後恢復 TUN：基礎代理穩定後，再檢查虛擬網卡、路由與 DNS 接管。

恢復標準不只是節點延遲出現數字。至少應同時符合：用戶端核心穩定執行；網頁請求出現在連線面板；規則命中符合預期；連續開啟多個目標都沒有間歇性逾時；切換節點後，新連線使用新的策略。如果只有測速恢復、實際連線仍然失敗，排查就還沒有結束。