先保留現場：記下日誌時間、連線目標與實際使用的核心

Clash 顯示「已連線」，通常只表示核心正在執行，或本機代理入口已啟用，不代表每個網站都能成功連線。排查時應沿著請求路徑逐步確認：應用程式是否使用代理、網域是否解析成功、規則選擇了哪個策略、節點是否連線成功，以及遠端是否有回應。

Clash、Clash Meta（目前通常以 mihomo 核心維護）及不同圖形用戶端的日誌格式不盡相同。以下欄位與錯誤片段僅供示意，並非任何特定版本的固定輸出。請先在用戶端的「關於」或核心資訊頁面記下核心名稱與版本，再依照該核心的設定說明排查；只記錄外層用戶端版本並不足夠。

  1. 記下重現時間：精確到秒，例如 14:32:10。清除日誌畫面前，先保存重要錯誤訊息。
  2. 縮小請求範圍：暫停下載和背景更新，只開啟一個有問題的網址，避免數十條並行連線混在一起。
  3. 記下環境資訊：作業系統、用戶端與核心版本、規則或全域模式、系統代理與 TUN 開關、目前的策略組及節點。
  4. 每次只變更一項：每次修改後重新發出請求，比較同一目標的結果；不要同時更換 DNS、節點和規則。

日誌層級設定：平時使用 info，重現問題時短暫切換為 debug

在用戶端側邊欄的「日誌」或「執行日誌」頁面查看輸出。日誌層級設定的位置會因用戶端而異，可能在設定或核心設定中。介面上的日誌篩選不一定等於調整核心輸出層級：只篩選「除錯」無法找回核心未產生的記錄。

Clash 和 mihomo 常用的頂層設定欄位為 log-level，支援 silent、error、warning、info、debug。以下為設定片段，需合併至目前的設定中，並非可獨立使用的訂閱：

# 頂層欄位，與 mode、rules 同層
log-level: debug

儲存後依照用戶端要求重新載入設定或重啟核心，並確認新設定已生效。更新訂閱可能會覆寫手動編輯的內容；若用戶端支援設定覆寫或合併，請優先使用該機制。重現問題後，請改回 info，避免長期產生大量除錯日誌。

讀懂連線記錄：先看目標，再看規則與出站路徑

一筆記錄可能同時包含來源位址、目標網域、命中規則、策略組、最終節點和錯誤原因。閱讀順序很重要：錯誤前的 DIRECT 或代理節點名稱，會影響接下來應檢查哪一段連線路徑。

# 欄位示意，並非固定的日誌格式
[TCP] 127.0.0.1:53124 --> example.com:443
match DomainSuffix(example.com)
using Proxy[節點 A]
error: dial tcp 203.0.113.10:443: i/o timeout

這裡的 53124 是應用程式這次連線使用的暫時來源連接埠，不是系統代理的監聽連接埠。example.com:443 是請求目標，Proxy 是策略名稱。範例中的文件保留位址 203.0.113.10 僅供說明，不能用來測試連線。

記錄線索優先確認的事項對應設定或入口
完全沒有新的連線請求是否進入本機代理系統代理、mixed-port、TUN、應用程式設定
目標網域解析失敗哪個解析環節發生問題dns、節點網域解析、系統解析器
命中 DIRECT分流結果是否符合預期mode、rules、規則集
透過代理連線後逾時無法連上節點入口，還是最終目標proxies、proxy-groups、節點服務狀態
監聽連接埠啟動失敗連接埠是否已被占用mixed-port、port、socks-port、控制連接埠

dial timeout：分辨節點入口逾時與目標連線逾時

dial timeout、i/o timeout 或 context deadline exceeded 都表示某項操作未能在期限內完成，但不能只憑「逾時」就判定是 DNS 出錯。請先查看同一行的位址及前後日誌：如果失敗的位址是節點伺服器，優先檢查本機到節點的連線路徑；如果是直連目標，則檢查直連路徑與分流設定是否正確。

用四個步驟縮小問題範圍

  1. 在策略組中手動選擇另一個節點，再次發出相同請求。若另一個節點成功，問題較可能出在原節點或其線路，但這還不足以證明是協定本身有問題。
  2. 改用另一個目標網站。如果只有單一目標連不上，請檢查目標網站狀態、出口地區限制，以及節點到目標網站的連線路徑。
  3. 保持節點不變，只切換一次網路，例如從 Wi-Fi 改用手機熱點。若結果有所不同，請優先檢查本機網路、防火牆或電信業者的連線路徑。
  4. 比對節點設定中的伺服器位址、連接埠和協定參數。訂閱過期或伺服器端調整連接埠也會導致連線失敗；修改前請先更新訂閱並確認帳戶狀態。

延遲測試成功只表示當時能對測試目標完成相應探測，不代表串流影片、檔案下載和 UDP 都能正常使用。不要把測得的 80 ms 解讀成網頁一定能在 80 ms 內載入。

connection refused 與 timeout 並不相同

connection refused 通常表示收到主動拒絕，例如目標連接埠沒有服務監聽，或防火牆回覆拒絕連線。若位址是 127.0.0.1:7890，請先確認本機代理是否正在該連接埠監聽；若位址屬於節點伺服器，則核對節點連接埠與服務狀態。盲目延長逾時時間無法解決連接埠遭拒的問題。

DNS 解析失敗：區分請求網域、節點網域與上游解析器

no such host、lookup ... failed、DNS query timeout 等訊息表示問題出在解析環節，但還需要判斷是哪個對象解析失敗。連線至目標網域需要解析；代理伺服器使用網域名稱時也需要解析；若加密 DNS 上游設定為網域名稱，還需確認如何預先解析上游本身的位址。

Windows 可先執行 nslookup example.com；macOS 或 Linux 安裝相應工具後，可執行 dig example.com。這些命令通常檢查系統使用的解析路徑，不一定會經過 Clash 內建 DNS；系統解析與核心解析必須分別驗證。

Fake-IP 位址本身不是解析錯誤的直接證據

在 Fake-IP 模式下，應用程式取得合成位址可能是正常情況。常見設定會使用 198.18.0.0/16 範圍，這與真實網站的公網位址不同。應確認後續連線是否進入核心並還原網域對應，而不是一看到這個位址就更換節點。

若問題在切換 DNS 模式後出現，請先重新建立應用程式連線，必要時清除系統 DNS 快取。不要立刻將所有網域加入 fake-ip-filter；先用一個確實不相容的網域驗證，再進行最小幅度的調整。欄位說明請參閱 DNS 設定參考與 Fake-IP 說明。

規則未命中：檢查模式、順序與網域資訊

「沒有使用預期節點」不一定會產生錯誤日誌。請求可能正常命中較前面的直連規則，也可能正處於全域模式，根本沒有依照預期的規則清單分流。請先確認執行模式，再檢查連線記錄中的實際規則與策略。

# 分流片段；Proxy 必須是已存在的策略名稱
mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

規則會由上而下比對，命中後即停止。若將 MATCH,DIRECT 放在第一行，後面的網域規則就不會生效。範例中的 Proxy 不是內建保留名稱，必須與設定中現有的代理或策略組名稱完全一致。

  1. 確認規則模式：全域模式通常由全域策略決定出站方式；直連模式則會略過預期的代理策略。模式說明請參閱 代理模式設定。
  2. 確認目前使用的設定：檢查編輯的是否為目前正在使用的設定；訂閱更新後，自訂規則是否仍然保留。
  3. 確認規則集狀態：使用 RULE-SET 時，請檢查對應的提供者是否載入成功，以及名稱與內容格式是否符合宣告。
  4. 確認網域資訊：若應用程式直接連線至 IP，網域規則可能無法命中。嗅探可在部分情況下補充網域資訊，但不保證能還原所有連線的網域。
  5. 重新建立連線：現有的長連線可能仍沿用原本的出站方式。請關閉相關頁面或應用程式連線後再測試，避免將舊連線誤認為新規則的結果。

啟動與權限錯誤：連接埠占用、設定錯誤與 TUN

address already in use：先確認是哪個程序占用了連接埠

如果核心啟動時出現 bind: address already in use，請先確認遭占用的是代理連接埠、DNS 監聽連接埠，還是控制介面連接埠。以下命令以 7890 為例；實際連接埠請以目前設定為準，不同用戶端的預設值可能不同。

# Windows：查看監聽連接埠及程序編號
netstat -ano | findstr :7890

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

# Linux：查看 TCP 監聽通訊端
ss -ltnp 'sport = :7890'

確認程序身分後，關閉重複執行的用戶端，或變更本機監聽連接埠。若將 mixed-port 從 7890 改為 7891，也要同步更新系統代理與應用程式內的代理設定。不要只看到程序編號就直接終止不明的系統服務。

YAML 與策略參照錯誤：先確認設定能載入

yaml: line ... 通常表示語法或結構有問題。請使用空格縮排，不要使用 Tab；含有特殊字元的值應依 YAML 規則加上引號。錯誤行可能只是剖析器無法繼續的位置，實際錯誤也可能在上一行。策略不存在或規則集名稱拼錯屬於設定參照問題，重新啟動網路無法解決。

TUN permission denied：檢查系統授權與流量接管範圍

建立 TUN 失敗可能與管理員權限、用戶端服務模式或作業系統的 VPN 授權有關。Windows 通常需要檢查服務及提升權限的狀態；Android 則需確認已核准 VPN 連線要求。實際操作請依照用戶端說明進行。啟用 TUN 不代表所有流量都會自動進入代理；路由、排除項目和現有 VPN 都會影響接管結果。

若一般明確指定的代理可用，但 TUN 無法使用，請保留相同節點與設定，只切換流量接管方式進行比較。如此可將問題範圍縮小至虛擬介面、路由或 DNS 接管，而非同時懷疑訂閱與節點。

驗證修復結果：使用相同請求比較前後差異

日誌變少不代表故障已排除。修復後應使用相同目標、相同網路和相同節點再次測試，確認請求確實送至預期策略，並收到應用程式層級的回應。瀏覽器可能會快取頁面，最好重新發出請求；終端機可明確指定本機代理，避免環境變數造成干擾。

# 本機 mixed-port 為 7890 時的 HTTP 代理測試
# Windows 可使用 curl.exe
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

# mixed-port 或 SOCKS 入口為 7890 時的 SOCKS 測試
curl --proxy socks5h://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

socks5h 表示將網域交由 SOCKS 代理解析，適合用來與本機解析路徑比較。若測試收到 HTTP 403 等回應，代表已收到某個 HTTP 端點的回覆，但仍可能受到目標網站的策略限制；這與建立連線前就逾時是不同類型的問題。

若仍需回報問題，請整理一份精簡紀錄：作業系統與核心版本、重現步驟、發生時間、已遮蔽敏感資訊的日誌、相關設定片段，以及已進行的單項比較。相較於整頁截圖，這些資訊更容易將問題定位到 DNS、規則、監聽入口或節點連線的特定環節。