Clash 執行日誌怎麼看：log-level 等級與常見錯誤訊息對照

先確認失敗階段，再看日誌等級

閱讀 Clash 日誌時，依序確認「連線是否進入核心 → 命中哪條規則 → 使用哪個策略 → 在哪個階段失敗」。warning 代表事件等級，不表示整個用戶端無法使用；單一 i/o timeout 也不足以證明節點失效。先比對同一筆請求的時間、目標位址、策略與錯誤訊息，才能判斷該檢查本機連接埠、DNS，還是代理伺服器。

# 合併至目前生效設定的頂層，不要重複新增同名欄位
log-level: info

本文討論範圍涵蓋 Clash 常見設定，以及 Clash Meta（mihomo）核心。不同核心和用戶端可能調整日誌格式、欄位名稱與中文提示；下方範例用於說明欄位關係，並非所有版本都會逐字輸出相同文字。排查前請記下用戶端版本、核心名稱與核心版本，不要只記錄桌面應用程式的版本號。

如何選擇 log-level 等級

log-level 是 YAML 頂層欄位，不可放在 dns 或 proxy-groups 底下。常見值為 silent、error、warning、info、debug；其中應使用 warning，而非 warn。日誌顯示的 WARN 是輸出標籤，不代表設定也接受相同拼法。

修改後為什麼日誌沒有增加？

• 確認修改的是目前啟用的 Profile，而非尚未切換的另一份設定。
• 檢查用戶端是否透過執行設定或覆寫功能，將 log-level 改回其他值。判斷時應以最終生效的設定為準，而非訂閱原文。
• 依用戶端提供的方式重新載入設定；若用戶端支援執行時修改，可直接透過設定調整，不必一再重新啟動系統。
• 清除日誌檢視器中的關鍵字與等級篩選，再發出一筆新請求。切換至 debug 不會自動替舊記錄補上細節。

如果設定載入失敗，請查看啟動日誌或用戶端的核心輸出。此時「日誌清單空白」可能表示核心尚未啟動，不應繼續從代理規則著手排查。

連線日誌要看哪些欄位

先看連線路徑，再看最後的錯誤訊息。以下是結構化說明範例：來源位址是本機臨時連接埠，目標是網站的 HTTPS 連接埠，Proxy 則是範例策略組名稱。

[TCP] 127.0.0.1:53124 --> www.example.com:443
match DomainSuffix(example.com) using Proxy[節點A]

[TCP] dial Proxy (match DomainSuffix/example.com)
127.0.0.1:53124 --> www.example.com:443
error: dial tcp 192.0.2.10:443: i/o timeout

這裡的 192.0.2.10 是文件範例位址，並非可用節點。實際日誌中的撥號位址可能是代理伺服器、直連目標或解析器；不能只看最後一個 IP 就判定網站故障。應配合目前的出站策略與完整錯誤上下文，確認核心正在連線至哪個對象。

1. 時間：確認是否與手動測試時間一致，或是背景應用程式先前留下的連線。
2. 網路類型：TCP 與 UDP 不可混為一談。網頁能正常開啟，不代表遊戲或其他 UDP 應用程式也正常。
3. 目標：確認目標是網域名稱還是 IP，以及連接埠是否符合預期，例如 HTTPS 常用 443。
4. 規則與出站：確認命中哪條規則、進入哪個群組，以及群組最後選擇的節點、DIRECT 或 REJECT。
5. 錯誤階段：確認問題發生在解析、TCP 建立連線、代理交握，還是後續讀取或寫入階段。

dial tcp 與 i/o timeout 分別代表什麼

dial tcp 表示正在發起 TCP 連線，本身並非錯誤原因。後續的 i/o timeout、connection refused 或 network is unreachable 才能指出可能的故障方向。代理協定交握、TLS 協商與應用程式請求分屬不同階段，不能以一次 TCP 連線成功就判定整條連線正常。

所有節點逾時與單一目標逾時，應分開排查

多台不同伺服器同時發生撥號逾時時，優先檢查本機網路、路由、防火牆，以及訂閱網址是否仍有效；若只有一個節點失敗，先確認該節點的伺服器位址、連接埠與服務狀態。同一節點能連上其他網站、只有一個網域失敗時，再檢查目標網站、目標解析結果與分流結果。延遲測試通常只會連線至特定測試位址，測試成功不代表所有網站都能存取。

如何區分 DNS、TLS 與連接埠錯誤

解析失敗：先確認是節點網域還是目標網域

lookup … no such host 表示網域名稱解析失敗；DNS … timeout 則表示解析請求未能及時完成。先確認解析失敗的是節點伺服器、訂閱伺服器，還是要存取的網站。節點網域解析失敗時，代理連線可能根本尚未建立，盲目更換網站規則並無幫助。

系統的 nslookup 結果不一定與 mihomo 內部 DNS 的解析結果相同，尤其是在啟用 Fake-IP、DNS 劫持或分流解析時。可將系統解析結果作為對照，但也要一併查看目前生效的 dns 設定。mihomo 的 proxy-server-nameserver 用於解析代理節點網域，排查時應確認適用版本與實際設定，不要直接套用至不支援此欄位的舊版核心。

TLS 錯誤：檢查憑證、系統時間與協定參數

x509 相關錯誤通常與憑證信任、有效期限或名稱不符有關。先檢查系統日期，再確認節點的 TLS 開關、伺服器名稱與伺服器端要求。tls handshake timeout 表示 TLS 交握未能及時完成，不代表一定是憑證錯誤；若請求仍在交握階段，就還不能歸類為網站回傳 HTTP 錯誤。

監聽失敗：先恢復本機連線入口

bind: address already in use 通常表示本機監聽位址與連接埠已被占用。例如 HTTP 與 SOCKS 合併監聽在 7890，但另一個用戶端也占用了該連接埠，核心入口就可能無法正常建立。請停止衝突的程序，或變更連接埠，並同步更新系統代理、瀏覽器與終端機設定。

# 本機入口範例；7890 僅為範例連接埠，並非所有用戶端的預設值
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

這只是欄位片段，不包含節點或完整規則。修改前先確認原設定是否已有 mixed-port，避免重複設定同一個鍵。若只需供本機存取，請保留 allow-lan: false；不必為了解決本機連接埠衝突而開放區域網路監聽。

規則未命中：檢查順序、模式與最終策略

「規則未命中」通常是排查時的描述，並非所有版本通用的錯誤訊息。連線命中兜底規則、進入非預期策略，或根本沒有進入核心，都可能被使用者歸為這類狀況。規則會依 rules 的順序由上而下比對；前面的寬泛規則可能會先攔截連線。

# 範例片段：網域規則置於前方，兜底規則置於後方
# Proxy 必須是完整設定中已存在的策略組或代理名稱
mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - MATCH,DIRECT

• 先確認模式：global 使用全域策略，direct 使用直連；不能用這兩種模式驗證 rule 模式下的規則順序。
• 再確認目標資訊：應用程式可能直接連線至 IP。能否還原網域名稱，取決於 DNS 對應、流量嗅探與實際流量；不能假設每筆 IP 連線都會命中網域規則。
• 確認兜底規則：命中 MATCH,DIRECT 代表規則正常執行，只是結果可能與預期不同；應修正前面的具體規則。
• 確認群組內的選擇：日誌顯示已進入 Proxy，不代表一定經過代理。如果該群組目前選擇了 DIRECT，最終仍會直連。
• 確認更新是否覆蓋設定：更新訂閱可能取代手動編輯的內容。若要長期保留規則，請使用用戶端支援的合併或覆寫機制，並檢查產生的結果。

如果目前流量完全沒有對應日誌，應先檢查連線入口。系統代理只會影響遵循該設定的應用程式；終端機、遊戲或自行設定代理的瀏覽器可能使用其他連線路徑。TUN 能承接更多 IP 流量，但仍受權限、路由、排除項目與 DNS 設定影響；啟用 TUN 並不足以證明所有流量都已進入核心。欄位說明請參閱設定欄位說明。

可重現的日誌排查流程

有效的排查方式，應讓每次修改都有新證據可供對照。以下流程以本機 HTTP 代理入口 127.0.0.1:7890 為例；若目前設定使用其他連接埠，也要同步修改命令。

1. 記下目前的 Profile、核心版本、代理模式、選取的節點與本機監聽連接埠；將日誌等級設為 info。
2. 關閉無關的下載與測速工作，記下目前時間。每次只測試一個目標，避免將背景連線誤認為測試結果。
3. 使用下方的明確代理命令進行測試，讓請求不受系統代理設定影響。Windows PowerShell 可使用 curl.exe，避免舊版環境中同名別名造成差異。
4. 在相同時段找到對應連線，確認規則與出站，再查看最後的錯誤訊息。若沒有日誌，先檢查監聽入口與檢視器篩選條件。
5. 資訊不足時切換為 debug，並重複相同請求。每輪只變更一個條件，例如只切換節點，不要同時修改 DNS、規則與 TUN。
6. 確認問題已排除後，將等級改回 info，並記錄故障原因與最終生效欄位，不要長期保留大量除錯輸出。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 15 --verbose https://example.com/ --output /dev/null

在 Windows 使用 curl.exe 時，可將輸出目標 /dev/null 替換為 NUL。此處的 10 秒是 curl 連線階段的上限，15 秒是整筆請求的上限，不會直接變更核心內部逾時設定。命令中的 --verbose 會顯示代理連線與 TLS 過程；HTTPS 經由 HTTP 代理時，即使 CONNECT 成功，也只表示通道已建立，仍需繼續檢查後續交握與回應。

分享日誌前：哪些內容要保留、哪些要隱藏

尋求協助時，請提供故障發生時間、用戶端與核心版本、相關模式、目標連接埠、規則結果，以及請求前後連續的日誌。通常保留同一次重現前後約 10～30 行，比只截取最後一句 timeout 更容易定位問題。設定片段請保留階層與欄位名稱，但移除可用來存取服務的憑證。

• 隱藏完整訂閱網址及其查詢參數、節點密碼、UUID、存取權杖，以及控制介面的 secret。
• 視需要隱藏真實網域、區域網路位址與節點位址，但同一個對象請使用一致的替代名稱，以免失去前後關聯。
• 保留錯誤類型、目標連接埠、TCP/UDP 類型與規則順序；這些資訊會直接影響判斷結果。
• 不要預設上傳完整訂閱檔案來尋求協助。節點數量再多，也無法彌補缺少重現步驟的問題。

最後的判斷應能指出具體層級：請求未進入本機入口、規則選擇不符、節點撥號失敗、協定交握失敗，或目標回傳異常。先分類再修改，比反覆重裝用戶端或一次重設所有設定，更能保留有效線索。