先確認失敗發生在哪個環節，再看錯誤關鍵字

dial tcp 只表示「嘗試建立 TCP 連線」，並不是故障原因。真正要看的是後面的位址、連接埠和錯誤訊息。i/o timeout 表示某次網路讀寫等待逾時；no such host 則表示目前的解析流程未能取得可用的主機位址。這三個詞不能直接分別解讀為「節點故障」、「網路太慢」或「換 DNS」。

代理請求通常會經過「應用程式 → 本機代理入口 → 規則與策略組 → 節點伺服器 → 目標網站」。DNS 查詢可能發生在解析節點網域、目標網域等不同環節。先辨認失敗位址屬於哪個環節，才能判斷該調整本機連接埠、節點選擇還是 DNS 設定。

記錄一次請求，留下必要的排查資訊

  1. 開啟用戶端的「日誌」頁面，記下錯誤發生時間；介面名稱可能是「運行日誌」或「Logs」。
  2. 記錄目前的模式、啟用中的設定檔名稱、策略組實際選用的節點，以及系統代理和 TUN 的開關狀態。
  3. 暫時將日誌層級設為 debug，只重現一次錯誤。排查完成後改回 info，避免日誌持續增加。
  4. 保留錯誤發生前後的匹配規則、出口選擇和完整錯誤訊息，不要只截取紅色關鍵字。

常見錯誤對照：先找出問題，再調整設定

日誌結尾或關鍵字代表意義優先檢查項目
connection refused連線遭到拒絕確認連線位址和連接埠是否正確，以及服務是否正在監聽
i/o timeout網路操作超過等待時間確認逾時發生在 DNS、節點連線還是目標回應
no such host網域名稱解析失敗確認實際網域、拼字及使用的 DNS 解析路徑
address already in use本機監聽位址已被占用確認衝突的連接埠及占用中的程序
network is unreachable目前網路沒有可用路由檢查 IPv4／IPv6 路由、網路介面卡和隧道狀態
certificate has expired憑證有效期限檢查失敗檢查系統時間、節點憑證及伺服器維護狀態

單一錯誤訊息也可能包含多層原因，例如外層顯示 dial failed，內層才指出 DNS 查詢逾時。閱讀時應先從最內層的具體錯誤看起，再往外確認是哪一條連線觸發了錯誤。

dial tcp 與 connection refused：先確認連線目標

dial tcp 192.0.2.10:443: connect: connection refused

這段日誌表示連線至 192.0.2.10:443 建立 TCP 連線時遭到拒絕。常見原因包括服務未啟動、連接埠設定錯誤，或網路設備主動拒絕連線。如果這是節點伺服器的位址，先核對目前節點的 server 和 port；如果是直連目標，則檢查規則是否將請求送往 DIRECT。

看到 127.0.0.1 時，優先檢查本機代理入口

Failed to connect to 127.0.0.1 port 7890: Connection refused

這類訊息也可能來自瀏覽器或命令列工具，而非 Clash 日誌。通常表示應用程式無法連上本機代理入口：核心尚未執行、入口連接埠已變更，或應用程式仍使用舊連接埠。先開啟用戶端的連接埠設定，確認實際監聽的連接埠，再核對系統代理的位址和連接埠。

  • mixed-port: 7890：同一個連接埠可接收 HTTP 代理和 SOCKS 代理流量。
  • port：HTTP 代理入口；socks-port：SOCKS 代理入口，不能只看連接埠號碼猜測通訊協定。
  • external-controller：控制介面，不是瀏覽器應使用的代理入口。

例如控制介面為 127.0.0.1:9090，不代表系統代理應填入 9090。混淆代理入口與控制介面，可能導致連線失敗、回應異常或網頁無法載入。

i/o timeout：分開測試 DNS、節點和目標網站

i/o timeout 只表示某項網路操作未能在期限內完成。可能發生在 DNS 的 UDP 查詢、連線至節點伺服器，或建立連線後的讀寫過程。只看到這個錯誤就連續更換十幾個節點，很容易掩蓋真正的本機網路問題。

第一步：指定代理入口重現問題

如果實際使用的混合連接埠是 7890，可以執行以下命令。Windows PowerShell 請使用 curl.exe，避免某些環境將 curl 解讀為其他命令；macOS 和 Linux 通常使用 curl。

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

此處的 10 秒是連線階段的上限，20 秒是整次操作的上限，並非核心的預設逾時值。-I 會送出 HEAD 請求，伺服器可能回傳 405；只要收到有效的 HTTP 回應，就不能把這個狀態碼視為網路逾時。需要查看回應內容時，可以移除 -I。

第二步：一次只變更一個項目

  1. 保持目標網址和規則不變，只在同一個策略組中切換至另一個已知可用的節點，再重新送出請求。
  2. 保持節點不變，改測另一個允許存取的目標。若只有單一目標失敗，優先檢查目標網站的限制或相關規則。
  3. 保持用戶端設定不變，改用手機熱點測試。只有在熱點正常、原本的網路失敗時，才有理由繼續檢查原網路的路由或過濾設定。

延遲測試按鈕顯示成功，不代表所有網頁都能正常使用。測試網址、HTTP 狀態碼要求和實際使用的目標可能不同；同樣地，測試失敗也不一定表示節點完全無法使用。應以實際發生問題的請求交叉驗證。

no such host：先確認解析失敗的是哪個網域

lookup node.example.net: no such host

如果錯誤訊息中的網域是節點的 server，表示代理通道尚未建立。此時先確認節點網域是否拼寫正確、訂閱是否過期或遭服務商更換，再檢查節點網域使用的解析路徑。如果錯誤指向目標網站，則應檢查目標網域解析和匹配規則，不能直接認定訂閱失效。

依序檢查三個環節

  1. 位址本身：確認 server 欄位沒有填入含有 https://、路徑或結尾空格的完整網址。此欄位通常應填主機名稱或 IP 位址。
  2. 系統解析：執行 nslookup node.example.net。這裡的網域僅為格式範例，測試時請換成日誌中的實際網域，並留意查詢會送至目前使用的解析器。
  3. 核心解析：核對實際生效設定中的 dns 區段，並查看同一時間是否出現解析器連線逾時或遭拒的訊息。

nslookup 的結果只能用來比對，不能證明核心 DNS 一定正常。系統解析器、Clash 內建 DNS 和瀏覽器安全 DNS 可能分別使用不同路徑；TUN 的 DNS 劫持也會改變查詢路徑。

如果設定了「透過代理存取的加密 DNS」，但代理節點網域又必須依靠該 DNS 才能解析，就可能形成啟動依賴循環。應先建立可用的節點網域解析路徑，而不是強制將所有 DNS 請求送入尚未建立的代理。

address already in use：如何排查本機連接埠衝突

listen tcp 127.0.0.1:7890: bind: address already in use

這是本機監聽失敗，和節點方案或遠端網域沒有直接關係。常見情況包括另一個代理用戶端已在執行，或舊的核心程序未完整結束。先確認是哪個程序占用了連接埠，再決定關閉舊程序或變更連接埠；不要直接結束不熟悉的系統程序。

Windows：找出監聽中的程序

netstat -ano | findstr :7890
tasklist /FI "PID eq 1234"

第一個命令會列出包含該連接埠的記錄，請核對本機位址、LISTENING 狀態和 PID。第二個命令中的 1234 是範例程序編號，執行時請換成查詢到的實際 PID。只有連線記錄不代表該程式占用了監聽入口。

macOS／Linux：查看監聽程序

lsof -nP -iTCP:7890 -sTCP:LISTEN

Linux 若未安裝 lsof，可以改用 ss -ltnp 'sport = :7890'。顯示程序資訊可能需要額外權限。若決定將混合連接埠從 7890 改為 7891，系統代理、瀏覽器擴充功能、終端機環境變數，以及其他手動設定的應用程式入口都必須一併更新。

介面顯示「已啟動」不代表每個入口都成功開始監聽。請檢查啟動後的日誌，確認錯誤涉及的是 mixed-port、DNS 監聽連接埠還是控制介面，避免改錯設定。

TUN、憑證與連線中斷：別把問題都當成逾時

  • network is unreachable：先確認位址是否為 IPv6，再檢查目前網路是否有可用的 IPv6 路由。這比較像是路由問題，不能只憑這一行就判定伺服器離線。
  • permission denied 或 operation not permitted：若錯誤出現在建立 TUN 裝置時，請檢查用戶端服務模式、系統授權和是否有其他 VPN 占用。請依照目前用戶端的安裝說明處理權限，不要隨意提高整個程式的權限。
  • x509: certificate has expired or is not yet valid：先檢查系統日期、時間和時區，再確認節點憑證。不要把 skip-cert-verify: true 當成長期解決方案。
  • connection reset by peer 或 EOF：表示連線遭到重設或讀取已結束，可能與伺服器端、通訊協定參數或中間網路有關。光看這一行，無法判斷是不是密碼錯誤。

比較 TUN 狀態時，先記下原本設定，再關閉 TUN，並以明確指定 127.0.0.1:7890 的請求進行測試。如果明確指定代理後正常，但 TUN 仍失敗，請優先檢查路由、DNS 劫持及與其他 VPN 的衝突。關閉 TUN 後直接開啟瀏覽器並不等同於這項測試，因為瀏覽器可能改用系統代理，也可能直接連線。

如果只有某個應用程式無法使用，先確認它使用 TCP 還是 UDP、是否會讀取系統代理，以及是否有自己的代理設定。HTTP 代理請求成功，不代表 UDP 轉送也正常；也不必因此立即修改全域模式或整份訂閱設定。

修正後再次測試：保留可比較的依據

  1. 使用相同網址、相同請求方式和相同策略組重新測試，確認原本的錯誤不再出現。
  2. 檢查日誌中實際匹配的規則和出口，避免請求只是意外改為直連。
  3. 還原暫時調整的日誌層級和測試開關，並保存必要的本機設定變更。
  4. 尋求協助時，請提供核心名稱與版本、作業系統版本、錯誤發生時間、完整錯誤鏈及重現步驟。

排查順序可以固定為：本機入口 → 規則出口 → 節點解析與連線 → 目標回應。每次只修改一個項目，並記錄修改前後的同一筆請求，通常比反覆重新安裝更容易找出原因。連接埠設定可參閱入門指南的連接埠說明；若持續逾時，可接著查看問題診斷中的逾時排查。