Clash Meta 開啟 Sniffer 後 HTTPS 仍走錯節點？對照 mihomo 日誌查 SNI 並修復

1. 為什麼「規則寫對」仍可能走錯：IP、SNI 與規則時機

在 HTTPS 連線裡，瀏覽器會先建立 TCP，再送出 TLS Client Hello，其中帶有 SNI（Server Name Indication），伺服器才知道要拿哪張憑證、對應哪個虛擬主機。對 mihomo 來說，若此時還沒有還原出網域，規則引擎往往只能先依 IP、PROCESS-NAME、或更底層的特徵做決策；而 CDN 與多服務共用 IP 非常普遍，於是你會看到「我明明寫了 example.com，卻命中了另一條 IP 規則或 MATCH」的現象。

另一個常見落差是：你以為命中的是 A 網域，實際連線卻是 B 網域。例如頁面裡的追蹤腳本、廣告網域、或 API 子網域會另外開連線；使用者只看網址列，但核心看到的是多條並行連線。若沒有從日誌把「每一條連線的 SNI」拆開，你很容易把問題誤判成 Sniffer 壞掉，其實只是規則沒覆蓋到那條子網域。

因此排查的第一步，請先接受一個工作假設：分流失效不是「規則檔案沒存檔」這麼單純，而是「規則在決策當下拿到的資訊不足以指向你預期的網域」。接下來我們才談 Sniffer 能不能補這段資訊，以及補上之後為什麼仍可能被別的規則攔截。

2. Sniffer 在做什麼：還原網域，而不是萬能開關

Sniffer 的核心價值，是讓核心在 TLS 初期從資料流中取出「更像使用者意圖的那個網域」，以便規則可以用 DOMAIN／DOMAIN-SUFFIX 這類條件重新評估。它不是把延遲變成零，也不會自動修復錯誤的 DNS、不會替你修正策略組裡選錯的節點，更不會把已經 DIRECT 的應用程式突然變成走代理。

實務上你需要同時理解兩個邊界：第一，嗅探解析需要時間與條件，某些極短連線、或非典型 TLS 行為可能讓解析不如預期；第二，設定檔裡的 override／force-dns-mapping 等選項會改變嗅探與 DNS 的互動，若你同時開了較進階的 DNS 模式，請把「DNS 模組行為」與「嗅探行為」一起看待，而不是只調其中一邊。

下面是一段示意用的 YAML 結構（實際鍵名與預設請以你使用的核心版本文件為準），重點是讓你看見 Sniffer 通常放在設定檔的哪個區塊、以及 sniffing 與 dns 常並列出現：

Example structure only — adjust keys per your mihomo / Meta build docs
sniffer:
  enable: true
  sniff:
    TLS:
      ports: [443, 8443]
  skip-domain:
    - Mijia Cloud
dns:
  enable: true
  # ... nameserver / fake-ip / fallback ...

若你把 Sniffer 當成「開了就會變聰明」的單一開關，卻沒有在日誌裡驗證它是否真的覆蓋到你的場景，通常會陷入無止境的規則堆疊。下一步我們直接談：日誌裡要看到什麼，才算 Sniffer 真的幫上忙。

3. mihomo 日誌怎麼讀：確認嗅探命中與 SNI 字串

建議你把日誌級別調到能顯示連線與規則命中的程度（實際選項名稱依客戶端而異），然後用「重現問題的最小動作」去打開目標網站一次，從日誌中截取完整一段。你要找的不是只有一行 MATCH，而是這條連線從建立到決策的上下文：目標是 IP 還是網域、是否出現 sniff／SNI 相關欄位、以及最後命中的規則類型與策略組。

實務上可照這個順序讀：先確認連線的五元組與行程（若客戶端有顯示進程資訊），再看TLS SNI 是否出現預期網域；若 SNI 是 *.example.com 的子網域，請回到規則檢查你是否只寫了父網域、或是否被更前面的 GEOIP／IP-CIDR 規則提前帶走。很多人看到「Sniffer 已開」就停止排查，但日誌若顯示決策早於嗅探完成，代表問題在規則順序或模式，而不是嗅探本身故障。

另一個高價值線索是重試與多路徑：現代瀏覽器會同時嘗試 IPv6／IPv4、HTTP／3、或多條並行連線。你可能其中一條命中正確策略，另一條仍直連，表現在使用者畫面上就是「偶發」或「重新整理才好」。日誌要對齊時間戳，避免把兩條連線的事件揉成同一個原因。

若你對 TLS、DNS 與訂閱拉取之間的差異還不熟，建議先讀 訂閱更新與 TLS／DNS 日誌排查，那篇的方法論是「先分類錯誤層級」，與本篇「先分類決策資訊是否完整」可以無縫銜接。

4. SNI 與憑證 CN／SAN：為什麼兩者可能不一樣

有些人會把 SNI 與憑證上的 CN／SAN 混成一個名詞，但在排查分流時，它們代表不同階段的資訊：SNI 是客戶端在握手開始時宣告的伺服器名稱，而憑證主體是伺服器回來的資料。多數正常站點兩者一致；若中間有 CDN、拆分證書、或多層網域別名，日誌裡可能出現「SNI 是 a.example.com，但憑證覆蓋的是 *.cdn.example」這類組合。

這會直接影響你如何寫規則：若你只用很寬的 DOMAIN-SUFFIX，有時反而太寬，把不相干的子服務也帶進同一策略組；若你用太窄的 DOMAIN，又會漏掉實際連線的子網域。當 Sniffer 讓你能看到真實 SNI 時，請把「規則集合」調整成覆蓋那組 SNI 的最小充分集合，而不是一直加更上層的後綴。

遇到「看起來像直連」但其實是誤判時

有些網站會把關鍵 API 放在不同網域；畫面顯示正常不代表所有連線都走同一節點。當你懷疑 分流失效，請以日誌中的 SNI 為準做一張清單，再回頭對照規則檔。這比「感覺規則沒生效」更可靠，也能避免你把問題錯怪到節點品質。

5. 規則與 DNS：順序、Fake-IP、GEOSITE 的常見誤判

即使 Sniffer 正常，規則順序仍可能讓你得到「錯誤但穩定」的結果。典型情況是：靠前的 IP-CIDR／GEOIP 已把流量送進 DIRECT，後面的 DOMAIN 規則再也沒機會執行；或 GEOSITE 大包與你自訂規則的相對位置不符合直覺。若你最近更新過規則集或合併多份訂閱，請優先檢查「最早命中」的那一條，而不是檢查你以為會命中的那一條。

Fake-IP 會讓「應用程式看到的 IP」與「實際伺服器 IP」不同；它的優點是把網域決策留在本機，但缺點是當其他元件仍以 IP 做判斷時，可能出現認知不一致。當 Sniffer 與 Fake-IP 並用時，請以日誌為準觀察：決策當下規則引擎看到的到底是哪個網域、哪個 IP，而不是只看瀏覽器外掛顯示的「出口 IP」。

想補齊策略組切換與自動測速的觀念，可搭配 策略組 url-test 與 fallback 設定：那篇談的是「節點如何在同一策略組內切換」，本篇談的是「流量為何根本沒進你以為的策略組」；兩篇合在一起，才比較接近完整閉環。

6. 系統代理與 TUN：連線是否經過核心的差異

同一份設定檔在 系統代理 與 TUN 模式下，應用程式走的路徑可能完全不同。某些程式忽略系統代理，只會在 TUN 模式下被迫入隧；反之，少數環境下 TUN 與其他虛擬網卡衝突，你又退回系統代理。當你發現「只有瀏覽器正常、其他程式異常」或相反，請先把模式當成第一層變因，再談 Sniffer。

若你剛完成圖形客戶端首次設定，也建議用同一套日誌方法驗證：在調整模式前後各抓一份日誌，對照同一條連線的出站標籤是否改變。這比來回切換 UI 開關更能避免誤判。

7. 可複製的排查清單（建議依序做）

步驟 A：固定變因。只保留一個客戶端、一張設定檔、一種模式（先 TUN 或先系統代理擇一），關閉會注入系統 Proxy 的其他軟體，避免多層轉送讓日誌難讀。

步驟 B：用最小動作重現。清除該站相關分頁後單次開啟，立即截取日誌；確認每一條相關連線是否出現預期 SNI，並記錄最早命中的規則名稱。

步驟 C：檢查規則順序。特別留意 IP／GEO 類規則是否早於你的 DOMAIN 規則；若命中結果與順序矛盾，先調整順序再談加規則。

步驟 D：對照 DNS 與 Fake-IP。觀察解析與回落是否符合預期；若你同時調整了多個 DNS 上游，請一次只改一個變因。

步驟 E：確認 Sniffer 覆蓋埠與例外。檢查是否誤把目標站點放進 skip／忽略清單，或非 443 的 TLS 埠未列入 sniff 範圍。

步驟 F：驗證策略組本身。若流量已進入正確策略組但節點不符合預期，請回到 url-test／fallback 與手動選擇邏輯，避免把節點問題誤報成規則問題。

8. 開源資訊與回報習慣

若你使用基於 mihomo 的客戶端，上游專案的授權、原始碼與 Issue 流程可參考 MetaCubeX／mihomo。回報問題時請附上去除敏感資訊後的設定片段、核心版本、以及能顯示 SNI／規則命中的日誌片段；避免只提供「走錯了」的結論而沒有連線證據。與「取得安裝包」分開：一般使用者要安裝客戶端，仍建議優先使用本站 下載頁，再依 使用教學總覽銜接到分流調校。