Clash 節點逾時、連線失敗怎麼辦？從訂閱到出口逐步排查

先釐清：測速逾時、代理連線失敗，還是網站無法開啟

Clash 顯示節點逾時，不代表節點伺服器已經停止運作。延遲測試通常會透過節點向測試網址發出請求，結果同時取決於本機網路、節點連線、代理交握、出口解析與測試網站。任何一個環節出錯，都可能顯示逾時。應先確認問題出在哪一層，再修改對應設定，不要接連更換 DNS、連接埠與核心。

Clash 泛指相關核心與設定生態；用戶端則負責介面、訂閱管理及系統代理等操作。Clash Meta 後續改名為 mihomo。不同用戶端的選單位置、設定合併方式與核心功能不盡相同。排查時應以目前執行中的核心日誌與生效設定為準，不能只看訂閱檔案的內容。

第一層：確認訂閱更新成功，且設定已啟用

先確認用戶端確實載入新設定，再判斷節點是否可用。訂閱更新成功、設定解析成功，以及切換至該設定，是三個不同的步驟。遠端訂閱更新失敗時，用戶端可能繼續使用本機快取，因此清單中有節點，不代表這次更新成功。

1. 檢查更新時間與結果。在目前用戶端的訂閱或設定清單中找到正在使用的項目，執行一次更新，並記下 HTTP 狀態碼或錯誤訊息。不同用戶端的選單名稱可能不同，請勿把自動更新間隔當成最近一次成功更新的時間。
2. 確認回傳內容是設定檔。HTTP 200 只代表請求成功；登入頁面或流量用盡提示頁也可能回傳 200。若日誌顯示 YAML 解析失敗，應先檢查內容類型，不要隨意刪除縮排試運氣。
3. 確認已選取並重新載入設定。切換後檢查策略群組是否出現預期節點，並查看日誌是否有未知欄位、缺少代理群組、名稱重複或不支援的代理類型。
4. 區分主設定與節點提供者。使用 proxy-providers 的設定還有獨立的節點擷取流程；主設定更新完成，不代表提供者也已成功擷取。

訂閱下載本身也需要代理，該怎麼辦？

如果舊節點已失效，而訂閱更新又設定為透過舊節點進行，就可能形成更新依賴。先確認訂閱網域在目前網路能否直接連線；若用戶端提供訂閱更新代理選項，可暫時改用已確認可用的連線路徑。主設定中的 proxy-providers 擷取，與用戶端本身下載訂閱可能採用不同機制，請分別查看日誌。

請勿將含有權杖的訂閱連結貼到公開檢測網站。需要尋求協助時，只提供狀態碼、已遮蔽敏感資訊的錯誤訊息及更新時間；完整訂閱網址通常等同於存取憑證。

第二層：檢查本機網路與切換網路的差異

如果所有節點突然同時失敗，先檢查它們共用的本機網路連線。暫停系統代理與 TUN，再開啟目前網路原本就能直接連線的網頁；若基本網路也無法使用，應先處理 Wi-Fi、網路線、認證入口網站或路由器問題。測試結束後，請恢復需要的代理設定。

• 檢查網路認證：飯店、校園或公共 Wi-Fi 可能需要先透過瀏覽器登入。開啟代理後，認證頁面可能無法正常跳轉。
• 檢查系統時間：日期、時區或時鐘明顯錯誤，可能導致憑證有效期限驗證失敗。開啟系統自動校時後，再測試 TLS 類型的節點。
• 暫時改用手機熱點：維持同一台裝置、同一份設定與同一個節點，只更換網路。如果熱點可用、原網路卻失敗，應優先檢查原網路的 DNS、對外連線政策或 IPv6 路徑。
• 排除多重接管：暫時關閉其他 VPN、代理用戶端或流量過濾工具，避免多個工具同時修改路由。排查時不要長時間關閉系統防火牆。

熱點測試只能縮小問題範圍，不能單憑此結果證明電信業者封鎖。行動網路與固定寬頻可能使用不同的解析結果、IPv4／IPv6 出口與路由。記錄兩次測試的差異，比反覆點選延遲測試更有幫助。

第三層：檢查監聽連接埠，以及應用程式是否進入核心

先確認本機代理入口可用，再檢查遠端節點。連接埠被占用、核心啟動失敗，或系統代理指向舊連接埠，都會讓應用程式顯示「代理無法連線」。以下是本機入口欄位範例，只用來說明監聽關係，並非包含節點資訊的完整設定。

# 合併至目前設定的頂層；不要重複宣告同名鍵。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

mixed-port 可同時接受 HTTP 和 SOCKS 代理連線；7890 是此範例使用的連接埠。external-controller 是控制介面，不是瀏覽器代理入口，請勿將常見的控制連接埠 9090 填入應用程式的 HTTP 代理設定。

確認哪個程序占用了 7890

Windows 可在 PowerShell 中查看監聽記錄，再依回傳的程序識別碼確認是哪個程式：

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

macOS 可使用系統內建的 lsof；Linux 可使用 ss。查看程序詳細資訊時，可能需要相應權限：

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -lntp 'sport = :7890'

如果占用者是另一個代理執行個體，應先確認目前由哪個執行個體提供服務，再停止重複程序或修改連接埠。修改連接埠後，也要同步更新系統代理與應用程式設定。日誌出現 address already in use 時，應優先處理監聽衝突，不必先更換節點。

略過系統代理設定，直接測試本機入口

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

在 Windows PowerShell 中，建議將上方的 curl 改寫為 curl.exe，避免部分環境中同名別名造成影響。--noproxy "" 用來清除本次請求的代理略過清單；5 秒是連線等待上限，15 秒是請求總時間上限。

如果出現無法連線至 127.0.0.1:7890 的訊息，應優先檢查核心與監聽連接埠。如果收到 200、301 等 HTTP 回應，表示這次請求已收到回應，但仍應在連線日誌中確認最終策略：規則可能讓流量走 DIRECT，不能只憑回應碼就認定代理節點可用。

第四層：區分節點網域解析與目標網域解析

排查 DNS 時，先確認「是哪個網域解析失敗」。若節點的 server 填寫的是網域，核心連線至節點前就必須先解析該網域；存取目標網站時，還可能需要進行另一輪解析。節點位址解析失敗與網站網域解析失敗，不能一概而論。

• 節點網域解析失敗：日誌可能包含 lookup、no such host 或解析逾時等字樣。先用系統工具查詢節點網域，記下是否回傳 A、AAAA 記錄，再與核心的實際日誌比對。
• 目標網域解析失敗：節點交握可能已成功，但後續請求仍會因解析失敗而中斷。請確認問題發生在本機、核心 DNS，還是伺服器出口。
• 只有 IPv6 路徑異常：留意日誌中實際連線使用的是 IPv4 還是 IPv6 位址。系統查詢成功不代表該位址類型的網路路徑暢通，也不代表核心使用了相同的解析器。

以下說明 mihomo 中為節點網域指定獨立解析器的欄位關係，前提是目前使用的核心支援相關欄位。這段內容不是通用的 DNS 推薦設定；請合併至既有的 dns 對應表，不要在同一層再新增第二個 dns。

dns:
  enable: true
  nameserver:
    - 1.1.1.1
  proxy-server-nameserver:
    - 1.1.1.1

proxy-server-nameserver 用來解析代理節點網域。範例中的解析器位址不保證目前網路可以連線，請選用已確認可達的解析器。若已有 DoH、Fake-IP 或依網域指定解析器的設定，應保留原有結構，只修改與故障直接相關的部分。

第五層：核對協定參數與核心支援範圍

相同的位址和連接埠能建立 TCP 連線，不代表代理協定交握一定能完成。如果本機入口正常、節點位址也能解析，但只有某類節點失敗，就應檢查協定支援與伺服器參數。舊版 Clash 核心與 mihomo 支援的協定範圍不同；用戶端介面顯示節點名稱，也不代表目前執行的核心能使用該協定。

優先重新取得服務提供者針對目前核心提供的設定，不要只憑節點名稱推斷協定，也不要手動刪除看不懂的參數。若使用訂閱轉換，請確認轉換目標與實際核心相符；轉換不相容可能會遺失傳輸或驗證欄位。

TCP 可達性測試只能解答部分問題

Windows 的 Test-NetConnection 可檢查指定位址與連接埠能否建立 TCP 連線。將 -ComputerName 後的值換成設定中的實際節點網域，並將 -Port 後的值換成實際連接埠即可。請勿用這類 TCP 測試結果證明 Hysteria2 等採用 UDP 的協定可正常運作。

即使 TCP 測試通過，也只表示該連接埠當時能建立連線；密碼、TLS 與代理傳輸仍可能失敗。反過來說，節點沒有回應 ICMP 也很常見，單憑 ping 封包遺失不能證明代理服務無法使用。

第六層：判斷伺服器故障、出口限制與測速目標異常

只有在前面各層大致確認無誤後，才應著重檢查伺服器與出口。此時應交叉測試「同一節點連不同目標」與「同一目標走不同節點」，不要只反覆測試同一個延遲網址。

1. 用同一個節點測試兩個目標。如果一般網頁可以存取，只有延遲測試失敗，請檢查用戶端設定的測試 URL、回應要求與逾時門檻。測速目標故障不代表節點失效。
2. 以另一個節點測試同一個目標。如果只有一個出口失敗，可能是該出口至目標的路由、目標網站的風控機制，或伺服器端的解析異常。
3. 查看帳戶狀態。確認有效期限、剩餘流量、線上裝置數量限制，以及服務提供者的維護公告。訂閱仍可下載，不代表代理帳戶仍有可用流量。
4. 向服務提供者提交已遮蔽敏感資訊的證據。提供故障時間與時區、節點識別資訊、核心版本、錯誤類型、換網測試結果及目標網域；不要提交密碼、UUID、完整訂閱連結或完整設定。

connection refused 通常表示連線收到明確拒絕，常見原因是連接埠沒有服務監聽，或中間設備主動拒絕；i/o timeout 表示某次網路操作未能在期限內完成，需搭配日誌判斷發生在連線、交握還是讀寫階段；EOF 表示資料流已結束，單憑這個錯誤無法判斷是驗證失敗或遠端主動中斷。

如果節點可以開啟一般網站，但某個平台回傳 403、要求輸入驗證碼或限制地區，應從目標網站與出口的關係著手處理。單純延長連線逾時不會解決應用層限制，也不應將問題歸類為本機連接埠故障。

恢復確認：確保實際流量採用預期策略

排查完成的標準是實際請求成功，且連線路徑符合預期，而不是延遲數字變成綠色。在規則模式下，用戶端會依規則選擇策略；節點測試通常會直接測試指定節點，兩者的流量路徑可能不同。請在連線頁面或執行日誌中確認目標網域、命中的規則與最後使用的節點。

• 瀏覽器失敗，但明確指定代理的請求成功：檢查系統代理連接埠、瀏覽器本身的代理設定、擴充功能接管情況與略過清單。既有連線可能仍沿用舊路徑，可關閉相關連線後重新發出請求。
• 瀏覽器正常，但終端機失敗：終端機工具不一定會讀取系統代理。可先使用本文的 curl -x 明確指定代理方式驗證，再決定是否設定該工具支援的代理環境變數。
• 需要接管更多應用程式：TUN 可處理部分不讀取系統代理的流量，但仍需要相應權限，並仰賴路由與 DNS 設定。啟用 TUN 無法修復過期訂閱、錯誤密碼或失效節點。
• 若曾暫時調整日誌層級：排查完成後，請將 log-level 恢復為日常使用的 info 或原本的設定，避免長期保留大量包含存取目標的資訊。