先看時間軸，再找錯誤關鍵字
一次只重現一個請求，先找出最早出現的相關錯誤。「網頁無法開啟」可能是流量接管、網域解析、規則選擇、代理連線或目標網站回應出了問題。日誌最後一筆逾時，往往只是前面故障造成的結果；只搜尋 timeout 就換節點，很容易找錯問題根源。
Clash 泛指核心與用戶端生態系。舊版 Clash 核心、Clash Meta（現稱 mihomo）及不同桌面介面，日誌格式與可用欄位不盡相同。介面中的「日誌」頁面通常顯示核心執行輸出；用戶端本身的服務安裝、權限與更新錯誤，則可能另存在應用程式日誌中。核心尚未啟動時，沒有連線日誌並不奇怪。
- 記下問題發生的當地時間，例如
14:32:10，並記錄目標網域及使用的程式。 - 關閉無關的網頁、下載器及持續連線的軟體，減少背景流量。
- 開啟日誌頁面並清除介面上現有的記錄；這通常只會清除畫面顯示，不代表刪除磁碟上的日誌。
- 只重新整理一次目標頁面，保留前後約 10 秒的記錄。
- 依照「是否進入核心 → 解析 → 規則 → 出站 → 應用程式回應」的順序檢查。
日誌層級：平時使用 info，重現問題時使用 debug
先查看用戶端的「日誌」頁面。需要更多細節時，請在用戶端設定中尋找「日誌層級」或 Log Level。部分介面可直接調整核心執行層級；有些介面的篩選器則只會隱藏特定行，不會改變核心實際輸出的內容。切換後重新發送請求，確認是否出現新的除錯資訊。
| 層級 | 適用情境 | 閱讀重點 |
|---|---|---|
silent | 不適合用於排查 | 輸出遭到抑制，無法據此判斷是否有連線 |
error | 僅收集嚴重錯誤 | 例如啟動失敗等錯誤，通常缺少正常連線的前後文 |
warning | 觀察異常 | 連線失敗、逾時及相關警告 |
info | 日常檢查 | 連線目標、規則比對結果與所選策略等常見資訊 |
debug | 短時間重現問題 | 更詳細的解析或內部處理資訊，實際內容視版本而定 |
修改設定時，必須改到實際生效的設定
支援透過設定欄位指定層級的核心，可使用以下頂層欄位。請勿將它縮排到 dns: 或 tun: 底下。用戶端管理訂閱時，請優先使用其提供的覆寫或合併設定功能；直接修改下載的訂閱檔案，可能會在下次更新時遭到覆蓋。
log-level: debug儲存後依照用戶端指示重新載入設定，並確認執行層級確實有變更。排查完成後請改回 info。除錯輸出可能包含瀏覽網域、內網位址及代理伺服器資訊；長期保留不僅會增加雜訊，也會提高分享日誌時洩露資訊的風險。
連線記錄：拆解目標、規則與出站
14:32:10 INF [TCP] 127.0.0.1:53124 --> example.com:443
match DomainSuffix(example.com) using DIRECT這筆示意記錄至少提供四項線索：連線使用 TCP；本機來源連接埠為 53124；目標是 example.com:443；命中網域後綴規則並選擇直連。來源連接埠通常是應用程式暫時分配的連接埠，不是 Clash 的監聽連接埠；不要只因為看到它就去修改 mixed-port。
- 目標：確認網域或 IP 是否對應剛才執行的操作。網頁也會要求圖片、指令碼和登入介面，因此首頁網域並非唯一目標。
- 規則：查看命中的規則類型與內容，不要只看最後顯示的策略群組名稱。
- 出站：
DIRECT代表直接連線；REJECT代表依策略拒絕；代理群組後面可能還會顯示實際選用的代理。 - 結果：出現連線記錄表示核心已處理該連線，不代表 TLS 交握、網頁載入或業務請求已成功。
完全沒有相關日誌怎麼辦？
先確認日誌沒有套用篩選條件，再檢查流量入口。系統代理只會影響遵循該設定的程式；若在應用程式內個別設定代理位址，請核對目前的監聽位址與連接埠，例如 127.0.0.1:7890，不要假設所有用戶端都使用 7890。TUN 模式也要確認虛擬網卡、路由接管及所需權限都已生效。
瀏覽器沿用舊連線時，重新整理頁面不一定會產生新的連線記錄。完全關閉瀏覽器後重新開啟，或使用新的測試程序發送請求，更容易取得清楚的樣本。如果一般代理測試能留下日誌，原本的程式卻始終沒有記錄，請優先檢查原程式的流量接管方式。
dial 失敗：分辨連線遭拒、逾時與路由無法連線
dial 表示正在嘗試建立連線。錯誤中的位址可能是最終目標，也可能是代理伺服器或 DNS 上游。先讀完完整錯誤鏈，找出「正在連線到哪裡」，再決定要檢查網站、節點還是本機網路。
dial tcp 127.0.0.1:7890: connect: connection refused
dial tcp 192.0.2.10:443: i/o timeout
dial tcp [2001:db8::10]:443: connect: network is unreachable上方的 192.0.2.10 和 2001:db8::10 是文件示範位址，並非可供測試的節點。三種錯誤分別著重於「對端拒絕」、「未能在指定時間內完成」及「沒有可用的網路路徑」，處理方向各不相同。
connection refused：先檢查位址與監聽狀態
如果被拒絕的位址是 127.0.0.1:7890，常見原因包括代理核心未啟動、連接埠已變更，或程式仍使用舊設定。Windows 可在 PowerShell 檢查 TCP 監聽狀態；macOS、Linux 可在終端機查看監聽程序。以下指令只會查詢，不會終止程序：
# Windows PowerShell
Get-NetTCPConnection -LocalPort 7890 -State Listen
# macOS / Linux，需先安裝 lsof
lsof -nP -iTCP:7890 -sTCP:LISTEN沒有監聽時，請回到用戶端檢查執行狀態。有監聽時，確認程序是否為預期的核心。若遠端代理位址遭拒，請檢查訂閱中的伺服器連接埠及服務狀態；修改本機混合連接埠無法解決遠端拒絕。
i/o timeout：確認是哪個環節逾時
逾時不代表節點永久失效。原因可能是網路封包遺失、防火牆丟棄封包、代理伺服器無法連線，或目標網站回應緩慢。維持目標不變，只切換同一策略群組中的另一個代理，再比較錯誤位址與時間。如果所有代理都失敗，請繼續檢查本機網路及代理伺服器的網域解析；不要同時修改 DNS、TUN 和規則。
network is unreachable：檢查路由與 IP 位址類型
錯誤位址帶有方括號時，通常代表 IPv6。網路沒有可用的 IPv6 路由、VPN 路由衝突或 TUN 接管異常，都可能造成無法連線。先確認系統本身能否存取相同的 IP 位址類型，再檢查路由是否有變化。單筆 IPv6 錯誤無法證明整個請求失敗，後續可能還會重試 IPv4，請一併查看前後相關記錄。
DNS 解析逾時：分辨上游故障與連線問題
lookup example.com: i/o timeout
exchange failed: context deadline exceeded
lookup example.com: no such host這些示意輸出可能分別代表查詢逾時、DNS 交換超過期限或網域不存在等問題。實際日誌也可能包含上游位址、查詢類型及底層連線錯誤。no such host 不等於逾時：請先核對網域拼字，再檢查回應來源與篩選設定。
- 確認由誰解析：系統 DNS、應用程式自己的 DoH，還是 mihomo 內建 DNS。瀏覽器的安全 DNS 設定會影響解析路徑，TUN 的 DNS 劫持也可能改變實際目的地。
- 確認上游是否可連線：傳統 DNS 常用 UDP/TCP 53，DoT 常用 TCP 853，DoH 通常使用 HTTPS 443。連接埠可連線只代表傳輸層可達，不代表 DNS 查詢一定成功。
- 區分兩種網域：目標網站網域與代理伺服器網域都可能需要解析。代理伺服器解析失敗時，後續代理連線也會失敗。
- 檢查依賴關係：若 DNS 上游必須透過代理才能存取，而該代理伺服器又尚未完成解析，可能形成啟動依賴問題。
系統查詢僅供比對
nslookup example.com這個指令可查看系統預設查詢路徑的結果，但無法證明 mihomo 內建 DNS 正常。在 TUN 或 DNS 劫持生效時，查詢也可能由核心接管。若要判斷是否使用相同路徑，必須搭配目前設定及日誌中的上游資訊，不能簡單推論「系統能解析，所以 Clash DNS 沒問題」。
mihomo 的 proxy-server-nameserver 可用於解析代理伺服器網域，default-nameserver 則涉及解析 DNS 伺服器本身的網域；實際行為與支援項目請以目前核心文件為準。舊版 Clash 設定不一定支援這些欄位，請勿整段複製新版核心範例。使用 respect-rules 等選項時，也要檢查 DNS 請求是否被規則送往依賴自身的代理路徑。
規則未命中：檢查執行模式、順序與目標類型
「規則未命中」不一定會以明確錯誤訊息呈現。較常見的狀況是日誌顯示 Match 兜底，或出站結果與預期不同。先確認用戶端處於規則模式：全域模式和直連模式不會像一般規則模式那樣，依規則為每條連線選擇出站。
# 設定片段：並非完整訂閱
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- MATCH,DIRECT規則會依序檢查，第一條符合的規則決定結果。上述特定網域規則放在兜底規則之前；若將 MATCH 放在前面，後續一般規則就無法處理連線。範例只使用內建目標 DIRECT；若改用自訂策略群組名稱，必須在完整設定的 proxy-groups 中定義該群組。
- 網域不符：
DOMAIN比對指定網域，DOMAIN-SUFFIX比對後綴及其子網域。網頁重新導向後使用的登入網域，可能不在原有規則範圍內。 - 只取得 IP：如果應用程式直接連線至 IP，或網域資訊未被保留，網域規則可能無法參與比對。流量嗅探能否還原網域，取決於協定、設定及核心支援，無法保證所有連線都能還原。
- 規則集未載入：查看啟動或重新載入設定時，provider 下載或解析是否出錯。規則集格式必須符合
behavior；訂閱下載成功不代表每個規則集都已成功載入。 - 覆寫未合併：確認目前啟用的是哪份設定。編輯到其他設定檔，或使用錯誤的合併層級，都可能導致規則未進入執行設定。
- 策略群組選擇不同：即使命中預期規則，仍可能走錯代理，因為群組內的手動選擇、自動測試結果或巢狀群組指向都可能已變更。
驗證時，只新增一條針對目標網域的暫時規則，並放在相關的廣泛規則之前；重新載入後建立新連線。確認規則名稱與出站都符合預期，再判斷是否解決實際連線問題。規則寫法與混合連接埠說明請參閱進階設定。
依時間軸排查：每次重現只修改一個變數
以下是排查記錄範例，並非實際測速結果。假設 14:32:10 重新整理頁面，14:32:10 命中預期策略群組，14:32:15 出現代理伺服器連線逾時。請優先檢查代理伺服器的連線路徑；若 14:32:10 就出現代理伺服器網域解析失敗，解析才是更早發生的問題。
| 觀察結果 | 下一步 | 暫時不要做 |
|---|---|---|
| 沒有目標連線記錄 | 核對日誌篩選條件、系統代理、應用程式代理或 TUN 接管 | 大量更換節點 |
| 代理伺服器網域解析失敗 | 檢查解析上游及啟動依賴 | 只修改目標網站規則 |
| 命中兜底規則或錯誤規則 | 檢查規則模式、順序、網域與執行設定 | 只憑延遲數字判斷規則正確 |
| 預期的出站連線遭拒或逾時 | 核對遠端位址、連接埠及改用另一個代理的比對結果 | 同時重設所有網路設定 |
| 連線已建立，但應用程式仍失敗 | 檢查 TLS、HTTP 狀態碼及應用程式日誌 | 把所有失敗都歸因於 DNS 問題 |
使用明確指定代理的請求測試入口
如果目前混合連接埠確實是 7890，可用以下請求測試 HTTP 代理入口。Windows 使用 curl.exe 可避免部分 PowerShell 環境中的命令別名差異；macOS、Linux 通常使用 curl。
# Windows
curl.exe -I --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 https://example.com/
# macOS / Linux
curl -I --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 https://example.com/此處的 5 秒是連線階段的逾時限制，15 秒是整體請求的逾時限制，只影響這次 curl 測試，不會修改核心的全域逾時設定。-I 會要求回應標頭；即使目標回傳 403 或 405，也不能直接判定代理故障，應一併確認連線是否建立及回應來源。這項測試明確使用本機 HTTP 代理入口，無法單獨證明 TUN 能正常接管其他程式的流量。
如果日誌只顯示連線已處理，瀏覽器仍回報憑證或登入錯誤，請繼續查看瀏覽器開發者工具中的網路狀態與應用程式錯誤。Clash 執行日誌不是完整的 HTTP 封包擷取，通常無法直接顯示所有業務介面的回應內容。核心日誌用於定位傳輸路徑，應用程式日誌則用來補充更上層的原因。
分享排障日誌：保留前後文，隱藏敏感資訊
提供給維護者的資料，重點在於能否重現問題，而不是數量多寡。保留同一請求前後約 10 秒的文字記錄、目前模式、系統版本、用戶端版本及核心版本，並說明是否啟用系統代理或 TUN。請分別記錄用戶端版本與 mihomo 核心版本，不要以其中一項代替另一項。
- 說明操作與預期結果，例如「開啟目標頁面，預期命中指定網域規則，實際卻走了 MATCH」。
- 保留完整錯誤鏈、規則類型、位址類型及連接埠，否則難以區分遠端與本機故障。
- 刪除訂閱連結、認證資訊、控制介面金鑰及存取權杖。
- 代理伺服器、使用者名稱及內網位址可使用一致的代號遮蔽；同一個對象始終使用同一代號。
- 附上最近一次修改，以及修改前後相同請求的結果；不要只截取一行紅色錯誤訊息。