先確認日誌來源與連線階段
Clash 日誌不是一份「節點優劣清單」。同一次瀏覽網頁，可能會觸發網域解析、規則比對、連線至代理伺服器、協定交握，以及連線至目標網站等步驟。錯誤出現在不同階段，處理方向也不一樣。看到一筆紅色紀錄就更換訂閱，往往會錯失最有用的現場資訊。
先區分用戶端日誌與核心日誌。用戶端日誌通常記錄介面、設定檔下載、更新與權限問題；Clash 或 mihomo 核心日誌則主要記錄設定載入、監聽連接埠、DNS 與連線處理。用戶端使用 mihomo，不代表所有錯誤都來自 mihomo。排查時請一併記下用戶端與核心版本，不要只寫「最新版」。
- 啟動即失敗：先查看設定解析、策略引用、連接埠占用與權限提示，不必先檢查目標網站。
- 啟動正常但網頁無法開啟：先找出該網域的連線紀錄，再確認規則與出口路徑。
- 只有訂閱更新失敗：檢查下載設定檔所使用的網路、訂閱網址狀態與 HTTP 回應，不要直接視為代理連線故障。
- 瀏覽器連線失敗但沒有相關日誌：先確認流量是否進入用戶端，再檢查節點。系統代理無法涵蓋所有應用程式；TUN 也可能設有路由排除。
如何調整日誌層級：先用 info，需要時短暫切換至 debug
在用戶端開啟「日誌」頁面，尋找層級下拉選單或篩選選項。請注意，介面上的篩選器可能只是隱藏部分紀錄，並未改變核心產生日誌的層級。若需要更詳細的紀錄，請確認執行中的設定已變更 log-level。
常見的 Clash 核心與 mihomo 使用 silent、error、warning、info、debug 等層級。日常使用建議以 info 為起點；需要排查時改為 debug，重現一次問題後再恢復。詳細日誌會增加輸出量，也可能暴露瀏覽過的網域。
透過設定調整的步驟
- 先備份目前的設定，並確認用戶端支援哪種方式：持續生效的覆寫、設定合併或編輯本機設定。
- 在頂層設定
log-level: debug。若已有同名欄位，請修改原欄位，不要重複新增。 - 透過用戶端的重新載入設定功能套用變更；若用戶端要求重新啟動核心，請依提示操作。
- 開啟日誌面板，確認目前顯示的不是只有 warning 或 error。只執行一次失敗操作，並保留前後約 30 秒的紀錄。
- 收集完成後，將
log-level: info還原，避免長時間輸出大量瀏覽紀錄。
# 頂層欄位片段，合併至現有設定
log-level: debug以上不是完整設定檔。直接編輯訂閱產生的檔案，可能會在下次更新時遭到覆寫。若用戶端提供覆寫功能，請優先使用可持續生效的覆寫。選單位置會隨用戶端版本而異，因此不要把某款用戶端的「設定」路徑當成所有 Clash 用戶端的通用入口。
連線日誌有哪些欄位值得查看
先看時間，再看目標、規則與錯誤。連線日誌常帶有 [TCP] 或 [UDP] 標記；match、using 等文字通常用來說明命中的規則與使用的出口。實際輸出取決於核心，不是每筆紀錄都會包含完整欄位。
| 欄位或內容 | 需要確認的問題 |
|---|---|
| 時間與協定 | 是否對應剛才的失敗操作？TCP 與 UDP 的表現是否不同？ |
| 來源位址 | 請求是否來自目前裝置或預期的應用程式，而非背景更新或區域網路中的其他裝置？ |
| 目標網域與連接埠 | 是目標網站的 443 連接埠、DNS 的 53 連接埠，還是代理伺服器本身的服務連接埠？ |
| 規則與策略 | 預期透過代理連線卻命中 DIRECT，還是遭 REJECT 拒絕？策略群組實際選中了哪個成員？ |
| 錯誤鏈結尾 | 連線失敗的直接原因是解析失敗、逾時、連線遭拒，還是協定或憑證錯誤？ |
DIRECT 表示使用直連出口，不代表請求成功。REJECT 表示依策略拒絕，可能正是預期的封鎖結果。即使日誌顯示使用某個代理群組，也應在連線詳細資訊或策略頁面確認實際選取的節點；自動策略群組的成員可能在兩次測試之間變動。
dial tcp、timeout 與連線中斷有何不同
dial tcp：先查看後面的位址與原因
dial tcp 192.0.2.10:443: connect: connection refused
dial tcp 192.0.2.10:443: i/o timeout
dial tcp: lookup proxy.example on 127.0.0.1:53: no such hostdial tcp 只表示正在建立 TCP 連線，本身並非故障結論。範例中的 192.0.2.10 是文件示例位址。查看實際紀錄時，請判斷該位址屬於代理伺服器，還是直連時存取的目標。若無法連上代理伺服器，修改目標網站的分流規則通常無法解決問題。
- connection refused：連線遭到明確拒絕，常見原因包括連接埠沒有服務在監聽、連接埠填錯，或防火牆主動拒絕。這不代表帳號密碼錯誤；驗證通常是在連線建立後進行。
- i/o timeout：某項網路讀寫操作未能在期限內完成。可能是線路封包遺失、目標沒有回應、出口受到限制，或卡在協定處理階段；需搭配外層錯誤判斷發生位置。
- network is unreachable：本機或目前網路沒有可用路由。優先檢查網路介面、預設路由與 IPv6 連線能力，不要先修改驗證資訊。
context deadline exceeded：整體操作逾時
這表示有時限的操作未能如期完成，可能發生在 DNS 請求、健康檢查或建立連線的過程中。光看這幾個字無法判斷是哪個節點出了問題。請保留外層脈絡，例如確認紀錄來自 DNS 模組還是代理撥號模組，並比對同一時間的其他連線。
EOF、connection reset by peer：連線建立後遭到關閉
EOF 表示讀取時遇到連線結束；connection reset by peer 表示收到重設訊號。可能與伺服器關閉連線、協定不相符或中間網路設備介入有關。若每次都在交握階段出現，請核對節點類型、連接埠、TLS 設定與傳輸參數；若只偶爾在閒置連線結束時出現，且實際存取正常，不必只憑這筆紀錄判定故障。
DNS 解析失敗：分清節點網域、目標網域與解析器
看到 lookup、no such host 或 DNS request failed 時，先記下正在解析的網域。若節點伺服器的網域解析失敗，透過該節點的所有請求都會受影響；只有單一目標網域失敗時，應先檢查該網域的紀錄與解析路徑。
| 日誌線索 | 代表的狀況與下一步 |
|---|---|
| no such host | 解析沒有取得可用結果，常見原因是網域不存在，或上游回覆否定答案。請核對拼字、網域狀態與實際使用的解析器。 |
| DNS 請求逾時 | 先確認 DNS 上游是否可連線，以及協定設定是否正確；使用 DoH 時，也要留意如何解析其伺服器網域以完成初始連線。 |
| 127.0.0.1:53 連線失敗 | 確認本機 53 連接埠確實有 DNS 服務在監聽。回送位址指的是目前裝置，不代表路由器或其他裝置。 |
| server misbehaving | 通常與 DNS 伺服器回覆失敗有關，應比對具體回覆與其他解析器的結果，不能直接斷定網域不存在。 |
系統查詢結果不一定代表用戶端使用的 DNS
例如執行 nslookup example.com，通常會查詢系統選用的解析器。如果用戶端使用內建 DNS、fake-ip 或獨立的 DNS 上游，這個結果不一定反映應用程式實際採用的解析路徑。請先查明執行設定中的監聽位址與連接埠，以及應用程式的請求是否已被接管。
在 fake-ip 模式下，出現 198.18.0.0/16 這類位址，可能是設定所分配的映射位址，不應只憑該位址判定解析錯誤。若應用程式保留舊映射，而核心重新啟動後映射狀態有所變化，可能需要關閉相關應用程式的連線，並依用戶端提供的方式清除快取，再重新測試。
mihomo 的 proxy-server-nameserver 可用於解析代理節點網域。是否需要此欄位，應依核心版本與現有 DNS 設計判斷。不要把 mihomo 專用欄位直接加入不支援的舊版核心，也不要一次替換所有 DNS 設定；請先確認究竟是哪個網域、哪個上游發生問題。
排查連接埠、TLS 與設定錯誤的起點
address already in use：本機監聽連接埠已被占用
如果啟動日誌顯示無法監聽 127.0.0.1:7890，先檢查是否同時執行了兩個用戶端，或舊核心尚未結束。7890 只是常見設定範例，請以目前 mixed-port、port 或 socks-port 的實際值為準。
# Windows PowerShell：查看範例連接埠的監聽程序
Get-NetTCPConnection -LocalPort 7890 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess
# macOS：查看範例連接埠的 TCP 監聽狀態
lsof -nP -iTCP:7890 -sTCP:LISTEN
# Linux：查看範例連接埠的 TCP 監聽狀態
ss -ltnp 'sport = :7890'確認程序身分後，再正常結束應用程式以釋放連接埠，或調整目前的監聽連接埠。不要只看到 PID 就強制終止不明程序。變更連接埠後，也要同步更新系統代理或應用程式中的代理位址，否則可能出現「核心正常，但應用程式仍連到舊連接埠」的情況。
x509 與 TLS handshake：檢查時間、憑證與服務名稱
遇到 x509: certificate has expired or is not yet valid 時，先檢查裝置日期、時區與自動校時，再確認伺服器憑證是否仍在有效期限內。若憑證名稱不符，請核對伺服器位址、TLS 服務名稱及服務提供者要求的設定。TLS handshake timeout 也可能是網路遭封鎖或連接埠協定不符，不能一概歸因於憑證過期。
設定載入失敗：先恢復可執行狀態
遇到 YAML 解析錯誤、未知策略或缺少代理群組時，先復原最近一次變更。YAML 縮排請使用空格，避免混用定位字元；規則引用的策略名稱必須與實際定義一致。若核心未能成功載入設定，後續網頁存取失敗就不只是線路問題。請先讓設定載入與連接埠監聽成功，再排查連線。
依時間順序重現問題：一次只變更一個變數
日誌很容易被背景同步、自動健康檢查與應用程式重試訊息淹沒。有效重現問題不在於收集越多越好，而是將單一操作對應到一小段紀錄。以下提供可重複執行的檢查流程，時間僅供操作示範。
- 14:20:00，記錄基準資訊。記下用戶端版本、核心版本、系統版本、網路類型、目前模式、是否啟用 TUN，以及策略群組所選的節點。
- 14:20:10，開始短時間收集。將核心日誌層級調為 debug，在面板中清除舊紀錄或記下起始時間，並保留啟動與設定載入時的原始錯誤。
- 14:20:20，存取一個目標。關閉不相關的分頁，只開啟一個先前無法連線的網址。記下瀏覽器提示，以及日誌中的目標連接埠、規則與出口。
- 14:20:40，進行一次對照測試。保持目標、模式與網路不變，只切換一個節點。若節點網域都無法解析，請先檢查 DNS，不要繼續隨機切換。
- 14:21:00，整理差異。是沒有流量進入、命中錯誤規則、節點連線失敗，還是連線建立後目標沒有正常回應？請明確寫出發生問題的階段。
沒有日誌時，檢查流量接管狀態，不要提高日誌層級
可以透過本機代理請求進行對照。以下命令僅適用於目前設定確實在 127.0.0.1:7890 提供 HTTP 或 mixed 代理的情況。Windows PowerShell 可使用 curl.exe，避免與其他命令別名混淆。
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/此處的 10 秒是建立連線階段的逾時上限，20 秒是整個請求的時間上限，並非速度指標。此命令使用 HEAD 請求；部分網站處理 HEAD 的方式與一般網頁不同。它適合檢查明確指定的代理路徑，不能取代瀏覽器測試，也無法據此確認 TUN 已接管所有流量。
如果命令能產生連線紀錄，但瀏覽器沒有，請檢查瀏覽器代理擴充功能、系統代理與應用程式各自的設定。如果啟用 TUN 後出現問題，先記下路由與 DNS 狀態，再進行一次開關對照。不要同時切換 TUN、DNS 模式、節點與規則，否則無法判斷是哪項變更生效。
回報故障資訊：保留脈絡並移除敏感欄位
向維護者或服務提供者回報時，提供失敗前後約 30 秒的必要日誌，比只截取最後一行的圖片更有幫助。文字日誌方便搜尋與比對，但請先檢查是否包含憑證或個人資訊。
- 保留：準確時間與時區、用戶端及核心版本、完整錯誤訊息、目標連接埠、命中規則、使用的協定，以及已進行的單一變數對照測試。
- 移除：完整訂閱網址、驗證權杖、密碼、UUID、控制介面金鑰，以及不適合公開的存取網域與裝置路徑。
- 一致地遮蔽資訊：同一節點在不同日誌中使用相同代稱，避免失去關聯；不要把所有網域和位址都替換成同一個詞。
- 區分原始紀錄與整理內容：註明哪些是實際日誌、哪些是重現步驟。不要把重新撰寫的範例當成用戶端原始輸出。
結論最好具體寫成「連線至代理伺服器的 TCP 階段逾時」、「規則將目標送往 DIRECT」或「節點網域解析失敗」，而不是只寫「Clash 無法使用」。先確認出錯階段，再選擇相應的網路、規則或設定檢查方式，後續修改才有明確依據。