兩種「連不上」：先分是本機還是出網
很多人遇到的情境是：工作列圖示正常、訂閱也更新成功，但瀏覽器開網頁一直轉圈，或每隔幾分鐘就掉線。此時若同時改節點、改 DNS、重裝用戶端，往往難以判斷到底是哪一層壞了。
實務上可先粗分兩類：本機服務沒有正確監聽或連接埠被佔用，以及代理已經在跑，但對外建立隧道或撥號到節點失敗。前者常出現在啟動階段或切換設定後的幾秒內；後者則多半伴隨對特定網域、特定節點的重試與逾時訊息。
下文以 Mihomo（Clash Meta） 與常見圖形介面為例，說明日誌裡哪些字串偏向「連接埠／綁定」問題、哪些偏向「節點／線路」問題。請在合法合規前提下使用代理工具，本文不提供規避法規或濫用網路資源的指引。
看日誌前先確認三件事
第一，日誌等級是否足以看到錯誤與連線細節；若只開到 silent 或過度過濾，可能只剩「感覺壞了」而沒有線索。第二，時間點要對齊：是「一開程式就報錯」還是「開某個網站才爆量」；兩者對應的排查順序不同。
第三，代理模式要心裡有數：系統代理、TUN、或手動指向 socks-port／mixed-port，錯配時症狀類似，但日誌裡看到的來源位址與規則命中會不一樣。若你使用 Clash Verge Rev 等桌面用戶端，建議搭配完整教學把「介面開關」與實際 YAML 是否一致先對齊，再來讀日誌才不會誤判。
連接埠佔用與綁定失敗：mixed-port、socks-port
Clash 系核心會在本機開 listener，讓瀏覽器或其他程式把流量送進來。最常見的兩個欄位是 mixed-port（常同時承 HTTP 與 SOCKS）與 socks-port；有些設定還會另開 port（HTTP）或 redir-port、tproxy-port 等。
當你看到日誌或主控台出現類似 address already in use、bind: address already in use、listen tcp 後面接著某個 127.0.0.1:7890 之類位址，或啟動直接失敗並反覆重試同一連接埠，高度代表：該連接埠已被其他行程佔用。佔用者可能是另一套 Clash／Mihomo、舊程序未結束、其他本機代理、或某個開發伺服器剛好選了同一號碼。
另一種變體是 permission denied 或無法綁定特定介面：在類 Unix 系統上若埠號小於 1024，可能需要更高權限；在 Windows 上則較少見，但仍要留意公司資安軟體攔截本機 listener。這類訊息與「連出去逾時」不同：問題發生在「本機 socket 還沒站好」之前。
處理方向很具體：在設定檔把 mixed-port／socks-port 改成空閒埠、關掉重複的代理程式、或用系統工具查誰佔用了該埠。改完後務必完全重啟核心，避免舊行程仍握著舊埠。
dial tcp 與連線逾時：多半是節點或線路
當核心已經在聽本機埠，日誌裡開始出現 dial tcp 或 connect tcp 指向你的節點位址與遠端埠，後面若接 i/o timeout、context deadline exceeded、connection reset、或長時間重試，通常代表：從你的機器到該上游的路徑沒有在預期時間內建好連線。
這與本機連接埠衝突的差別在於：錯誤發生在「對外撥號」階段，而不是 bind 本機。可能原因包含節點暫時擁塞、出口被封鎖、DNS 指到錯誤位址、TLS／SNI 被干擾、或訂閱裡該節點已失效。若只有特定網站失敗，也要想到規則把流量送到某個慢節點或錯誤策略，日誌裡會看到對應的 outbound 名稱。
實務上建議單變因測試：換一個已知較穩的節點、暫時改成全域走同一個出口、或對同一目標網域開啟更詳細的 log，確認是「每一條 dial 都逾時」還是「只有命中某規則才逾時」。若你也遇到 DNS 相關的間歇解析失敗，可交叉閱讀DNS 防洩漏與解析設定指南，避免把純解析問題誤認成節點掛掉。
日誌關鍵字速查：該往哪邊查
下面用「關鍵字 → 較可能的層級」做速查，方便你開著日誌逐行對照。
- already in use／bind／listen … failed：優先查本機連接埠與重複行程；對應設定
mixed-port、socks-port、port等。 - dial tcp … timeout／i/o timeout：優先查節點可用性、線路品質、防火牆與系統時間；必要時對照訂閱與規則 outbound。
- TLS handshake timeout／x509：偏向傳輸層或憑證問題，可能是節點設定變更、中間人攔截、或本機時間嚴重偏移。
- reject／rule match：可能是規則刻意丟棄或走 DIRECT 後目標不可達；要與「真的連不上節點」區分開來。
同一條日誌裡若同時出現本機位址與遠端位址，請先看錯誤動詞是針對哪一端：bind／listen 是本機；dial／connect 多半是出網。
易混淆情境：DNS、TUN 與「假逾時」
有些使用者看到瀏覽器一直轉圈，就以為是節點逾時；實際上可能是 DNS 沒回應或 fake-ip 與規則不一致，應用程式一直在等解析結果，日誌裡卻不一定立刻出現顯眼的 dial 錯誤。此時除了關鍵字，還要看是否有 DNS 查詢日誌、是否命中了預期的 nameserver。
若你啟用 TUN，整機流量路徑更長一層；介面或路由異常時，症狀也像「全面連不上」。Windows 使用者可參考TUN 與 Wintun 排查文，先確認不是虛擬網卡或路由把封包導錯，再回來看 dial 日誌。
建議排查流程（可重複驗證）
- 啟動當下先看有沒有 bind／listen 類錯誤；有則先解連接埠與重複程序，再測。
- 本機 listener 正常後，複現問題並篩選
dial tcp行：記下目標位址、outbound 名稱、是否僅特定網域。 - 換節點或暫時簡化規則，若逾時隨節點消失，偏向線路或節點品質；若與規則綁定，檢查該條規則與策略群組。
- 同步檢查 DNS 與時間：無效解析與憑證錯誤常偽裝成「連線很慢」。
- 調整後重啟核心與瀏覽器，避免連線池與快取讓舊錯誤殘留。
想從訂閱與規則面減少「誤分流導致的假逾時」，也可一併參考提速與調校技巧，把測速、延遲與規則精簡放在同一套維護節奏裡。
開源核心與版本差異
不同版本的核心在日誌格式與欄位名稱上可能略有差異，但「bind 失敗」與「dial 逾時」兩大類通常仍分得清楚。若要核對某欄位在當前版本的精確意義，可到 GitHub 上的 Mihomo 倉庫查文件與更新日誌。安裝包取得與用戶端更新仍建議以本站下載頁為主，避免核心與圖形介面版本脫節造成行為差異。
小結
Clash 日誌裡，連接埠佔用多半表現為 mixed-port、socks-port 等 listener 無法綁定；節點或線路問題則常落在 dial tcp 之後的連線逾時或握手失敗。先把這兩類分開，再決定是改本機埠、排除連接埠衝突，還是換節點、查 DNS 與規則，能顯著減少無效嘗試。
相較於零散搜尋錯誤碼，用固定順序對照日誌關鍵字，通常更快定位問題層級。若你希望用已整合 Mihomo、並把常見連接埠與日誌選項整理過的用戶端，也能降低手動對設定檔的負擔；建議前往本站下載頁依平台取得安裝包，再依本文流程邊看日誌邊驗證。