Clash 執行日誌怎麼看：常見錯誤訊息與故障排查順序

LOG LAYERS

先判斷日誌來自哪一層

Clash 用戶端出現「連線失敗」時，介面提示通常只是最終結果，執行日誌才會記錄失敗發生在哪個階段。開始分析前，先區分三層資訊：用戶端介面層、代理核心層與作業系統網路層。用戶端負責設定管理、系統匣選單與系統代理開關；Clash、Clash Meta 或目前使用的 mihomo 核心負責監聽連接埠、解析規則、建立代理連線與處理 DNS；作業系統則管理網路介面、路由、防火牆、權限及本機連接埠。三層中的任何一層失敗，都可能在介面上呈現為「無法連線」。

不同用戶端對同一條核心日誌的顯示方式可能不同。有些會保留時間、日誌層級與模組名稱，有些只顯示訊息本文。mihomo 更新版本後，欄位名稱與措辭也可能改變。因此不要只搜尋完整錯誤句子，應擷取其中穩定的物件，例如設定檔路徑、監聽位址、連接埠號碼、網域名稱、節點名稱、網路類型與系統錯誤。

單獨出現 warning 或 error 不一定代表所有代理流量都已中斷。例如某個節點連線逾時，只會影響當次連線或對應的策略群組；一台備用 DNS 伺服器失敗，也可能由其他伺服器完成查詢。判斷影響範圍時，應同時查看錯誤物件、發生頻率，以及後續是否出現成功紀錄。

REPRODUCE FIRST

依時間順序重現問題

有效的日誌分析需要明確的重現流程。不要讓用戶端連續執行數小時後，再從混雜設定更新、延遲測試與背景程式連線的紀錄中猜測原因。更可靠的方法是清除目前日誌或記下起始時間，接著只執行一個會觸發問題的動作。如此即可將使用者操作與日誌時間對應起來。

1. 記錄目前環境。確認用戶端名稱、核心類型、作業系統、目前設定檔、代理模式，以及是否啟用 TUN。剛完成用戶端或核心更新時，也要記下更新前後的狀態。
2. 停止無關測試。暫時關閉自動測速、設定自動更新，以及會持續產生連線的程式，減少日誌雜訊。
3. 從較低的日誌量開始。先使用 info 層級重現問題；如果只能看到連線失敗結果，再暫時切換到 debug。問題定位後恢復常用層級，避免日誌快速增長。
4. 只執行一個動作。例如更新一次訂閱、開啟一個確定的網頁、切換一次節點，或單獨啟用 TUN。
5. 找出第一筆異常。從操作發生的時間點往下查看，找出最早的 warning、error 或明顯逾時，再檢查它前面的設定與路由資訊。
6. 修改一個變數後重試。每一輪只更換節點、連接埠、DNS 或執行模式中的一項，否則無法確認是哪項修改生效。

日誌中的時間順序比錯誤數量更有價值。假設先出現設定解析失敗，接著出現控制連接埠連線失敗，最後介面提示核心未執行，那麼根因通常是第一筆設定錯誤，而不是最後的控制連接埠錯誤。又如 TUN 初始化失敗後，應用程式仍能透過系統代理存取網路，表示代理核心可能正常，只是透明接管路徑尚未建立。

啟動用戶端
→ 讀取設定
→ 初始化 DNS 與規則
→ 監聽本機代理連接埠
→ 初始化 TUN（若啟用）
→ 接收應用程式連線
→ 比對規則
→ 選擇節點
→ 建立遠端連線

可以把這條流程當成檢查順序。錯誤發生在哪個步驟，就先處理該步驟及其依賴的前置步驟，不要直接跳到更換節點或重新安裝用戶端。

CONFIG PARSER

設定檔解析與核心啟動錯誤

設定錯誤通常發生在核心正式監聽連接埠之前。常見關鍵字包括 parse、yaml、unmarshal、invalid config、field、duplicate 和 not found。出現這類錯誤時，繼續測試節點或系統代理沒有意義，因為核心可能尚未載入可執行的設定。

YAML 結構無法解析

YAML 依靠縮排表達階層。使用 Tab、清單項目的階層不一致、冒號後缺少空格，或引號未閉合，都會導致解析停止。日誌通常會提供行號與欄號，但實際問題也可能位於提示行之前，例如上一行字串未結束，解析器直到下一行才發現結構不合法。

proxies:
  - name: Example
    type: ss
    server: example.test
    port: 443

proxy-groups:
  - name: SELECT
    type: select
    proxies:
      - Example

檢查時先確認縮排全部使用空格，再查看錯誤行前後數行。節點名稱包含冒號、井字號或其他具有 YAML 語意的字元時，應由設定提供方正確加上引號。手動編輯設定後出現錯誤，可以先復原修改，確認原始設定是否能夠載入。

欄位存在但目前核心不支援

Clash 設定並非所有核心版本都完全通用。某些欄位只有 mihomo 支援，舊核心讀取時可能回報未知欄位、型別錯誤或缺少必要參數。反過來，用戶端更新核心後，過時欄位也可能觸發警告。此時要確認用戶端實際呼叫的核心，而不是只看用戶端產品名稱。設定適用於 mihomo 時，應使用支援相應語法的用戶端與核心版本。

引用的物件不存在

策略群組引用了不存在的節點、規則指向未定義的策略群組，或規則集合路徑無法讀取，都會造成載入失敗或部分功能無法使用。重點比對錯誤中的物件名稱，檢查大小寫、空格與全形字元。名稱必須完全一致；看似相同的前後空格也可能導致引用失敗。

LISTENER STATUS

連接埠占用與系統代理錯誤

連接埠錯誤的典型關鍵字是 address already in use、bind、listen、permission denied 或 connection refused。Clash 核心通常需要監聽 HTTP、SOCKS、混合連接埠或外部控制連接埠。如果另一個核心執行個體、舊用戶端程序或其他網路工具已占用相同位址，新程序就無法完成監聽。

address already in use 表示指定的位址與連接埠已被其他程序占用。先退出所有同類用戶端，再檢查工作管理員或系統程序清單中是否仍有核心程序。不要只關閉視窗，因為部分用戶端仍會在系統匣中執行。確認沒有殘留程序後重新啟動；如果連接埠仍被占用，再改用未使用的連接埠，並同步更新依賴該連接埠的瀏覽器或應用程式設定。

permission denied 要結合監聽位置判斷。一般本機高位連接埠通常不需要特殊權限，但系統安全性原則、防火牆規則或受限制的執行目錄仍可能阻止操作。若日誌提到 TUN、路由或服務註冊，則屬於系統權限問題，不應透過反覆更換代理節點處理。

connection refused 的方向也很重要。用戶端介面連線外部控制連接埠遭拒，通常表示核心未啟動、控制位址不一致，或核心已經退出；代理核心連線遠端伺服器遭拒，則表示目標位址可達，但遠端對應連接埠沒有接受連線。兩者使用相同措辭，故障位置卻完全不同，必須查看日誌中的來源位址、目標位址與模組名稱。

系統代理開啟失敗不代表核心連接埠沒有運作。可以先確認日誌中本機代理已成功監聽，再檢查作業系統代理設定是否已指向對應連接埠。如果手動設定的瀏覽器可以連線，而一般應用程式無法連線，問題更可能位於系統代理設定、應用程式是否遵循系統代理，或應用程式本身的網路設定。

DNS PIPELINE

DNS 查詢與解析異常

DNS 問題常表現為網頁提示找不到網域、部分網站可用而部分網站失敗、啟用 TUN 後所有網域連線逾時，或日誌反覆出現 lookup、resolve、no such host、timeout、SERVFAIL。分析時先區分「網域未取得位址」與「已取得位址但後續連線失敗」。如果日誌已顯示目標 IP 並進入撥號階段，根因通常不再是最初的網域解析。

傳統 DNS、DNS over HTTPS 與 DNS over TLS 的依賴方式不同。加密 DNS 伺服器本身使用網域名稱時，核心可能需要透過 bootstrap 或預設解析器先取得伺服器位址。這個前置解析失敗，就會導致後續所有查詢無法送出。若日誌反覆查詢 DNS 伺服器網域並逾時，應檢查預設解析器、網路可達性及設定中的 nameserver-policy，而不是只更換代理節點。

Fake IP 模式下，應用程式會先收到保留位址，核心再依據內部對映還原原始網域名稱並執行規則比對。看到保留位址不代表解析錯誤。真正需要關注的是對映是否存在、目標網域是否被正確接管，以及某些不適合 Fake IP 的區域網路網域或裝置探索網域是否需要過濾。Redir Host 模式則會直接將解析結果回傳給應用程式，因此故障日誌的表現會有所不同。

DNS 逾時的排查順序

1. 確認設定可以正常載入，且 DNS 模組已完成初始化。
2. 查看失敗的是所有伺服器，還是其中一台備用伺服器。
3. 確認查詢使用直連還是代理路徑，以及相關策略是否形成循環依賴。
4. 檢查 DNS 伺服器的位址與協定格式是否受目前核心支援。
5. 關閉 TUN 後使用系統代理重試，判斷問題是否只存在於接管路徑。
6. 查看網域解析成功後，是否仍出現 TLS、連線逾時或路由失敗。

TUN DEVICE

TUN 模式啟動失敗

TUN 模式透過虛擬網路介面與系統路由接管更多應用程式流量，涉及權限、驅動程式、網路介面與路由表，因此錯誤範圍比一般系統代理更廣。常見關鍵字包括 tun、interface、route、adapter、device、service 和 operation not permitted。

第一步是判斷「核心整體失敗」還是「只有 TUN 初始化失敗」。如果本機 HTTP 或 mixed 連接埠已成功監聽，而且關閉 TUN 後系統代理可以運作，表示節點、規則與基礎核心大致可用，故障集中在虛擬網路介面路徑。此時應檢查用戶端要求的服務元件、執行權限，以及系統中的其他 VPN、虛擬機器或網路過濾工具。

出現介面建立失敗時，先徹底退出其他可能建立虛擬網路介面的程式，再重新啟動用戶端。出現路由新增失敗時，檢查是否存在同網段衝突、舊路由殘留或權限不足。若日誌指出找不到指定網路介面，可能是設定中固定了已變更的介面名稱；筆記型電腦從有線切換到無線，或重新安裝網路裝置後，介面識別可能發生變化。

macOS、Windows 與 Linux 的 TUN 實作及權限模型不同，不能直接套用其他平台的處理指令。桌面用戶端若提供服務模式或輔助服務，應先確認該元件狀態正常。Linux 環境還要確認 TUN 裝置與網路管理權限。無論在哪個平台，都應先使用用戶端本身提供的啟停入口測試，不要同時疊加多個接管工具。

啟用 TUN 後斷網但日誌沒有致命錯誤

這種情況要檢查預設路由、DNS 接管與規則結果。若日誌顯示連線進入 DIRECT，但直連流量無法從正確介面送出，可能是出口介面自動辨識失敗。若所有網域查詢都逾時，應先處理 DNS 路徑。若只有區域網路裝置無法存取，則檢查區域網路網段是否被錯誤接管，以及私人位址規則是否依預期直連。

排查 TUN 時建議保留一組對照測試：關閉 TUN，只開啟系統代理並存取相同目標。如果系統代理成功、TUN 失敗，繼續檢查網路介面與路由；如果兩種模式都失敗，再回到 DNS、節點與遠端連線層分析。

OUTBOUND CONNECTION

連線失敗、逾時與 TLS 錯誤

核心完成規則比對後，會透過選定的出站節點連線至目標。此階段的日誌通常包含目標網域或 IP、連接埠、網路類型、策略群組、節點名稱與耗時。最重要的問題是：連線的是節點伺服器，還是節點建立後再連線目標網站。日誌模組與位址有助於區分這兩段鏈路。

i/o timeout 或 context deadline exceeded

逾時表示操作未能在限定時間內完成，但單憑逾時無法判斷原因。節點伺服器無法連線、網路封包遺失、DNS 查詢遲遲沒有結果，或目標網站沒有回應，都可能產生逾時。先看逾時物件：如果是節點伺服器位址，可切換同一訂閱中的其他節點進行對照；如果多個不同地區的節點同時逾時，優先檢查本機網路、DNS 與防火牆；如果只有特定目標失敗，則查看規則結果與目標可達性。

connection reset by peer

這項訊息表示連線建立後，被對端或鏈路中的裝置重設。偶爾發生一次可能是網路波動或伺服器主動結束連線；持續發生則要核對節點協定、連接埠、傳輸層參數與伺服器狀態。不能只憑 reset 判定是用戶端故障。使用另一個節點存取相同目標，或使用同一節點存取不同目標，可以快速縮小範圍。

TLS handshake timeout 與憑證錯誤

TLS 握手逾時常見於鏈路品質不佳、目標無法連線或協定參數不相符。遇到憑證錯誤時，也要確認系統日期與時區是否正確，因為錯誤時間會使有效憑證被判定為尚未生效或已過期。節點設定包含伺服器名稱、傳輸層安全參數時，應保持訂閱下發內容完整，不要在不了解用途時手動刪除。

network is unreachable 與 no route to host

這類日誌指向路由層。可能是目前網路沒有對應的 IPv4 或 IPv6 出口、TUN 路由未建立、指定介面無法使用，或目標位址所在的網路無法到達。如果日誌顯示嘗試 IPv6 而本機網路沒有穩定的 IPv6，可以檢查 DNS 結果與核心的位址選擇；如果 IPv4、IPv6 都失敗，則回頭檢查系統網路與路由。

RULE MATCH

規則比對與流量去向

有時連線本身沒有報錯，但流量去向不符合預期，例如應代理的網域被直連、區域網路位址被送往節點，或策略群組選到了失效節點。這類問題要查看規則比對日誌，而不是只搜尋 error。debug 或詳細連線日誌通常會顯示目標、命中的規則與最終策略。

Clash 規則會依設定順序進行比對，命中後通常停止繼續檢查。較寬泛的規則若放在前面，可能覆蓋後方的精確網域規則。最後的 MATCH 規則負責承接先前未命中的連線。如果日誌顯示命中了錯誤策略，應回到設定中查找該規則的位置、規則集合內容，以及策略群組目前的選擇。

策略群組名稱不等於實際節點。日誌可能先顯示某連線交給名為「自動選擇」的策略群組，再由該群組選擇具體節點。排查時既要看規則將連線送往哪個群組，也要看該群組當時的實際選項。延遲測試成功只表示測試 URL 在測試當下可達，不保證節點能存取所有目標，也不代表長連線始終穩定。

DIRECT 同樣是一種明確的出站策略。命中 DIRECT 後失敗，應檢查本機網路、DNS 與目標網站，而不是期待代理節點解決。REJECT 則表示規則主動終止連線，日誌中的拒絕屬於設定的預期結果。應用程式反覆請求遭 REJECT 的網域時，可能產生大量紀錄，但這並非核心異常。

INCIDENT CHECKLIST

日誌收集與故障排查清單

需要向用戶端維護者、訂閱提供方或其他技術人員回報時，日誌應包含足夠的上下文，同時移除敏感資訊。有效回報不應只有一張「連線失敗」截圖，也不需要匯出數小時的完整紀錄。保留重現操作前後幾十秒的連續日誌，通常更容易定位問題。

應一併記錄的資訊

• 作業系統及版本、用戶端名稱與版本、實際核心類型與版本。
• 目前使用規則模式、全域模式或直連模式，以及是否啟用系統代理與 TUN。
• 問題出現前執行的動作，例如更新設定、切換節點、從睡眠恢復或升級用戶端。
• 可重複的操作步驟，以及問題是持續發生還是偶爾發生。
• 第一筆異常前後的連續日誌，而不是只截取最後一行。
• 關閉 TUN、切換節點或更換網路後的對照結果。

分享前應處理的內容

日誌與設定可能包含訂閱網址、驗證參數、節點伺服器位址、區域網路裝置位址、存取網域與本機檔案路徑。公開發布前應逐項檢查並遮蓋這些內容，但要保留錯誤類型、連接埠範圍、協定類別與時間順序。不要把所有位址都替換成同一個值，否則會失去「本機位址還是遠端位址」、「同一個目標還是多個目標」等關鍵關係。

從現象到根因的固定順序

1. 確認作業系統本身可以連上網路。
2. 確認設定解析完成，核心沒有在啟動階段退出。
3. 確認本機代理連接埠與控制連接埠已成功監聽。
4. 確認 DNS 查詢能夠回傳結果。
5. 啟用 TUN 時，確認虛擬網路介面與路由初始化成功。
6. 確認目標連線命中了預期的規則與策略群組。
7. 確認策略群組選擇了可用節點，並能連線至節點伺服器。
8. 最後再檢查目標網站、TLS 握手與應用程式本身的代理設定。

這套順序的核心是先處理上游依賴。設定尚未載入時不要測試連接埠，連接埠尚未監聽時不要檢查應用程式代理，DNS 尚未完成時不要判斷目標連線，TUN 尚未建立時不要將所有逾時歸咎於節點。每次只改變一個條件，並保留修改前後的日誌對照，通常比反覆切換多項設定更快找到根因。