Clash 執行日誌怎麼看？mihomo 常見錯誤訊息與逐步排查方法

先建立可重現的請求

排查 Clash 連線失敗時，先確認問題發生在哪一層：應用程式是否將請求交給用戶端、核心是否完成規則比對、節點位址能否解析，以及對外連線是否建立。FlClash 是用戶端，mihomo 是其採用的代理核心；介面錯誤、訂閱下載錯誤與核心轉送日誌不一定出現在同一處。

開啟用戶端的「日誌」頁面，記下目前時間、執行模式、策略群組選擇及失敗的目標。選單名稱可能因用戶端版本而異，請尋找「核心日誌」或「執行日誌」，不要只查看更新檢查紀錄。接著只重新整理一個頁面，或送出一次測試請求，避免背景應用程式的連線淹沒目標紀錄。

1. 確認目前使用的是 rule、global 還是 direct 模式。只有在規則模式下，才適合排查自訂分流規則。
2. 記下目前的混合連接埠。以下統一以 127.0.0.1:7890 為例，這並非所有用戶端的固定預設值。
3. 保留失敗時間前後約 10 秒的日誌，並記下瀏覽器顯示的錯誤訊息。
4. 每次只變更一項設定，再對同一個目標重試。不要同時切換節點、DNS 和 TUN。

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

這個指令會明確使用本機 HTTP 代理入口，連線逾時上限為 10 秒，總執行時間上限為 20 秒。在 Windows PowerShell 中，可將指令名稱寫成 curl.exe，避免舊環境中同名別名造成問題。即使目標回傳 403 或 405，也要先區分「收到 HTTP 回應」與「根本沒有建立連線」。此測試只能驗證代理入口，不代表 TUN 接管一定正常。

如何閱讀日誌等級與每行欄位

mihomo 的 log-level 支援 silent、error、warning、info、debug。通常先使用 info；需要更多解析與連線脈絡時，再暫時改為 debug。用戶端可能會覆寫訂閱中的欄位，因此應檢查最終生效的設定，而非只修改下載的 YAML。

log-level: info

以下是方便閱讀的結構示意，不保證與每個 mihomo 版本完全一致。圖形介面用戶端可能會將時間、等級和訊息拆成不同欄位。

time="2026-09-15T10:24:08+08:00" level=info msg="[TCP] 127.0.0.1:53124 --> example.com:443 match DomainSuffix(example.com) using 手動選擇[節點A]"

• time：用來對照同一次操作。先確認系統時區，不要直接混用不同裝置的時間。
• [TCP] 或 [UDP]：表示傳輸協定。網頁能正常開啟，不代表 UDP 遊戲或 QUIC 一定正常。
• 127.0.0.1:53124：連線來源與臨時來源連接埠。這裡的 53124 並非代理監聽連接埠。
• example.com:443：目標網域與連接埠。使用 TUN 時，也可能先看到目標 IP。
• match：命中的規則類型與內容；using：使用的策略與節點。

出現「命中規則並使用某個節點」的紀錄，表示已完成路由選擇，但不代表目標網站已成功回應。還需要查看相鄰的連線錯誤與實際請求結果。

dial 逾時：先確認正在連線的對象

i/o timeout 與 context deadline exceeded

這兩類訊息表示某項操作未能在指定時間內完成，但光看這幾個詞，無法斷定「節點失效」。先查看前面的操作對象：是 DNS 查詢、連到代理伺服器的 TCP 連線，還是透過代理連線到目標的過程。錯誤鏈中的 IP 可能屬於代理伺服器、DNS 伺服器或目標網站，排查方向各不相同。

dial tcp 203.0.113.10:443: i/o timeout

上述位址使用文件保留網段，僅用於說明格式。實際排查時，請將日誌中的位址與目前節點的 server、port 對照。如果位址對應代理伺服器，先確認本機網路能否連上該伺服器；如果是直連目標，則檢查規則為何選擇 DIRECT，以及本機網路能否連上該目標。

1. 使用同一個節點測試兩個不同目標。所有目標都失敗與只有單一網站失敗，應分開處理。
2. 維持規則和 DNS 不變，只更換節點。更換後恢復正常，問題較可能出在原節點或其連線路徑。
3. 維持節點不變，切換 Wi-Fi 與行動網路。若只有某個網路失敗，再檢查網路限制、路由與 IPv6 是否可連線。
4. 若只有 UDP 請求失敗，請確認節點協定及伺服器是否支援 UDP 轉送，不要以 TCP 延遲測試結果代替 UDP 驗證。

connection refused 與 network is unreachable

connection refused 通常表示連線遭到主動拒絕，例如連接埠沒有服務監聽，也可能是防火牆主動拒絕。如果目標是 127.0.0.1:7890，先確認核心是否已啟動、實際連接埠是否變更；如果目標是遠端節點，則核對節點位址與連接埠。這和「等待直到逾時」是不同的狀況。

network is unreachable 通常與本機路由或位址族問題有關。例如日誌嘗試連線到 IPv6 位址，但目前網路沒有可用的 IPv6 路由。應先檢查路由與網路環境，再考慮調整 IPv6 相關設定。不要只因一次錯誤就全面停用 IPv6。

DNS 解析失敗：分辨節點網域與連線目標網域

看到 no such host、DNS resolve failed，或帶有 DNS 查詢脈絡的逾時訊息時，先確認正在查詢哪個網域。代理伺服器使用網域名稱時，必須先解析該名稱，才能建立代理連線；網站網域則可能由本機 DNS、mihomo DNS 或代理連線處理，視入口與設定而定。

no such host 常見於名稱不存在等解析失敗情況，但仍須搭配上游回應確認。逾時代表未能及時取得結果，不能據此認定網域不存在。nslookup example.com 通常測試系統設定的 DNS，並不會自動測試 mihomo 的 DNS。只有指定實際 DNS 監聽位址與連接埠的工具，或核心本身的日誌，才適合用來驗證核心解析路徑。

在 Fake-IP 模式下，應用程式可能會收到 198.18.0.0/16 範圍內的合成位址；這個範圍常見於相關設定，但仍應以實際的 fake-ip-range 為準。看到這類位址，不應立刻判定為 DNS 污染。請檢查網域對應、連線接管，以及 fake-ip-filter 是否符合目前應用程式的需求。

不要為了消除日誌中的合成位址，就將所有網域加入 fake-ip-filter。這會改變解析路徑，卻無法直接修復節點無法連線、上游逾時或 TUN 接管異常。

規則未命中：通常不代表發生錯誤

「規則未命中」通常是使用者對分流結果的描述，不一定有對應的錯誤日誌。mihomo 會依序比對規則，前面的規則一旦比對成功，就不會繼續處理後面的規則。末尾的 MATCH 是兜底規則，命中它屬於正常路由行為，不代表核心解析規則失敗。

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,PROXY

這是規則順序的片段，不是可直接執行的完整設定；PROXY 必須是已存在的策略群組或對外連線名稱。此片段會讓 example.com 及其子網域直連，其餘請求則交由 PROXY 處理。如果日誌顯示某個請求命中了其他較前面的規則，應調整規則順序，而非反覆更換 DNS。

• 先確認模式：global 和 direct 模式不會依一般規則清單進行預期中的分流。
• 再看連線資訊：只有目標 IP、沒有網域名稱時，網域規則可能無法如預期比對。請確認應用程式是否已先行解析、Fake-IP 對應是否存在，以及是否需要啟用適用的嗅探設定。
• 檢查規則來源：使用 RULE-SET 時，請確認對應的 rule-providers 是否載入成功，並檢查格式、路徑及更新是否有錯誤。
• 檢查實際生效的內容：訂閱更新、覆寫與用戶端設定合併，都可能改變規則順序。請以執行中的設定為準。
• 最後檢查策略群組：命中代理策略群組後，群組內仍可能選到 DIRECT。群組名稱有「代理」不代表最後一定會經過遠端節點。

如果連線紀錄中完全沒有出現該請求，先確認流量入口。某些應用程式不遵循系統代理，必須另外設定代理或使用 TUN；有些請求也可能沿用既有連線。先關閉該應用程式，再重新送出請求，比連續重新整理舊連線更容易判斷問題。

連接埠占用與 TUN 啟動失敗

address already in use：檢查監聽程序

常見訊息為 listen tcp 127.0.0.1:7890: bind: address already in use。這表示監聽位址與連接埠發生衝突，並非遠端節點錯誤。常見原因包括另一個代理用戶端仍在背景執行，或同一個核心啟動了兩份。也要確認發生衝突的是混合連接埠、DNS 監聽連接埠，還是控制介面連接埠。

# Windows：查詢 7890 連接埠，重點查看 LISTENING 列及其 PID
netstat -ano | findstr :7890

# macOS：查看監聽 TCP 7890 的程序
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux：查看監聽 TCP 7890 的程序
ss -ltnp 'sport = :7890'

確認程序身分後，請透過對應應用程式正常結束程序，或調整監聽連接埠。不要直接終止不熟悉的系統程序。如果將 mixed-port 從 7890 改為 7891，也要同步更新瀏覽器擴充功能、命令列環境變數，以及手動填寫代理位址的應用程式。在 Linux 上查看其他使用者的程序資訊時，可能需要額外權限。

TUN 權限與路由問題：先確認啟動階段

TUN 需要虛擬網路裝置與系統權限。出現 operation not permitted、建立裝置失敗或新增路由失敗時，應檢查用戶端的服務模式、系統授權及虛擬網卡狀態，而不是先調整訂閱節點。Windows 通常涉及管理員權限或已安裝的服務；macOS、Linux 的授權方式則視用戶端實作而定。

若 TUN 已成功啟動，但目標請求沒有進入核心，請檢查 tun.auto-route、路由排除項，以及其他 VPN 和安全軟體的影響。先退出其他會修改路由的用戶端，再重新測試。不要為了排查而長期關閉系統防火牆；若要確認是否遭到攔截，應針對特定程式、介面和連接埠檢查規則。

TLS 與驗證錯誤：連線建立後還要核對參數

如果日誌已進入 TLS 交握階段，卻出現 x509: certificate has expired or is not yet valid，先確認系統日期、時間與時區，再檢查憑證有效期限。若出現憑證名稱不符，請核對節點的 servername 或該協定對應的 SNI 設定、伺服器網域及伺服器憑證。

EOF、connection reset by peer 和 TLS handshake timeout 的成因並不單一。可能是遠端主動中斷、傳輸參數不一致、中間網路干擾，或交握未完成。需要配合協定、節點連接埠及發生階段判斷，不能把所有 EOF 都視為密碼錯誤。

• 確認協定類型、連接埠、密碼或 UUID，以及傳輸層參數是否與伺服器設定一致。
• 使用 WebSocket 等傳輸方式時，請檢查路徑與 Host 參數；參數名稱以目前的協定設定為準。
• 出現明確的驗證失敗訊息時，優先重新確認憑證資料及訂閱狀態。
• 不要把 skip-cert-verify: true 當成通用修正方法。略過憑證驗證會降低連線身分驗證能力，也無法修復連接埠或協定錯誤。

依固定順序縮小問題範圍，並保留重測結果

一段日誌可能同時包含多個應用程式、多個節點及多次重試。最終判斷應以一個可重現的請求為依據，而不是整個畫面中最醒目的紅色文字。依照以下順序處理，可減少在不相關的設定間反覆切換。

1. 啟動層：確認設定是否載入成功、監聽連接埠與 TUN 是否啟動。啟動失敗時，先處理語法、連接埠和權限問題。
2. 入口層：確認明確指定的代理請求能否進入核心。若明確代理測試成功，但原應用程式仍失敗，接著檢查系統代理、應用程式代理或 TUN。
3. 路由層：查看目標、命中規則、策略群組與最終節點，確認請求的路由符合預期。
4. 解析層：確認解析失敗的是節點網域、DNS 服務網域還是連線目標網域，再檢查對應的解析路徑。
5. 連線層：區分逾時、拒絕、無路由、TLS 與驗證失敗，每次只修改一項相關變數。
6. 應用程式層：收到 HTTP 回應後，再排查網站狀態、登入狀態與應用程式協定，不要再把所有失敗都歸因於代理連線。

向維護者回報時，請附上用戶端版本、核心版本、作業系統、觸發步驟、執行模式、相關設定片段，以及同一次請求的日誌。公開前請移除訂閱連結、存取權杖、密碼、UUID 及私人網域；保留錯誤關鍵字、欄位名稱、連接埠關係與時間順序。若替換位址，請在不同日誌行中以相同代稱表示同一個對象。

問題排除後，使用相同入口與相同目標再測試一次，並記錄是哪項變更讓問題恢復正常。最後將暫時開啟的 debug 恢復為日常等級。需要確認設定欄位的意義，可繼續參閱設定欄位參考；首次設定代理入口與 TUN，則可依照入門指南逐項確認。