一、先把日誌打開：三個入口
做法先講。不管用的是哪一款客戶端，日誌都來自同一個地方——核心。圖形介面只是訂閱了核心的輸出，所以各客戶端看到的錯誤文字其實是同一份；學會讀文字，等於通了所有客戶端。入口依使用方式分三類：
- 圖形客戶端的日誌頁。Clash Verge Rev 左側導覽有「日誌」一項，點進去就是即時滾動的核心日誌，上方可依等級篩選；Clash for Windows 對應「Logs」板塊，同樣支援依等級過濾。
- 核心設定裡的 log-level。直接執行 mihomo 核心時，日誌會輸出到終端機，詳細程度由設定檔裡的
log-level欄位控制，可選silent、error、warning、info、debug五檔，預設info。 - 外部控制介面。核心開啟
external-controller（常見位址127.0.0.1:9090）後，/logs?level=info介面會持續推送日誌串流，圖形客戶端的日誌頁走的就是這條通道。
注意：在介面上切換篩選等級，只會改變「顯示哪些」，不會改變核心實際記錄的內容。想讓核心記錄更細的日誌，要改 log-level 並重新啟動核心或重新載入設定才會生效。
二、一行日誌裡有什麼：時間、等級、連線
先看一條典型的 info 等級運行日誌（各客戶端顯示格式略有差異，要素相同）：
2026-06-19 21:03:11 INFO [TCP] 127.0.0.1:52341 --> www.example.com:443 match DomainSuffix(example.com) using 香港節點把它拆成四段：
- 時間
2026-06-19 21:03:11：排查時先用它對齊你動作發生的時刻，動作之前的日誌與這次問題無關； - 等級
INFO：由低到高依序是 debug、info、warning、error，等級愈高愈值得停下來檢視； - 連線
[TCP] 127.0.0.1:52341 --> www.example.com:443：左邊是本機來源位址與臨時埠，右邊是存取目標與埠； - 結果
match DomainSuffix(example.com) using 香港節點：這條連線命中了哪一條規則、被交給哪個出口——出口可以是節點、DIRECT（直連）或 REJECT（拒絕）。
再說說為什麼會長這樣。Clash 的運作模型是「來一條連線、查一次規則表、交給一個出口」，所以運行期的日誌幾乎都是這種句式。讀日誌的本質就是核對三件事：目標對不對、規則命中對不對、出口對不對。三件事都對卻仍不通，問題才輪到節點與線路。
三、五類常見錯誤逐條說明
1. 連線逾時：i/o timeout
2026-06-19 21:04:02 WARN [TCP] dial 香港節點 127.0.0.1:52341 --> www.google.com:443 error: dial tcp 203.0.113.8:443: i/o timeout含義：核心向節點伺服器發起連線，直到逾時仍沒有收到回應。context deadline exceeded 是另一種寫法，含義相同。排查請依「節點 → 線路 → 本機」的順序：
- 在節點列表做延遲測試：全部逾時，多半是訂閱過期或本地斷網；單個逾時，則是該節點本身的問題；
- 換一個節點存取同一目標，能通即可確認原節點失效；
- 所有節點都不通時，讓同一目標改走 DIRECT 試一次，直連也不通就是本機網路本身出了故障。
原因：timeout 只說明「沒等到回應」，並不區分節點掛掉、線路被干擾還是本地斷網，所以必須逐層排除，不能一看到逾時就急著換客戶端。
2. 訂閱與設定解析失敗
2026-06-19 21:05:40 ERROR configuration file error: yaml: unmarshal errors: line 86: cannot unmarshal !!str into map[string]interface {}含義：設定檔第 86 行附近的 YAML 結構不對，核心拒絕啟動。常見誘因有三種：手動編輯後縮排錯亂；訂閱連結回傳的不是 YAML，而是一段網頁錯誤訊息；設定裡混入了目前核心不認得的欄位。另一種常見形態：
2026-06-19 21:05:41 ERROR proxy 3: unsupport proxy type: hysteria含義：第四個節點（序號從 0 開始算）使用了核心不支援的協定。原版 Clash 核心不認得 hysteria、tuic 等新協定，需要換用 mihomo（Clash Meta）核心的客戶端，客戶端對比頁有各家的核心說明。
排查順序：錯誤訊息若給了行號就定位到行號，若給了節點序號就數到該節點；訂閱匯入失敗時，把訂閱連結貼到瀏覽器打開——回傳亂碼或錯誤頁，說明訂閱本身有問題；能回傳一大段文字，說明問題出在客戶端的解析環節。
3. 埠被佔用：bind error
2026-06-19 21:06:15 ERROR start mixed(http+socks) proxy error: listen tcp 127.0.0.1:7890: bind: address already in use含義：核心要監聽的 7890 埠已被別的處理程序佔用，代理服務起不來。Windows 上同一錯誤寫作「Only one usage of each socket address is normally permitted」。排查順序：
- 最常見的原因是上一個 Clash 實例沒退乾淨。打開工作管理員，找出殘留的 clash、mihomo、clash-verge 處理程序，結束後再啟動；
- 確認埠是被無關程式佔用時，改客戶端設定裡的混合埠（例如從 7890 換成 7897），儲存並重新啟動核心。
原因：監聽埠是獨占資源，同一時刻只能歸一個處理程序使用。這類錯誤的解法永遠是兩步——先找到佔用者，再決定結束它，還是自己換埠。
4. DNS 解析失敗
2026-06-19 21:07:33 WARN [TCP] dial DIRECT 127.0.0.1:52410 --> api.example.com:443 error: dns resolve failed: couldn't find ip含義：核心解析不出目標網域的 IP，連線在查位址這一步就卡住了。先檢查客戶端的 DNS 設定是否被改亂，恢復預設值再試；再確認系統本身能否正常解析（不開代理時瀏覽器能否上網）。使用 fake-ip 模式時這類錯誤較少出現；若頻繁出現，可在 DNS 設定裡加入 223.5.5.5、119.29.29.29 等公共 DNS 作為預設解析器。
5. TUN 模式啟動失敗
2026-06-19 21:08:20 ERROR start TUN listening error: create tun: permission denied含義：TUN 模式需要建立虛擬網卡，這一步需要管理員權限。Windows 上請以「用管理員身分執行」啟動客戶端；macOS 與 Linux 依客戶端提示完成授權。授權後仍失敗，再檢查是否與其他 VPN、加速器類軟體衝突——兩張虛擬網卡同時接管路由會互相干擾，先退出另一個再試。TUN 模式的完整設定步驟在使用指南裡有獨立一節，相關術語可在名詞解釋裡查詢。
四、定位問題的固定順序
把前面的零散重點整理成一條流程。遇到任何異常，依這五步走：
- 重現問題的同時盯著日誌把篩選等級調到 warning 以上，先看有沒有 error 行。
- 分清階段啟動期錯誤（設定解析、埠被佔用、TUN 建立）會在打開客戶端的瞬間出現；運行期錯誤（逾時、DNS、交握失敗）則在存取網頁時才出現。
- 啟動期依文字逐字處理錯誤訊息指哪一行就查哪一行，不要憑印象亂猜。
- 運行期先分節點與本地做延遲測試區分節點與本地網路，再用
match ... using ...核對規則命中是否符合預期——台灣網站被送進節點，多半是規則或 GeoIP 資料的問題，與節點本身無關。 - 資訊不足再開 debug目前等級看不出原因時，暫時切到 debug 重現一次，取得細節後再調回 info。
原因：日誌依時間排列，而故障有明確的階段屬性。先定階段、再查文字，比在幾千行滾動日誌裡撈關鍵字快得多。
五、debug 等級的用法與分寸
做法：在日誌頁把等級切到 debug，或在設定裡寫 log-level: debug 後重新載入核心，然後完整重現一次問題，截取從動作開始到錯誤出現之間的段落。分寸有三點：
- debug 會印出每條連線的比對細節，滾動極快，長期開著會拖慢介面、寫出很大的日誌檔案；
- 日誌裡含有你曾造訪過的網域，截圖發到群組或論壇求助前，先把敏感網域遮住；
- 問題解決後記得調回 info，讓日誌保持「平時安靜、有事才出聲」，下次排查才有可讀性。
說到這裡，讀日誌這件事就講完了：入口三個、句式一種、錯誤五類、流程五步。下次客戶端卡在轉圈、網頁打不開時，先別急著重裝——打開日誌，從最近一行 error 看起。