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

先確認日誌來源與時間範圍

Clash 用戶端中的「日誌」可能來自兩個不同層級：圖形用戶端負責下載訂閱、切換設定、啟動核心與設定系統代理；Clash Meta（mihomo）等核心則負責 DNS、規則比對、建立連線、選擇策略組與處理 TUN 資料。兩類日誌混在同一個視窗時，必須先確認錯誤發生在哪個層級。

例如，訂閱請求回傳 403 通常屬於用戶端的設定更新流程；某個網域命中規則後連線逾時，則屬於核心執行階段。只截取最後一行，容易把結果誤當成原因。正確做法是從故障發生時間往前查看，找出第一筆異常，以及異常前最後一筆正常紀錄。

日誌行通常包含哪些資訊

• 時間：用來對應使用者操作與日誌，例如點選更新訂閱、切換節點或啟用 TUN 的確切時刻。
• 層級：debug 提供詳細流程，info 記錄正常狀態，warn 表示需要注意但不一定會中斷，error 表示目前步驟失敗。
• 模組：常見模組包括設定載入、DNS、入站監聽、代理撥號、規則比對與 TUN。
• 目標：可能是網域、IP、連接埠、網路介面、設定檔路徑或策略組名稱。
• 錯誤鏈：一則錯誤可能由多個短語串接而成，通常從左至右描述執行過程，最末端是作業系統或網路函式庫回傳的直接原因。

排查前先重現一次最小故障：清空或記住目前的日誌位置，只執行一個動作，再儲存這小段日誌。若問題是網頁無法開啟，不要同時更新訂閱、切換模式、修改 DNS 和更換節點。一次改變多個條件，會讓日誌中的因果關係失去參考價值。

啟動與設定解析錯誤：先看檔案，再看連接埠

核心無法啟動時，後續的 DNS、規則與節點測試都沒有意義。此階段應先確認設定檔能否讀取與解析，再檢查監聽連接埠、控制連接埠、檔案權限及資源檔案。圖形介面顯示「啟動失敗」只是彙總狀態，真正原因通常位於它前面的幾行。

設定語法與欄位錯誤

常見訊息包括 yaml、unmarshal、invalid config、field not found 或特定行列位置。YAML 對縮排敏感，Tab、層級錯位、未閉合引號和清單格式錯誤都會阻止載入。以下規則必須位於清單層級中：

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

若日誌指出未知欄位，還要核對設定所對應的核心類型與版本。Clash Meta（mihomo）支援的部分欄位不屬於舊版 Clash 的設定能力，反向情況也可能發生。不要只因檔案副檔名是 .yaml 就判斷相容性；應查看欄位名稱、代理協定、規則集寫法與 DNS 設定結構。

連接埠已被占用

address already in use 表示指定的監聽位址與連接埠已被其他程序占用。常見對象是 mixed-port、port、socks-port 或 external-controller。這通常發生在舊核心未正常結束、另一款代理工具正在執行，或兩份設定同時監聽相同連接埠時。

處理順序是：先確認是否存在重複的 Clash 或 mihomo 程序，再檢查其他代理軟體，最後才考慮修改連接埠。修改後還應同步更新瀏覽器、終端機環境變數或區域網路裝置中填寫的代理連接埠，否則核心雖然啟動，應用程式仍會連線至舊連接埠。

權限與檔案路徑問題

permission denied 需要結合目標路徑判斷。存取設定目錄失敗，通常與目錄權限或檔案被占用有關；建立 TUN 介面失敗，則可能與系統管理員權限、系統延伸功能或網路服務權限有關。no such file or directory 往往表示設定引用的規則集、GeoIP 資料庫或憑證檔案遺失。此時應核對日誌中的完整路徑，不要只檢查目前開啟的主設定檔。

訂閱更新錯誤：區分下載失敗與解析失敗

訂閱更新由「發出請求、取得回應、辨識內容、產生設定、載入設定」組成。介面最後都可能顯示更新失敗，但每個階段的處理方式不同。首先記錄 HTTP 狀態、回應類型與解析資訊，再決定要檢查網路、訂閱權限還是格式相容性。

瀏覽器能開啟訂閱網址，不代表用戶端一定能完成更新。瀏覽器與用戶端可能使用不同的網路路徑、User-Agent、DNS 結果或代理設定。排查時應關注用戶端實際記錄的狀態碼與回應，而不是只依據瀏覽器頁面。

還要區分「訂閱內容為空」與「設定中沒有可用節點」。某些訂閱回傳完整的 Clash 設定，包含 proxies、proxy-groups 和 rules；另一些只提供通用節點清單，需要由用戶端轉換。若轉換器不認識協定欄位，可能只產生部分節點，甚至無法產生策略組。此時應保留原始回應類型的判斷資訊，並核對訂閱是否明確提供 Clash 或 Mihomo 格式。

DNS 錯誤：判斷是解析失敗還是連線失敗

DNS 日誌經常出現在連線錯誤之前，但網域無法存取不一定都是 DNS 問題。應先判斷日誌是否取得目標 IP：若出現明確的解析逾時、上游無法連線或空回應，問題位於 DNS 階段；若已取得 IP，之後才出現撥號逾時或 TLS 錯誤，則應繼續檢查代理鏈路。

常見 DNS 日誌含義

• no such host：系統解析器或指定上游未回傳可用位址，也可能是網域本身拼寫錯誤。
• i/o timeout：向 DNS 上游送出查詢後，未能及時收到回應，需要檢查上游位址、網路路徑與防火牆。
• connection refused：目標 DNS 服務位址可達，但相應連接埠未接受連線，或本機轉送服務未執行。
• server misbehaving：上游回應異常，可能涉及協定不相容、回應格式問題或中間網路干擾。
• fake-ip 相關紀錄：表示網域進入 Fake-IP 對映流程，本身不代表錯誤，應繼續查看後續規則比對與實際連線結果。

在 Fake-IP 模式下，應用程式先取得保留位址範圍中的對映 IP，核心再根據對映還原網域並執行規則。看到目標位址屬於 Fake-IP 範圍時，不應直接把它當成遠端伺服器位址。若某些區域網路服務、時間同步、遊戲或特殊協定運作異常，可以檢查 fake-ip-filter 是否需要排除對應網域，但不宜將大量網域無條件加入過濾清單。

啟用 TUN 後，DNS 還可能經過攔截與重新導向。此時系統設定中顯示的 DNS 伺服器，不一定等於最終使用的上游。排查時要同時確認 Clash 的 dns.enable、監聽位址、nameserver、fallback 或策略型 DNS 設定，以及 TUN 的 DNS 攔截設定。若連接埠 53 已被本機解析服務占用，日誌通常會在啟動階段顯示監聽失敗，而不是等到瀏覽網頁時才出現。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

上例僅用於展示欄位關係，實際設定應依據目前網路與核心文件選擇上游。修改 DNS 時一次只改一項，並以同一個網域重複測試。若同時切換增強模式、上游協定和 TUN 攔截，日誌變化將難以判斷原因。

連線、握手與逾時錯誤：沿著代理鏈逐段檢查

當規則選出策略與節點後，核心會連線至代理伺服器，再由代理伺服器存取目標。日誌中的逾時可能發生在本機至節點、節點至目標、代理協定握手或 TLS 握手的任何階段。判斷關鍵是找出錯誤前的出站名稱、目標位址與網路類型。

connection refused

拒絕連線表示目標主機明確回傳連接埠不可用。若目標是代理節點位址，應檢查節點連接埠、服務狀態與協定設定；若目標是本機控制連接埠，則檢查用戶端連線的控制位址是否正確。它與逾時不同：逾時通常沒有及時回應，拒絕則表示網路已抵達某台主機，但該連接埠未接受連線。

i/o timeout 與 context deadline exceeded

這類訊息表示操作超過時間限制。先切換至已知可用的節點，再測試相同目標。若多個節點同時逾時，應檢查本機網路、DNS、系統防火牆與代理模式；只有單一節點逾時，則優先檢查該節點線路。若一般網頁可用而特定網站逾時，再查看規則是否將該網域分配給不合適的策略。

EOF、連線重設與 TLS 握手失敗

EOF 表示連線在預期資料完成前被關閉，單獨一則訊息不足以確定原因。可能來自遠端主動中斷、代理協定參數不相符、傳輸層設定差異或中間網路重設。connection reset by peer 則更明確表示對端或鏈路設備重設了連線。

TLS 錯誤需要注意系統時間、憑證網域、SNI、節點傳輸設定與目標網站。若日誌顯示憑證名稱不相符，不應透過長期關閉憑證驗證來掩蓋問題，而應核對伺服器名稱與節點參數。系統時間偏差也會造成憑證尚未生效或已過期的判斷異常。

UDP 與 TCP 的表現不同

節點能開啟網頁，只能證明主要的 TCP 路徑可用。語音、遊戲、QUIC 或部分 DNS 請求依賴 UDP。若日誌在 UDP 連線處失敗，應確認節點協定與伺服器端是否支援 UDP、策略組是否選擇相應節點，以及系統防火牆是否允許相關流量。排查時可暫時讓應用程式退回 TCP，用來判斷故障是否只存在於 UDP 路徑，但最後仍應修正實際設定。

規則比對、代理模式與 TUN：日誌正常也可能是路徑錯誤

有些故障不會出現明顯的 error。連線成功，卻走了錯誤節點或意外直連，通常屬於規則、模式或流量接管範圍問題。此時應暫時將日誌層級調整為 debug，觀察網域、程序、規則類型、策略組與最終出站之間的關係，測試完成後再恢復常用層級，避免日誌量持續增加。

先確認目前的代理模式

• 規則模式：依規則由上至下比對，命中後使用指定策略。大多數精細分流問題都應在此模式下排查。
• 全域模式：流量統一交給全域策略，規則清單通常不參與一般分流。測試節點連通性時很有用，但無法驗證規則是否正確。
• 直連模式：流量直接連線至目標。若忘記切回規則模式，即使節點狀態正常，也不會建立預期的代理連線。

在規則模式下，順序比規則數量更重要。例如寬泛的 DOMAIN-SUFFIX 放在精確規則之前，可能提前攔截目標；GEOIP、GEOSITE、規則集與最終 MATCH 的位置也會改變結果。若日誌顯示命中了意外規則，應回到設定中搜尋該規則，並檢查它前面的涵蓋範圍，而不是只修改最終策略組。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

以上順序會讓 api.example.com 先直連，其他 example.com 子網域再進入代理。若兩條規則對調，精確規則將沒有機會命中。

TUN 已啟用但應用程式沒有出現在日誌中

如果應用程式發出請求時，日誌完全沒有對應的連線，問題通常位於流量進入核心之前。檢查 TUN 介面是否建立成功、預設路由是否安裝、自動路由設定是否生效，以及其他 VPN、虛擬網卡或安全軟體是否改變路由優先順序。某些應用程式還可能使用獨立代理設定；若該設定指向舊連接埠，也會繞過目前的 TUN 路徑。

日誌出現 operation not permitted、介面建立失敗或路由新增失敗時，應檢查執行權限與系統網路能力。Linux 環境還需注意 TUN 裝置、網路管理員、路由表與服務帳戶權限；Windows 和 macOS 則應查看虛擬網卡、系統延伸功能或系統管理員授權狀態。不同用戶端的封裝方式各異，判斷應以日誌中實際失敗的系統操作為準。

可重複使用的排查順序：從第一處異常到設定項目

穩定的排查流程應從底層狀態逐步走向具體請求。跳過啟動狀態直接更換節點，或看到 DNS 字樣就重寫整份 DNS 設定，通常只會增加變數。以下順序適用於「無法啟動、訂閱更新失敗、網頁無法開啟、只有部分應用程式異常」等常見情境。

1. 記錄故障範圍。明確確認是所有網站、單一網域、某個應用程式、TCP、UDP，還是只在啟用 TUN 後發生。
2. 確認核心正在執行。檢查設定是否載入成功、代理連接埠與控制連接埠是否正在監聽，以及是否存在權限或檔案遺失錯誤。
3. 確認設定來源。如果剛更新訂閱，先判斷下載是否成功、回應是否為正確格式，以及新設定能否解析。
4. 確認請求已進入核心。執行一次可重複的測試，在對應時間查看是否出現連線紀錄。沒有紀錄時，檢查系統代理、應用程式代理與 TUN 路由。
5. 確認 DNS 結果。查看網域是否完成解析、Fake-IP 對映是否符合目前模式，以及 DNS 上游是否逾時。
6. 確認規則與策略。核對目前模式、命中規則、策略組與實際節點，避免將錯誤分流誤判為節點故障。
7. 確認連線階段。區分本機至節點、協定握手、TLS、節點至目標及 UDP 路徑，按階段逐一替換單一條件進行測試。
8. 回復最近的變更。恢復上一份可用設定，再逐項套用 DNS、TUN、規則或節點變更，找出引入故障的最小差異。

一份有效的排查紀錄至少應包括：用戶端與核心名稱、作業系統、故障時間、目前模式、是否啟用 TUN、重現操作、第一筆異常日誌、命中的策略，以及已測試的單一變數。版本號也很重要，因為欄位支援範圍、預設行為與錯誤文字會隨核心和用戶端更新而變化。

判讀日誌的核心不是收集越多錯誤行越好，而是建立執行順序：設定先被讀取，接著監聽連接埠，訂閱產生設定，DNS 提供目標，規則選擇策略，節點建立連線，TUN 決定更多應用程式流量是否進入核心。把每筆日誌放回這條鏈路，就能將模糊的「Clash 無法使用」收斂至具體欄位、連接埠、上游或網路介面。