Clash 節點逾時無法連線：依序排查的七個環節

節點清單延遲顯示 timeout、連線時提示「無法連線到代理伺服器」、瀏覽器一直轉圈打不開網頁，這三種情況在使用者眼中都叫「節點逾時」，成因卻完全不同。多數人的第一反應是逐個切換節點，換了幾十個依然是 timeout——因為問題根本不在節點上。

以下七個環節依「從客戶端內部到外部鏈路」的順序排列，每一步都提供可直接執行的驗證動作與判斷標準。建議依序走一遍，不要跳步：前一步的結論會決定後一步是否需要執行。

先分清四種逾時，再動手排查

開始之前先做一次分類。同樣是 timeout，落在哪個環節是可以提前縮小的範圍。

現象	最可能原因	優先排查環節
所有節點延遲測試都 timeout	訂閱失效、DNS 解析失敗、本機連接埠衝突	環節一 → 二 → 三
只有個別節點 timeout	該節點已下線或暫時無法使用	環節一
延遲有數值，瀏覽器卻打不開網頁	系統代理未生效、規則命中 REJECT	環節四 → 五
單一應用程式逾時，其他應用程式正常	該應用程式不讀取系統代理、分流規則未涵蓋	環節四 → 五

判斷依據很簡單：延遲測試走的是內核自己的探測通道，瀏覽器走的是系統代理或 TUN 網卡。前者失敗，代表內核到節點這一段有問題；前者正常而後者失敗，代表問題出在流量接管或規則分流上。

環節一：訂閱更新與節點資訊是否過期

訂閱連結有有效期限與流量上限。到期之後客戶端通常不會跳出錯誤提示，只是節點清單裡的延遲全部變成 timeout。所以第一步永遠是手動更新一次訂閱，而不是切換節點。

具體操作順序

打開客戶端的「訂閱」或「設定」頁面，找到目前使用的設定，執行「更新」，不要只按「重新載入」——重新載入讀取的是本機舊檔案，節點資訊不會變。
更新完成後確認節點數量沒有變成 0，清單裡能看到具體的節點名稱與延遲欄。
打開產生的設定檔，檢查 proxies 段裡節點的 server 欄位是否還是有效的網域或 IP，服務商更換節點網域後舊設定會整段失效。

用一行指令驗證訂閱連結

curl -sI -o /dev/null -w '%{http_code}\n' "你的訂閱連結"

傳回 200 表示位址可存取；403、404、410 表示訂閱位址已失效或需要重新取得；傳回 200 但設定內容為空，通常是流量耗盡。

訂閱能取回不等於節點可用

部分服務商在流量耗盡後仍會傳回一個只含基本欄位的設定檔，客戶端能正常載入、節點也能顯示出來，但連線全部逾時。這種情況下必須回到服務商後台確認剩餘流量與到期時間。

環節二：DNS 解析與節點網域

節點網域解析失敗是 timeout 的常見原因，而且很容易被誤判成「節點掛了」。Clash 內核用自己的 dns 段解析節點網域，和系統 DNS 是兩套獨立設定，改系統 DNS 不一定會影響內核。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  proxy-server-nameserver:      # mihomo 專有：解析節點網域時使用
    - https://1.1.1.1/dns-query

proxy-server-nameserver 是 mihomo（Clash Meta）新增的欄位，作用是把「解析節點網域」這個動作單獨交給可信 DNS，避免中國大陸的 DNS 傳回被污染的 IP，導致 TCP 握手階段就逾時。原版 Clash 內核沒有這個欄位，只能用 nameserver-policy 為節點網域逐條指定伺服器。

驗證方法

執行 nslookup 節點網域 與 nslookup 節點網域 1.1.1.1，兩次結果差異過大代表存在 DNS 污染。
內核日誌裡出現 [DNS] resolve xxx failed，或反覆重試同一個網域，可以直接確認是解析問題。
使用 fake-ip 模式時，連線清單裡目標位址顯示為 198.18.x.x 屬於正常現象，不是故障。

環節三：連接埠佔用與本機監聽

內核預設監聽 7890（mixed-port，HTTP 與 SOCKS 混合）、7892（redir-port）、7893（tproxy-port），控制介面預設在 127.0.0.1:9090。任何一個連接埠被佔用，內核可能啟動失敗或只啟動一部分，而部分客戶端介面仍顯示「執行中」。

檢查連接埠佔用的指令

Windows：netstat -ano | findstr :7890，取得 PID 後到工作管理員確認是哪個處理程序。
macOS：lsof -i :7890
Linux：ss -lntp | grep 7890

兩種處理方式

結束佔用處理程序後重新啟動內核。常見的佔用者是上一次沒有完全結束的內核處理程序、其他代理軟體，以及會監聽本機連接埠的開發工具。
修改設定裡的 mixed-port（例如改成 7897），同時把系統代理、瀏覽器擴充功能、命令列工具的代理連接埠一起改掉。

只改設定不改系統代理會出現組合故障

內核實際監聽在 7897，系統代理仍指向 7890，表現就是「節點延遲測試正常、瀏覽器全部逾時」。這類現象看起來像節點問題，實際上是連接埠不一致。

環節四：系統代理與 TUN 是否真正接管流量

內核在執行，不等於流量被接管。系統代理和 TUN 是兩種不同的接管方式，排查前先確認目前用的是哪一種。

系統代理的檢查位置

Windows：「設定」→「網路和網際網路」→「代理」，確認「使用代理伺服器」已開啟，位址為 127.0.0.1，連接埠與設定裡的 mixed-port 一致。
macOS：「系統設定」→「網路」→ 目前的網路服務 →「詳細資訊」→「代理」，確認 HTTP 與 HTTPS 兩項都已勾選並指向同一個連接埠。
Linux：GNOME 在「設定」→「網路」→「網路代理」；終端機裡的命令列工具需要另外設定 http_proxy 環境變數。

TUN 模式的檢查位置

TUN 需要管理員或 root 權限，多數客戶端透過安裝系統服務來實現（Clash Verge Rev 的「服務模式」、Clash for Windows 的 Service Mode）。開啟後可以從路由表確認：

Linux / macOS：ip route 應該能看到 TUN 網卡與 198.18.0.0/16 的路由項目。
Windows：route print 中應出現 TUN 介面卡對應的路由。

用一行指令判斷整條鏈路是否暢通

curl -x http://127.0.0.1:7890 -o /dev/null -s -w '%{http_code} %{time_total}s\n' https://www.gstatic.com/generate_204

傳回 204 且耗時在數百毫秒內：內核、節點、規則這條鏈路正常，問題在系統代理設定或特定應用程式。
傳回 000 或長時間沒有回應：內核端就沒走通，回到環節一重新排查。

比較項目	系統代理	TUN 模式
接管範圍	會讀取系統代理設定的應用程式	全部 TCP / UDP 流量
權限要求	一般使用者即可	管理員 / root 或安裝系統服務
DNS 處理	多數情況仍走系統 DNS	由內核 `dns` 段統一處理
典型問題	應用程式不讀取系統代理、連接埠不一致	服務未安裝、路由未寫入

環節五：規則命中與分流結果

規則由上而下短路比對，第一條命中的規則決定這條連線的走向。規則寫錯或規則集沒更新，同樣會表現為逾時。

rules:
  - DOMAIN-SUFFIX,example.com,REJECT
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

三種常見的寫錯方式

MATCH 寫在中間：它會匹配所有流量，寫在它後面的規則永遠不會執行。
IP-CIDR 漏寫 no-resolve：每條連線都要先做一次 DNS 解析，解析慢或失敗時整體表現為逾時。
目標網域被 REJECT 或落到 DIRECT，而本機直連本身被目前的網路攔截。

如何確認命中了哪條規則

打開 Dashboard 的「連線」頁面，可以看到每條連線對應的「規則」與「代理鏈」兩欄；內核日誌裡也會輸出類似 [TCP] 1.2.3.4:443 → match GEOIP,CN => DIRECT 的記錄。如果某條連線命中的是 REJECT，瀏覽器端的表現就是請求一直沒有回應，而不是立刻回報錯誤。

環節六：內核日誌與延遲測試方式

日誌等級預設是 info，排查逾時時先調成 debug，再重現一次問題，看日誌停在哪一步。

log-level: debug
external-controller: 127.0.0.1:9090
unified-delay: true
tcp-concurrent: true

unified-delay: true：延遲依完整握手耗時計算，數值更接近實際體驗，也更容易看出哪一類節點在逾時。
tcp-concurrent: true：同一網域並行探測多個 IP，避免因為個別 IP 無法到達而整體逾時。
external-controller：Dashboard 的連入位址，設定後可以在瀏覽器打開本機面板查看即時日誌與連線清單。

日誌裡四類關鍵行

日誌片段	含義	回到哪個環節
`dial tcp 1.2.3.4:443: i/o timeout`	內核到節點的握手失敗	環節一至三
`[DNS] resolve xxx failed`	節點網域解析失敗	環節二
`match GEOIP,CN => DIRECT` 之後沒有回應	走了直連，但直連被網路攔截	環節五
`listen tcp 127.0.0.1:7890: bind: address already in use`	連接埠被其他處理程序佔用	環節三

統一延遲測試位址

把測試位址固定為 https://www.gstatic.com/generate_204。不同客戶端預設的測試位址不一樣，統一之後各平台的延遲數值才有可比性，也方便跨裝置對照。

環節七：網路環境與鏈路品質

前面六個環節都在本機，最後一個環節在鏈路。判斷方法很直接：把同一份設定換到手機熱點下測試一次。

公共 WiFi、校園網路、公司網路常做出站連接埠封鎖或 SNI 干擾。同一份設定在熱點下正常、在目前網路下全部逾時，基本上可以確認是網路端限制。
系統時間偏差：VMess 等協定依賴時間戳記，偏差超過 90 秒會直接握手失敗，現象同樣是 timeout。Linux / macOS 用 date -u 對比標準時間，Windows 用 w32tm /resync 重新同步。
IPv6 優先：節點網域同時存在 A 與 AAAA 記錄，而本機 IPv6 無法連線時，部分客戶端會先嘗試 IPv6 再回退，表現為首個封包逾時。可以在設定裡加上 ipv6: false 驗證。
MTU 與路由器：部分 PPPoE 環境需要把 TUN 的 MTU 從 9000 下調到 1500 或更低，否則大封包會被丟棄，表現為「網頁打得開、影片與下載一直卡住」。

七個環節速查表

順序	環節	確認方式	判斷標準
1	訂閱更新	`curl -sI "訂閱連結"`	傳回 200 且節點數不為 0
2	DNS 解析	`nslookup 節點網域 1.1.1.1`	與預設解析結果一致
3	連接埠佔用	`netstat -ano \| findstr :7890`	沒有其他處理程序佔用該連接埠
4	系統代理 / TUN	`curl -x http://127.0.0.1:7890 …`	傳回 204
5	規則命中	Dashboard「連線」頁	命中的規則與代理符合預期
6	內核日誌	`log-level: debug`	沒有 dial timeout 與 DNS 失敗記錄
7	網路環境	換手機熱點重新測試	熱點下恢復正常

排查過程中不要做的三件事

不要一邊改設定一邊測試。每次只改一項，儲存後重新啟動內核再重現，否則無法判斷是哪一項起了作用。
不要用切換節點代替定位。所有節點都逾時，代表問題在客戶端或本機鏈路，換節點不會改變結果。
不要直接編輯訂閱產生的設定檔。下次更新訂閱會覆蓋這些改動，自訂內容應寫進客戶端的擴充設定或 Merge 覆蓋層。

依這七個環節走一遍，大部分逾時問題都能歸到一個具體位置：訂閱、DNS、連接埠、接管方式、規則、日誌或網路環境。先定位再修改，比逐個試節點快得多。