Clash 節點全部顯示 timeout？從本機網路到遠端伺服器的疑難排解順序

1. 先分辨延遲測試失敗與實際代理連線失敗

timeout 表示某項操作未能在限定時間內完成，並不代表伺服器一定已停止運作。用戶端的延遲測試通常會透過節點連線至指定的 HTTP 或 HTTPS 網址；從解析網域名稱、連線至伺服器、完成協定交握，到存取測試網站，任何一步卡住都可能造成逾時。

先固定一個節點、一個測試網址和一個應用程式。暫停批次測速，避免同時發出數十條連線。記下用戶端名稱、核心名稱與版本、目前使用的網路、測試時間，以及記錄檔中的第一筆錯誤。接下來每一輪只變更一個條件。

2. 本機網路：先排除斷網、驗證問題與殘留代理設定

恢復可驗證的直連環境

1. 先記下原本的設定。關閉用戶端的系統代理與 TUN 模式，再退出其他 VPN、網路加速器或代理工具。
2. 在 Windows 11 開啟「設定」→「網路和網際網路」→「Proxy」，檢查是否留有手動代理或自動設定指令碼。若裝置由組織管理，請先聯絡管理員，勿擅自移除管理政策。
3. 在 macOS 開啟「系統設定」→「網路」→目前的網路連線→「詳細資訊」→「代理伺服器」，確認 HTTP、HTTPS 與 SOCKS 代理是否仍指向已關閉的本機程式。
4. 連上飯店、校園或公共 Wi-Fi 時，請先完成網路驗證。若瀏覽器出現登入頁面，先完成登入，不要急著修改節點參數。

只退出用戶端不一定會清除系統代理設定。如果系統仍指向 127.0.0.1:7890，但該連接埠已沒有程序監聽，瀏覽器就會連線失敗。這是本機入口問題，流量尚未抵達遠端節點。

使用明確略過代理的請求進行測試

在 Windows PowerShell 中使用 curl.exe，避免舊版 PowerShell 因同名命令別名而產生差異。以下請求會略過明確指定的代理，連線逾時設為 5 秒，總時限設為 15 秒；這些是疑難排解用的參數，並非實測結果。

curl.exe --noproxy "*" --connect-timeout 5 --max-time 15 -I https://www.example.com/

macOS 與 Linux 使用相同參數，只要將命令名稱改為 curl。範例網域僅用來示範請求方式，可換成目前網路中已知可直連的網站。若 TUN、旁路由或上游透明代理仍在運作，--noproxy 無法略過這些網路層級的流量接管。

直連仍然失敗時，先檢查網路介面卡的 IP 位址、預設閘道與路由器的網際網路連線狀態，再用手機熱點讓同一台電腦重測。若熱點正常、原網路失敗，問題可能出在原網路的 DNS、路由或存取政策；但這仍不足以單獨證明某個連接埠遭到封鎖。

3. 系統時間與 DNS：先確保網域解析與憑證正常

校正系統時鐘

TLS 憑證驗證會依據目前時間進行，部分代理驗證也有時間要求。在 Windows 11 開啟「設定」→「時間與語言」→「日期與時間」，啟用自動設定時間並執行同步。在 macOS 開啟「系統設定」→「一般」→「日期與時間」，檢查是否已自動設定日期與時間。

確認日期、年份和實際時間，不要只看介面上顯示的時區。若記錄檔出現 certificate has expired 或 certificate is not yet valid，也要檢查本機時鐘與遠端憑證；不要直接啟用略過憑證驗證。

分別檢查節點網域與測速網域

• 節點網域解析失敗：核心無法取得伺服器位址，代理連線無法開始。
• 測速網域解析失敗：伺服器可能可以連線，但指定的測試請求無法完成。
• 核心與系統的解析結果不同：系統查詢成功，不代表核心設定的 DNS 上游也正常。

先從記錄檔找出解析失敗的網域。Windows 可執行 Resolve-DnsName www.example.com，macOS 或 Linux 可執行 nslookup www.example.com，並將範例網域換成記錄檔中的目標。系統查詢結果只能作為對照，也要查看核心是否回報 DNS resolve failed、上游連線逾時或解析循環。

4. 測速網址：確認請求目標，不只看數字

檢查用戶端目前使用的測試 URL。它可能來自介面設定，也可能來自設定檔中的 url-test 策略群組或 proxy-providers 健康檢查。這些位置不一定共用同一個網址；即使修改了介面選項，背景健康檢查仍可能連到舊網址。

選擇回應簡短、網址穩定且目前線路可存取的 HTTPS 目標。回傳 204 的網址常用於連線測試，但不要把所有「未取得 204」的情況都當成節點失效：重新導向、驗證頁面、網站流量限制，以及用戶端判斷狀態碼的方式都可能影響結果。

使用相同目標發出兩組請求

以下透過本機 HTTP 代理連接埠存取範例網址。7890 僅為範例，請務必換成用戶端實際使用的 HTTP 或 mixed 監聽連接埠。先確認目前規則會將此請求交給待測節點，否則請求成功也可能只是走了 DIRECT。

curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 -I https://www.example.com/

1. 對同一個目標分別發出直連與代理請求，並保存錯誤訊息。
2. 在用戶端的連線記錄中確認目標網域、套用的規則與最終出站節點。
3. 若只有測試目標失敗，請保持節點不變，改用另一個已知可用的目標測試。
4. 若 5 秒測試失敗，但 15 秒請求能完成，請記下這是回應較慢的線索，並繼續檢查交握與封包遺失；不要只是不斷調高逾時值。

curl -I 使用 HEAD 請求，與部分用戶端使用的 GET 探測方式不同。若目標不支援 HEAD，可移除 -I，改用 -o NUL（Windows）或 -o /dev/null（macOS、Linux）捨棄回應內容。比較時應使用相同的請求方法。

5. 本機連接埠、規則與 TUN：確認流量確實經過待測節點

先確認明確指定的代理入口可用

在 Windows 可使用以下命令檢查範例連接埠是否正在監聽。若沒有輸出，請回到用戶端檢查核心是否已啟動、設定是否載入成功，以及連接埠是否被其他程式占用。

Get-NetTCPConnection -State Listen -LocalPort 7890

macOS 可使用 lsof -nP -iTCP:7890 -sTCP:LISTEN，Linux 可使用 ss -lntp 查看監聽狀態。確認連接埠存在還不夠，也要確認所屬程序確實是目前用戶端的核心。不要將 HTTP 代理請求傳送至控制介面連接埠；控制介面不是代理流量的入口。

透過連線記錄確認代理策略

• 規則模式：檢查目標套用的規則與策略群組，確認最終出站並非 DIRECT、REJECT 或其他節點。
• 自動選擇群組：排查期間固定使用一個指定節點，避免測試途中自動切換，導致結果混雜。
• 鏈式代理：任一跳失敗都可能讓最終請求逾時，請先簡化為單跳連線再進行比較。

若明確指定的 HTTP 代理正常，只有開啟 TUN 後才失敗，請優先檢查路由、DNS 接管、權限及其他 VPN 的衝突。TUN 會改變流量進入核心的方式，無法修正密碼錯誤或遠端連接埠無法連線的問題。先保存記錄檔與設定副本，再逐項檢查，不要同時啟用多個會接管預設路由的工具。

若只有遊戲、語音或 QUIC 請求失敗，請另外檢查 UDP 支援。瀏覽器透過 TCP 存取成功，不代表節點協定、伺服器與本機網路都支援 UDP。暫時停用應用程式的 QUIC 後恢復正常，只能作為 UDP 路徑異常的線索。

6. 協定參數與遠端伺服器：逐層確認連線與交握狀況

先確認目前的核心是否支援節點協定

Clash 設定格式相似，不代表所有核心都支援相同的協定與欄位。使用 mihomo 設定時，應記下實際的核心名稱與版本，而不只是用戶端介面版本。若記錄檔出現不支援的代理類型、未知欄位或設定解析失敗，請先處理相容性問題，再進行網路測速。

從可信任的原始訂閱重新取得設定，並確認帳戶流量、到期狀態與節點清單是否有變動。逐一檢查 server、port、協定類型與驗證欄位。使用 TLS 或 WebSocket 時，也要核對 servername、路徑與 Host；使用 REALITY 時，還要確認服務供應商提供的公鑰、short ID 等參數。

不要根據網域名稱的外觀猜測這些參數。直接將節點網域改成 IP，可能會改變 TLS SNI、憑證驗證或伺服器的流量分流結果；即使 TCP 能連線，也不代表完整協定能順利建立。

將連接埠檢測視為局部證據

在 Windows 可使用 Test-NetConnection 檢查伺服器的 TCP 連接埠。將以下變數改為設定檔中的實際伺服器位址與連接埠，再執行檢測；範例中的 443 並非所有節點都通用。

$server = Read-Host "輸入節點 server 位址"
$port = [int](Read-Host "輸入節點 port，例如 443")
Test-NetConnection -ComputerName $server -Port $port

• TCP 連線成功：僅能證明 TCP 連線可建立，無法證明驗證、TLS、WebSocket 或代理轉發正常。
• TCP 連線失敗：可能與路由、存取政策、服務未監聽或位址錯誤有關，不能只憑一次結果判定責任歸屬。
• UDP 協定：Hysteria2、TUIC 等以 UDP 為基礎的連線，無法透過 TCP 連接埠檢測判定是否可用。
• ping 失敗：目標可能不回應 ICMP，不能據此認定代理連接埠無法使用。

同一節點在兩個不同的網路上都連線失敗，且已確認參數與帳戶狀態後，再聯絡服務供應商確認監聽連接埠、防火牆、憑證與伺服器運作狀況。若多個節點共用相同的入口網域或中繼鏈路，即使全部失敗，也可能是共同依賴項出了問題，而非每台出口伺服器同時故障。

7. 透過記錄檔完成排查：保留第一個錯誤，不只截取全紅畫面

暫時將記錄檔層級提高至 debug，清除舊記錄後只重現一次錯誤。查看請求開始到報錯之間的完整脈絡：目標網域、選取的節點、解析結果與交握階段。排查完成後請恢復原本的記錄檔層級，避免持續產生大量記錄。

完成一輪疑難排解的標準

1. 關閉代理後，已確認本機直連是否正常。
2. 已固定一個節點，分別測試實際存取與延遲探測。
3. 已確認系統時間、節點網域解析與本機監聽連接埠。
4. 已透過連線記錄確認規則與最終出站節點。
5. 已在另一個網路完成對照測試，或記錄目前無法比對的原因。
6. 已找出失敗階段，並整理好移除敏感資訊的記錄檔以供進一步檢查。

依照這個順序排查，可將「所有節點都 timeout」的問題範圍縮小至本機入口、DNS、測試目標、協定交握或遠端鏈路其中一層。若需確認設定術語，請參閱概念速查；若要繼續檢查系統代理與規則設定，請參閱疑難手冊。