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

先重現一次請求，再篩選相關日誌

Clash 頁面無法開啟，不一定是節點失效。請求可能根本沒有進入核心，也可能卡在 DNS 解析、規則選擇、代理交握或目標伺服器回應階段。排查時應找出最後一個成功的步驟，而不是看到一則紅色訊息就更換整份設定。

本文也適用於原版 Clash 與 Clash Meta（現稱 mihomo）的常見日誌。不同核心、版本和用戶端可能會調整欄位與顯示方式；範例用於說明結構，不代表每個版本都會輸出相同文字。請先在用戶端的「關於」或核心資訊頁記下用戶端版本、核心名稱與版本，再進行比對；用戶端版本號不能取代核心版本號。

1. 保留目前設定的副本，並記下系統代理、TUN、運作模式與目前選取的策略群組。
2. 開啟用戶端的「日誌」頁面。各用戶端的選單名稱可能不同；找不到時，請先查閱該用戶端的使用說明。
3. 暫停其他下載工作，記下目前時間，只開啟一個能穩定重現問題的網址。
4. 保留這次請求前後約 10 秒的日誌，依目標網域、目標連接埠或來源連線連接埠篩選。

日誌層級與欄位：先看命中的規則，再看失敗位置

設定中的 log-level 用來控制日誌詳細程度。日常使用可維持 info；重現難以定位的問題時，可暫時改為 debug。修改後請套用設定，排查完成再還原，避免大量除錯資訊掩蓋關鍵錯誤。

log-level: info

設定值為 warning，介面卻可能顯示 WARN；不要把顯示用的縮寫直接當成設定值。日誌層級也不代表故障影響範圍：一則警告可能只是頁面內的統計請求所產生，而策略選錯的連線仍可能顯示為一般資訊。

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

• time：事件時間。比對不同裝置前，先確認時區與系統時間。
• [TCP]：連線協定；UDP 請求應另外觀察，不能只靠 TCP 測試下結論。
• 127.0.0.1:53124：來源位址與臨時連接埠，不是代理監聽連接埠。
• www.example.com:443：目標主機與連接埠。HTTPS 通常使用 443，但並非所有應用程式都採用預設連接埠。
• match：本次命中的規則；using 後方通常會顯示策略群組及實際選用的出站。

日誌中的 using 表示已選取某個出站，不代表連線已成功，更不代表網頁已完整載入。請繼續查看同一目標、相近時間是否出現撥號失敗、交握錯誤或連線關閉。

連線逾時：區分代理伺服器與目標伺服器

i/o timeout、context deadline exceeded 或包含 timeout 的撥號錯誤，都表示某個步驟超過等待時間。只看「逾時」兩字，無法判斷問題出在本機網路、節點線路還是目標網站。

依錯誤中的位址判斷卡在哪一段

1. 連線代理伺服器逾時：查看錯誤是否指向節點設定中的伺服器位址與連接埠。若是，請優先檢查節點是否可連線、本機網路與伺服器連接埠。
2. 直連目標逾時：日誌顯示使用 DIRECT，錯誤指向目標 IP 的 443 連接埠時，應先確認該規則是否預期要直連。
3. 交握或遠端讀取逾時：TCP 連線可能已建立，但後續協定互動尚未完成。請進一步核對節點協定、TLS 參數與伺服器狀態。

使用同一個 URL 進行比對，比開啟多個不同網站更有參考價值。以下指令適用於已設定 HTTP 混合連接埠 7890 的情況；Windows PowerShell 建議明確呼叫 curl.exe，macOS 與 Linux 則使用 curl。

curl -I --connect-timeout 5 --max-time 15 --proxy http://127.0.0.1:7890 https://example.com/
curl -I --connect-timeout 5 --max-time 15 --noproxy "*" https://example.com/

第一個指令明確透過本機代理連接埠，第二個則略過 curl 的代理設定。若 TUN 仍在接管路由，第二個指令的流量仍可能進入核心，因此必須在可控條件下暫時關閉 TUN，才能將它當作真正的直連對照。回應 403 或 405 仍屬於 HTTP 回應，不能直接視為網路連線失敗。

DNS 解析失敗：先確認由誰負責解析

no such host 表示解析未取得可用結果，但不一定是 DNS 伺服器故障；網域不存在、上游回覆否定結果或本機解析路徑異常，都可能出現類似狀況。特別留意 lookup 後方的網域：若是代理伺服器網域，問題發生在連線節點之前；若是目標網站網域，則需配合出站與 DNS 設定進一步判斷。

指定連接埠測試核心 DNS

假設目前啟用的設定確實包含以下 DNS 設定，可直接查詢核心監聽的 1053 連接埠。此處的上游位址僅供診斷參考，請依實際網路的可連線狀況選擇，不要覆蓋訂閱中的整段 DNS 設定。

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

# macOS / Linux，需已安裝 dig
dig @127.0.0.1 -p 1053 example.com A

# Windows，進入 nslookup 互動模式後依序輸入
nslookup
server 127.0.0.1
set port=1053
example.com
exit

• 查詢逾時：先確認核心已載入這份設定、1053 連接埠正在監聽，再檢查上游 DNS 是否可連線。
• 回覆 NXDOMAIN：檢查拼字，並以已知存在的網域進行比對；不要把不存在的網域當成網路故障。
• 回覆 Fake-IP：例如設定採用預設位址範圍時，出現 198.18.0.0/16 內的對應位址，這本身不代表解析失敗。
• 系統查詢正常、核心查詢異常：優先檢查核心 DNS 的上游與路由；反之，則檢查系統 DNS 是否確實指向預期的解析路徑。

一般執行 nslookup example.com 通常查詢的是系統設定的 DNS，無法直接證明核心 DNS 正常。若使用 DoH 或 DoT，也要考慮上游網域的引導解析、TLS 驗證與連線路徑。mihomo 的 DNS 擴充欄位並非全部適用於原版 Clash，新增前請確認目前核心支援的範圍。欄位說明請參閱DNS 設定參考。

連接埠占用與連線遭拒：先確認核心是否真的在監聽

bind: address already in use 通常出現在啟動或重新載入時，表示某個本機位址與連接埠無法再次繫結。常見原因包括兩個用戶端同時執行，或舊的核心程序尚未結束。請先確認錯誤涉及代理連接埠、DNS 連接埠還是控制介面，不要一次修改所有連接埠。

mixed-port: 7890
external-controller: 127.0.0.1:9090

上述設定中，7890 用於混合代理入站，9090 用於控制介面。控制介面不是 HTTP 代理入口；將瀏覽器代理指向 9090 不會得到預期結果。以下指令只會查詢程序，不會將其終止：

# Windows
netstat -ano | findstr :7890

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -lntp 'sport = :7890'

1. 確認連接埠對應的 PID 與程式名稱，並正常結束重複執行的用戶端。
2. 若改用 7891，請同步修改系統代理、瀏覽器擴充功能與命令列代理設定。
3. 重新啟動核心，確認沒有繫結錯誤，再使用指定的代理連接埠執行一次 curl 測試。

connection refused 與連接埠占用不同：它表示連線遭拒，常見原因是目標連接埠沒有服務在監聽。若遭拒位址是 127.0.0.1:7890，請優先檢查本機核心；若是節點伺服器位址，則檢查伺服器連接埠與服務狀態。不要為了排除本機連線問題，任意將監聽位址擴大到所有網路介面。

規則未命中：核對模式、順序與最終出站

Clash 的規則模式會依照 rules 由上而下比對，第一條命中的規則決定所用策略。清單中「有一條正確規則」，不代表它一定有機會執行。全域模式也不會依照同一組規則逐條選擇出站，因此排查前請先確認目前的運作模式。

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,手動選擇

此片段假設設定中已定義名為「手動選擇」的策略群組。開啟 www.example.com 時應命中第一條規則；其他未命中的請求則交由最後的 MATCH 處理。若將 MATCH 放在第一條，後續規則便沒有機會參與比對。

依四個檢查點逐步定位

• 確認實際載入的設定：訂閱來源檔案、本機編輯的檔案與用戶端正在使用的設定可能不同。請確認變更已套用，而不只是儲存在編輯器中。
• 確認網域是否可用：若應用程式直接連線至 IP，且核心沒有還原網域資訊，DOMAIN-SUFFIX 就不一定能命中。嗅探可能有幫助，但並非所有連線都能還原網域。
• 確認規則集狀態：使用 RULE-SET 時，先查看規則提供者是否已下載並成功解析，再核對引用名稱與比對順序。
• 確認策略群組的實際選擇：即使日誌顯示的群組名稱正確，若群組內選到 DIRECT 或其他節點，結果仍會與預期不同。

測試規則變更時，請建立新的連線。既有長連線可能繼續使用原本的出站，只重新整理頁面不一定會重建所有連線。可以先關閉測試中的應用程式再重新開啟，或確認影響範圍後關閉相關連線。完整欄位說明請參閱設定大全，訂閱更新流程請參閱訂閱使用說明。

TLS、驗證與 TUN 錯誤：不要混為同一種網路故障

TLS 錯誤應先區分是節點交握，還是目標網站交握。節點使用 TLS 時，伺服器位址、SNI 與憑證名稱必須符合伺服器設定；系統時間明顯不準也會導致驗證失敗。關閉憑證驗證會改變安全性，不應當作通用修復方式。

TUN 相關錯誤常出現在建立虛擬介面、設定路由或接管 DNS 的階段。Windows 請核對用戶端的服務模式及所需權限；Linux 請檢查 /dev/net/tun 是否存在，以及程序權限是否足夠；macOS 則應確認用戶端要求的系統授權。各用戶端的選項名稱可能不同，請勿照搬其他用戶端的選單路徑。

如果明確指定代理連接埠的 curl 測試成功，但啟用 TUN 後應用程式仍無法正常運作，排查重點應轉向路由、DNS 接管、其他 VPN 與安全軟體衝突，而非繼續更換節點。進一步設定請參閱TUN 設定參考。請注意，TUN 接管流量不代表所有流量都會經過代理，最終仍取決於運作模式與規則。

最後確認：使用相同請求驗證修復結果

修改後，使用一開始記錄的 URL 再測試一次。確認問題已解決時，應同時檢查應用程式結果與日誌路徑：頁面是否完整載入、是否命中預期規則、是否使用預期節點，以及同類錯誤是否仍反覆出現。節點延遲測試只顯示毫秒數，不能證明 DNS、目標網站與應用程式協定都正常。

1. 核心尚未啟動：先處理設定語法、連接埠與權限問題。
2. 日誌沒有請求：在 info 層級下重現問題，檢查系統代理、應用程式自訂代理與 TUN 接管範圍。
3. 出現解析錯誤：區分節點網域與目標網域，分別測試系統 DNS 和核心 DNS。
4. 出現連線錯誤：依錯誤位址區分本機入口、代理伺服器與目標伺服器。
5. 連線成功但路徑不符預期：檢查運作模式、規則順序、策略群組選擇與既有連線。
6. 問題已排除：恢復日常使用的日誌層級，並保留這次有效的變更與重現步驟。

一份有效的排查紀錄，應能回答「哪個請求、經過哪條規則、在哪個階段失敗」。依照這個順序縮小範圍，通常比批次替換設定更容易找出原因，也更方便在訂閱更新或用戶端升級後重新驗證。