1 為什麼要先看日誌，而不是先換下一個節點
Clash Meta／Mihomo 在 rule 模式下，每一條對外連線都會經過「解析 →（必要時）還原目的識別 → 規則掃描 → 策略組選路」這條鏈路。使用者從瀏覽器只會看到「轉圈圈」或「連線重設」，但核心日誌往往已經寫出卡在鏈路的哪一段。若跳過日誌直接換節點，等於用隨機嘗試掩蓋結構問題：可能節點其實健康，敗在上游 DNS；也可能 DNS 正常，但連線仍以 IP／FakeIP 形式進入規則引擎，導致您寫在後面的網域規則根本輪不到。
本文與泛論功能表、按鈕說明的文章不同之處，在於把「讀一行日誌」當成可重複的操作：當您能穩定區分「解析失敗」與「規則決策不符預期」，後續要搭配 Sniffer 教學、DNS／FakeIP 長文 或瀏覽器安全 DNS（可參考Chrome／Edge 與 FakeIP）時，才不會東拼西湊卻對不上現象。
心法：換節點治標；日誌告訴您該改 DNS、規則序位還是嗅探／覆寫目的才治本。
2 先把症狀拆成兩堆：解析層 vs 規則／連線層
實務上可先問自己一個問題：問題發生在「名字還原成位址」之前，還是之後？若瀏覽器或系統在向解析伺服器請求紀錄時就逾時、被拒絕或得到錯誤代碼，核心往往會在日誌裡留下DNS 查詢失敗、no such host、SERVFAIL 這類線索——此時調代理商線路多半無濟於事，應優先檢查 dns 區塊、是否誤用僅適合國內的解析器、或系統／瀏覽器是否繞過核心劫持。
若解析成功（或已進入 FakeIP 對應流程），但連線仍走錯策略組、長時間卡在錯誤出口，日誌裡較常見的是規則名稱、MATCH、或目的仍是純 IP而沒有對應主機名——這偏向規則命中／嗅探／override-destination議題，應與 Sniffer、規則順序一併看，而不是先把connection 日誌忽略掉。
3 日誌等級（log-level）該設哪一檔
Mihomo／Meta 系列通常支援類似 silent、error、warning、info、debug 等等級（實際可用枚舉請以您使用的核心版本文件為準）。日常長開建議不要用 debug 當預設值：輸出量會淹沒真正有異常的幾行，也讓桌面客戶端日誌視窗難以捲動查找。
silent／error：適合上線後長跑或資源吃緊裝置；除錯連線決策時資訊往往不足。warning：可捕捉部分異常摘要，但若問題只在規則細節或DNS 詳細往返，仍可能看不見全貌。info：多數使用者排查「走了哪個策略」「命中哪條規則」時的甜蜜點：連線摘要與決策結果通常會出現，噪音仍可控。debug：僅在短時間復現問題時暫開；抓完片段後務必調回info或更低，以免磁碟與 CPU 耗費無謂成本。
# Example — verify keys against your core version docs
log-level: info
圖形客戶端若提供「日誌等級」選單，與設定檔頂層 log-level 通常是同一概念；修改後若未見輸出變化，請確認設定是否已重載／覆寫檔（mixin）是否又把等級蓋回去。
4 連線日誌：您該盯哪些欄位
不同前端對「連線」列表的排版略有差異，但概念上等價於核心對每一個五元組／會話所做的一次決策紀錄。閱讀時請優先對齊這幾項：① 應用或來源類型（若有）；② 目的位址形式是網域、IP 還是偽裝位址；③ rule 或類似欄位顯示的規則類型與標籤（例如 GEOIP、DOMAIN-SUFFIX）；④ 最終策略組／節點鏈名稱。
若您看到規則總落在很後面的通用項（例如預設 MATCH），代表前面的細節規則未曾命中——接下來要問的不是「節點好不好」，而是為什麼目的識別對不上規則條件：常見包含嗅探未開／未覆寫目的、前面有更寬鬆的 IP-CIDR 先攔截、或該域名根本落在規則集之外。這類線索正是 connection 日誌 與規則除錯的交界。
另一方面，若連線紀錄稀疏或長時間空白，也有可能流量未進入核心（例如瀏覽器私密 DNS、系統繞過 TUN／代理例外）。此刻應同步檢查系統網路設定與站台內Android 私密 DNS等專題，而不是只在代理軟體裡找答案。
5 DNS 失敗在日誌裡的典型面貌
當DNS 失敗發生時，使用者在 UI 上可能只看到「無法連線該網站」，但核心側常見特徵包括：解析請求發出後無有效應答、應答標記為錯誤、或反覆在同一組解析伺服器上失敗後才 fallback。開著適中的日誌等級時，這類事件往往會伴隨警告級別以上的訊息；若仍看不清，再在短時間窗口內升到 debug，對齊同一秒的連線嘗試與解析請求。
與FakeIP並存時，請記得分開看待两件事：應用程式拿到的位址可能是核心分配的映射；真正決定規則能否對準網域的，仍是嗅探／覆寫與規則順序。若您懷疑「解析看似成功但網站仍異常」，請交叉閱讀本文連線段落與DNS 防洩漏一文中關於 enhanced-mode、分流域名伺服器的描述。
6 規則未命中、誤命中與「看似 FakeIP 無效」
許多人描述為「FakeIP／規則不生效」，細讀connection 日誌後常會收斂成兩類：① 規則其實命中了，但命中的是您誤會會走代理／直連的那一條（規則集版本或順序與認知不符）；② 命中結果雖是預設組，但是因為連線階段缺少網域線索，網域規則從未被評估。
對第二類情況，本站HTTPS 嗅探與 SNI一文說明了為何在 TUN／FakeIP 下需要把目的還原成主機名；若連線日誌長期顯示純 IP決策而少有網域名稱，請優先核對嗅探與 override-destination，而不是再加十條網域規則。
此外，若您使用國別類規則（如 GEOIP），請確認資料庫是否過期——過時的 mmdb 會造成「規則命中結果與直覺國別不符」，視覺上像規則錯亂，其實是資料問題；可將GEOIP／geosite 手動更新納入例行維護。
7 建議排查順序（可列印貼在螢幕邊）
- 固定復現動作：同一瀏覽器、無痕視窗一次，排除擴充套件快取。
- 將
log-level調為info，必要時短開debug。 - 觀察是否先出現 DNS 相關錯誤或逾時——有，則先修
dns與系統／瀏覽器 DNS；無，則進入連線規則分析。 - 在連線紀錄找出該站的命中規則名稱與策略組，對照設定檔順序核對是否被前置規則搶跑。
- 若目的欄位長期是 IP：依序檢查 Sniffer、QUIC／HTTP3 覆蓋、以及 TUN 是否真的接手該進程。
- 最後才评估節點品質（延遲、丟包、出口封鎖）；此時再用 URL-Test／Fallback 才有意義。
8 總結
Clash Meta／Mihomo 的進階排障裡，connection 日誌是把「走錯節點、FakeIP 看似失效、網頁間歇無法開啟」還原成可驗證假說的起點。先依日誌等級取得足夠資訊，再判斷問題落在 DNS 還是規則匹配／目的識別，最後才動到節點與策略組微調，整體效率會比盲目切換高一個數量級。
若您希望用圖形客戶端長期維持可讀的連線列表與日誌視窗，建議從 本站下載頁取得與 Meta 核心對齊的發行版，再將本文的 log-level 建議與既有設定合併。相對封閉、難以同螢幕檢視決策鏈路的工具，往往在這類「到底是 DNS 還是規則」的場景裡多花數倍時間。
