節點超時或無法連接是使用 Clash 及其衍生核心（Clash Meta、mihomo）過程中最常見的問題類型，但表現相同的故障背後往往對應完全不同的原因：可能是訂閱本身已失效，可能是節點伺服端出現波動，也可能是本機網路設定衝突。逐一猜測容易浪費時間，按固定順序從外部到內部依次排除，才能快速定位問題所在。本文給出的排查順序遵循一個原則：先確認資料來源是否正常，再確認軟體是否正常運作，最後確認系統環境是否放行了代理流量。
排查前的基本判斷
在進入具體步驟之前，先明確故障範圍。開啟用戶端，觀察連接失敗的提示訊息和影響範圍，能幫助縮小排查方向：
- 全部節點都無法連接：更可能是訂閱、系統代理或防火牆這類全域性問題。
- 只有個別節點無法連接，其餘正常：更可能是節點伺服端本身的問題，或者延遲測試結果本就異常。
- 之前能用，突然全部失效：優先檢查訂閱是否過期或流量是否用盡，其次檢查本機是否有新安裝的軟體佔用了埠。
- 換了新裝置或新系統後無法連接：優先檢查系統代理和防火牆設定，這是新環境最容易缺失的設定。
做完這個初步判斷後，再按下面五個步驟逐層排查，通常能在第二到第四步之間就能定位到具體原因。
第一步：檢查訂閱是否有效
訂閱失效是節點全部超時最常見的原因，但很容易被忽略，因為用戶端介面上節點清單可能仍然顯示著，只是背後對應的服務已經停止回應。檢查訂閱有效性可以從以下幾個角度入手：
- 查看訂閱到期時間和剩餘流量：多數訂閱服務商會在連結或面板中提供到期日期與流量餘量資訊，用戶端的訂閱管理頁通常會展示這兩項資料，確認是否已經到期或流量已用盡。
- 手動更新訂閱：在用戶端的訂閱清單中執行一次手動更新（通常是一個重新整理圖示或「更新訂閱」按鈕），如果更新失敗並提示網路錯誤或連結無效，說明訂閱位址本身出現了問題。
- 檢查更新時間戳是否異常：如果自動更新長期停留在很久之前的時間，說明定時更新可能因為網路問題一直失敗，節點清單實際上是過時的快取資料。
- 確認訂閱連結未被截斷：手動匯入訂閱連結時，複製貼上過程中連結末尾的參數容易被遺漏，導致連結指向的內容不完整。重新完整複製一次連結是排除這種可能的最簡單方法。
注意：如果訂閱更新成功但節點數量和之前完全一致，也不代表訂閱一定有效，服務商停止維護後節點清單可能長期不再變化，此時需要結合第二步的延遲測試進一步確認。
第二步：測試節點延遲
訂閱確認有效後，下一步是判斷具體是哪些節點出現問題。Clash 用戶端通常在節點清單旁提供延遲測試功能，點擊後會對每個節點發起一次網路探測並顯示往返時間（毫秒數）。觀察測試結果時注意區分以下幾種情況：
- 顯示具體毫秒數（如 80ms）：說明該節點目前可以連通，超時問題不在這個節點上，應該繼續排查系統層面的原因。
- 顯示超時或無回應：說明節點伺服端目前不可用，可能是伺服器維護、線路波動或該節點被大規模限制，嘗試切換到同一分組下的其他節點。
- 所有節點均顯示超時：延遲測試本身依賴網路連接完成，如果連測試請求都無法發出，問題往往出在本機網路環境，而不是節點伺服端，應該轉向後面的埠、系統代理和防火牆排查。
延遲測試的 URL 通常可以在設定中自訂，如果預設測試位址本身在目前網路環境下不可達（例如預設使用了某個特定站點），會導致測試結果整體異常，可以嘗試更換一個測試位址後重新測試，排除測試鏈路本身的問題。
如果某個節點長期高延遲或頻繁超時，而其他同一訂閱下的節點表現正常，通常是該節點線路品質問題，直接切換節點是最直接的解決方式，不需要在這一個節點上反覆排查。
第三步：檢查埠佔用
如果延遲測試也無法完成，接下來檢查 Clash 使用的本機埠是否被其他程式佔用。Clash 核心啟動時會監聽一組本機埠用於接收代理請求，常見的包括 HTTP 代理埠、SOCKS5 代理埠和混合埠（mixed-port），如果這些埠已經被其他程式佔用，核心可能無法正常啟動監聽，導致所有流量都無法轉送。
排查埠佔用可以按以下方式操作：
- 開啟用戶端的日誌面板，查看核心啟動時是否有類似「埠已被佔用」「bind: address already in use」之類的錯誤訊息。
- 在系統命令列中查詢埠佔用情況。Windows 下可以使用命令列工具查看指定埠對應的程序：
netstat -ano | findstr 7890macOS 與 Linux 下可以使用：
lsof -i :7890- 如果發現有其他程式佔用了 Clash 需要使用的埠，可以關閉該程式，或在用戶端設定中修改 Clash 使用的埠號，避開衝突。
- 修改埠號後需要重啟核心使設定生效，並檢查系統代理設定中記錄的埠號是否也同步更新，兩者不一致會導致系統代理指向一個已經無人監聽的埠。
說明：同時執行兩個 Clash 用戶端，或者上一次程序未完全退出就重新啟動，是埠衝突最常見的誘因，重啟系統或徹底結束相關程序通常可以解決。
第四步：確認系統代理狀態
埠正常監聽之後，如果瀏覽器等應用程式依然無法透過代理存取網路，需要確認系統代理是否真正生效。系統代理決定了哪些應用程式會把流量交給 Clash 處理，如果這一層設定出錯，即便節點和埠都正常，流量也不會經過 Clash。
- 檢查用戶端內的系統代理開關：確認用戶端設定中「設為系統代理」或類似選項已經開啟，部分用戶端在重啟後不會自動恢復該開關狀態，需要手動重新開啟。
- 檢查作業系統的代理設定：在系統網路設定中查看代理位址和埠是否與用戶端目前使用的埠一致，尤其是在手動修改過埠號之後，系統層的代理設定有時不會自動同步。
- 區分系統代理與 TUN 模式：系統代理只對遵循系統代理設定的應用程式生效，命令列工具、部分遊戲或背景服務可能不讀取系統代理設定，這類場景下即便系統代理已經開啟，這些應用程式依然會顯示無法連接，需要改用 TUN 模式接管全部流量，而不是繼續在系統代理層面排查。
- 瀏覽器或應用程式自身的代理設定：某些瀏覽器有獨立於系統代理的網路設定項，如果瀏覽器設定了「不使用系統代理」，即便系統代理正常運作，該瀏覽器依然無法透過 Clash 存取網路。
確認這一層沒有問題的一個簡單方法是開啟用戶端的連接日誌或流量面板，觀察是否有即時的連接記錄產生。如果發起瀏覽請求後面板上完全沒有新連接出現，基本可以確定流量沒有進入 Clash，問題出在系統代理設定這一層。
第五步：排查防火牆攔截
如果系統代理設定確認無誤，流量已經進入 Clash 但仍然回報超時，最後需要檢查是否有防火牆或安全軟體攔截了 Clash 的網路存取。這一步在新安裝的系統、企業管理的電腦或者剛更新過安全軟體版本後尤其常見。
- 檢查系統內建防火牆：確認 Clash 主程式及其核心程序被允許透過防火牆的入站與出站規則，如果是首次執行被攔截，作業系統通常會彈出授權提示，需要選擇允許而不是拒絕。
- 檢查第三方安全軟體：部分安全軟體會將代理類工具識別為風險程式並靜默攔截其網路請求，而不會彈出明顯提示，此時需要在安全軟體的日誌或白名單設定中手動新增 Clash 的可執行檔。
- 檢查路由器或閘道層面的限制：一些家用路由器或公司網路在閘道層做了埠限制或協定識別，如果本機所有排查步驟都正常但依然無法連接，可以嘗試更換網路環境（如手機熱點）進行對比測試，縮小問題範圍。
- 確認節點使用的傳輸協定未被針對性限制：部分網路環境會對特定協定特徵進行識別和干擾，如果同一訂閱下某些協定類型的節點普遍超時、另一些協定類型的節點表現正常，說明網路環境對特定協定做了限制，應優先選擇表現正常的協定類型的節點。
注意：關閉防火牆進行測試僅用於臨時排查問題原因，確認攔截來源後應恢復防火牆並新增針對性的允許規則，而不是長期關閉系統防護。
仍無法解決時的補充檢查
如果按以上五步排查後問題依然存在，可以補充以下幾項檢查，涵蓋一些相對少見但確實會導致連接失敗的情況：
- 設定檔中的規則衝突：如果自訂了規則集，檢查是否存在規則將本應代理的流量錯誤地劃分到了直連分組，或者代理群組的策略選擇器設定有誤，導致實際選中的節點和介面顯示不一致。
- DNS 解析異常：即便代理連接正常，如果 DNS 解析出現問題，瀏覽器也會回報無法存取，可以在設定中檢查 DNS 設定項，或切換為 fake-ip 模式排查是否為 DNS 解析導致的連接失敗假象。
- 核心版本與設定格式不匹配：更新用戶端或核心版本後，舊的設定檔欄位可能已經變更或廢棄，查看日誌中是否有設定解析相關的警告或錯誤。
- 系統時間不準確：部分節點的加密協定對系統時間偏差比較敏感，系統時間與實際時間相差較大時可能導致交握失敗，表現為連接超時，檢查並校準系統時間可以排除這一類問題。
把這五個步驟和補充檢查按順序走一遍，絕大多數節點超時問題都能在其中一步找到明確原因。養成先看日誌、再逐層排查的習慣，比反覆重啟軟體或更換節點更能穩定地解決問題。