Clash 節點逾時排查

一、先分辨測速逾時與實際連線失敗

Clash 用戶端顯示「逾時」，通常表示探測未能在指定時間內完成，光憑這項結果還無法判定節點已失效。延遲測試通常會透過選定的節點連線至測試網址；從節點網域名稱解析、連線至遠端連接埠，到協定交握及存取測試網站，任何一個環節失敗，都可能出現類似結果。先記下錯誤訊息和影響範圍，再調整設定，避免把測試網址無法連線誤判為所有節點故障。

觀察三種情況，找出排查起點

• 只有一個節點連線失敗：保留目前設定，切換到同一策略群組中的其他節點，連線至相同網站。若恢復正常，優先檢查該節點的服務狀態與參數。
• 所有節點都連線失敗：先檢查本機網路、系統時間、訂閱效期和核心記錄，不要立刻批次修改節點連接埠。
• 測速失敗，但網頁能開啟：檢查測試網址是否可連線，以及網頁連線是否確實使用該節點。瀏覽器快取或直連規則也可能造成「可以連線」的假象。

在用戶端的「連線」或「記錄」頁面，查看新建立連線的目標網域、套用規則和實際出口。例如，若網頁連線套用 DIRECT，只能證明直連正常，無法證明選取的代理節點可用。不同用戶端的頁面名稱可能有所不同，以下操作請以實際介面和目前的核心設定為準。

二、關閉代理，確認本機網路與時間

先結束其他代理程式或 VPN，再暫時關閉目前用戶端的系統代理和 TUN。如果瀏覽器曾個別設定代理，也請改回使用系統設定。使用平常可直接連線的網站確認基本網路正常；連線至公共 Wi-Fi 時，先完成網路認證。若直連也無法使用，應先處理 Wi-Fi、路由器或電信業者的網路問題。

依序完成基本檢查

1. 在 Windows 11 的「設定」→「網路和網際網路」→「Proxy」中檢查手動代理設定。關閉用戶端後，不應保留指向失效本機連接埠的代理設定。
2. 在「設定」→「時間與語言」→「日期與時間」中開啟自動設定時間，並選擇「立即同步」。請確認實際日期與時間，不只是時區顯示。
3. macOS 可在「系統設定」→「一般」→「日期與時間」中檢查自動設定；網路代理位於「網路」→目前的網路服務→「詳細資訊」→「代理」。
4. 基本網路恢復後，只啟動一個代理用戶端。先透過系統代理測試，確認正常後再啟用 TUN，避免同時引入虛擬網卡和路由變數。

TLS 憑證有明確的有效期間，系統日期不正確可能導致交握直接失敗。另一方面，不同協定使用的校時機制不盡相同，因此「同步時間」是必要的基本檢查，但並非所有逾時問題的通用解法。

三、確認訂閱未過期，且目前設定已更新

訂閱連結能下載，不代表帳號仍有可用流量，也不代表所有節點都正常運作。請前往訂閱服務的帳戶頁面，確認到期日、剩餘流量、維護公告和用戶端使用限制。若帳戶已停用，應先處理帳戶狀態；反覆更換 DNS 無法恢復已停用的服務。

1. 在用戶端的「訂閱」或「設定檔」頁面找到目前使用的項目，執行更新，並確認更新時間和結果。
2. 確認更新後的設定仍為選取狀態，且已成功載入核心。若下載成功但解析失敗，實際執行的可能仍是舊設定。
3. 檢查策略群組實際選用的節點。自動選擇群組和故障轉移群組目前使用的出口，可能與上次手動選取的節點不同。
4. 若記錄顯示未知代理類型、缺少欄位，或引用了不存在的策略群組，應先處理設定相容性問題，而非將其歸類為網路逾時。

四、檢查節點網域名稱與遠端連接埠

確認訂閱正常後，再分辨「無法解析位址」和「位址已解析但無法連上連接埠」。查看節點的 server 和 port，不要把本機 HTTP 代理的監聽連接埠誤認為遠端節點連接埠。以下命令中的 example.com 和 443 僅用於示範命令格式，執行時請替換為目前節點的實際伺服器網域名稱和連接埠；範例不代表可用節點。

# Windows PowerShell：先查詢網域名稱，再測試 TCP 連接埠
Resolve-DnsName example.com
Test-NetConnection -ComputerName example.com -Port 443

# macOS：查詢網域名稱並測試 TCP 連線
nslookup example.com
nc -vz -G 5 example.com 443

若網域名稱查詢失敗，先確認節點網域名稱沒有拼錯或已失效，再檢查目前網路使用的 DNS 服務。若啟用 mihomo 內建 DNS，也應確認節點伺服器網域名稱使用哪條解析路徑。設定中的 proxy-server-nameserver 可指定代理節點網域名稱的解析伺服器，但須依實際版本和 DNS 設定判斷；不能只複製這個欄位，就認定解析流程已設定正確。

TcpTestSucceeded: True 只代表 TCP 連線測試成功，不代表認證、TLS 或代理協定交握也成功。Hysteria2、TUIC 等使用 UDP 的協定，也不能以 TCP 連接埠測試取代可用性驗證。一般的 ping 使用 ICMP；伺服器即使不回應 ICMP，仍可能正常提供代理服務。

使用手機熱點交叉測試

保持用戶端、訂閱和節點不變，只將電腦從目前的 Wi-Fi 切換至手機熱點，再建立一次新連線。若熱點正常、原網路持續逾時，問題可能與原網路路徑、UDP 限制、路由策略或出口過濾有關，但還不能直接判定是某個連接埠遭到封鎖。請對照同一時段的記錄和伺服器狀態，進一步確認原因。使用企業或校園網路時，請遵守其存取規定，不要擅自修改受管理的安全策略。

五、確認核心相容性與協定參數

Clash 是用戶端生態系和核心設定中常見的名稱，但不代表所有核心支援的協定都完全相同。Clash Meta 後續以 mihomo 的名稱持續發展；較舊的核心可能無法辨識新協定或新欄位。請先在「關於」、核心資訊或啟動記錄中確認用戶端和核心版本，再對照訂閱服務的要求。若只升級介面程式，卻未切換實際執行的核心，相容性問題可能依然存在。

參數應以服務提供者目前提供的設定為準，不要憑經驗將所有連接埠改成 443，也不要任意更換傳輸類型。伺服器名稱不一定等於節點連線網域名稱；直接將 server 改成 IP，也可能改變解析行為並影響憑證驗證。若出現憑證錯誤，應修正時間、名稱或伺服器憑證，不要預設略過憑證驗證。

六、節點可連線但應用程式失敗時，檢查流量接管

若內建測試通過，但瀏覽器或特定應用程式仍然逾時，應檢查應用程式的流量是否進入用戶端、套用哪條規則，以及是否被導向錯誤的策略群組。系統代理和 TUN 是兩種不同的流量接管方式，啟用其中一種並不代表所有應用程式都會使用預期的出口。

先確認本機監聽，再檢查規則

假設目前設定明確寫有 mixed-port: 7890，可使用以下命令，讓 HTTPS 要求明確經由本機 HTTP 代理送出。7890 是此處的範例值，並非所有用戶端的固定連接埠；請先在實際設定或設定檔中確認監聽連接埠。

# Windows PowerShell 使用 curl.exe，避免命令別名造成差異
curl.exe -I --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://example.com/

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

• 連線遭本機連接埠拒絕：檢查核心是否正在執行、監聽連接埠是否一致，以及該連接埠是否已被其他程式占用。Windows 可使用 netstat -ano | findstr :7890 查看監聽記錄和 PID。
• 要求已送至用戶端，但遠端交握失敗：回頭檢查節點位址、協定參數和遠端網路，不必再調整瀏覽器代理設定。
• 要求套用 REJECT：檢查規則順序和來源。規則依序比對，第一條符合的規則會決定處理方式；應修正規則，而非只更換節點。
• 只有啟用 TUN 時才失敗：檢查服務權限、虛擬網卡、DNS 接管，以及其他 VPN 的路由衝突。先恢復已確認可用的系統代理路徑，再逐項啟用 TUN 功能。

命令成功取得 HTTP 回應，只能證明該次要求已完成，仍須在記錄中確認實際出口。連線重用也可能沿用舊節點的連線，因此更換節點後應重新發送要求；必要時只關閉相關的舊連線，不必直接清除所有設定。

七、整理最小重現資訊後再回報

如果依照前述步驟仍無法找出原因，提供一份可供比對的記錄，會比只傳一張「逾時」截圖更有幫助。測試時一次只變更一項條件，並記下修改前後的結果；不要同時更換訂閱、DNS、核心和網路，否則無法判斷是哪項變更產生影響。

1. 記錄環境：作業系統、用戶端版本、實際核心版本，以及系統代理或 TUN 的啟用狀態。
2. 記錄影響範圍：單一節點或所有節點、只有測速失敗或實際 HTTPS 要求也失敗，以及是否只影響特定應用程式。
3. 記錄交叉測試結果：同一節點在原網路和手機熱點下的結果、測試時間與失敗階段；不要將範例數字當作實測證據。
4. 記錄錯誤訊息：暫時提高記錄層級，重現一次問題後擷取相關時段的記錄。遮蔽敏感資訊後再提交，排查完成後請恢復常用的記錄層級。