Clash Sniffer 嗅探無效？mihomo 串流媒體網域辨識與規則修正步驟

為什麼「已開 Sniffer」仍對不到串流網域規則？

在 Mihomo（Clash Meta）核心裡，Sniffer（嗅探）的作用是：當連線以 IP 位址進入核心（例如目標是 198.51.100.10），而應用程式又沒有透過 HTTP 代理語意提供 Host 時，核心會嘗試從 TLS ClientHello／HTTP 標頭等資訊還原真實網域名稱，讓後續的 DOMAIN／DOMAIN-SUFFIX 規則有東西可以匹配。串流客戶端、桌面 App 與部分瀏覽器擴充行為，經常出現「連線已是加密隧道、但規則仍以 IP 思考」的情況；此時若沒有嗅探或嗅探被略過，介面上看起來就像規則寫了卻永遠不生效。

另一方面，嗅探不是萬能開關：它無法憑空知道每一種協定的語意，也會受 skip-domain、埠口對應、是否覆寫目的地、以及更早命中的規則影響。因此實務排查應把問題拆成四層：嗅探是否真的啟用並作用在該連線、覆寫目的地是否開對、規則順序是否讓串流網域有機會被評估、DNS（含 fake-ip）是否與嗅探結果一致。下列章節依序說明，並在文末附上可貼入設定檔的骨架。

第一步：確認嗅探模組與埠口對應

在設定檔中，sniffer 區塊需 enable: true，且 sniff 底下針對 HTTP、TLS、（若環境需要）QUIC 宣告要嗅探的埠口範圍。串流場景幾乎都走 443 與部分 8443；若您把 TLS 只綁在少數埠，或客戶端使用非預設埠，嗅探可能完全不觸發。建議先採較寬鬆的埠清單驗證行為，再視日誌收斂。

用戶端若提供「嗅探」GUI 開關，請確認它實際寫入的是核心所載入的那份設定（有些場景存在執行中設定與磁碟上的檔案不同步）。變更後請重載核心，並在連線發生時檢視日誌是否出現嗅探相關紀錄（實際關鍵字依版本而異，但「還原網域／override」類訊息值得留意）。若您同時使用 TUN 模式，請先確認流量確實進入核心；否則再強的嗅探也不會被呼叫。

YAML（sniffer 骨架，請依版本微調）sniffer:
  enable: true
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443
  force-domain:
    - "+.example-streaming.com"
  skip-domain:
    - Mijia Cloud
    - "+.push.apple.com"

force-domain 用於明確要求對某些網域嘗試嗅探（欄位名稱與前綴寫法請對照您使用的核心版本文件）；skip-domain 則可避免對內網或特定裝置同步網域誤判。串流除錯時，可先把目標平台的已知根網域列入 force-domain 做 A／B 測試，確認嗅探鏈路有跑起來。

第二步：override-destination 與「覆寫目的地」

嗅探到網名後，核心還要決定要不要把連線的「目的地」改成嗅探到的主機名，後續規則才會以網域為準做匹配。若僅嗅探但不覆寫，部分情境下仍可能以 IP 走規則，導致您以為「Sniffer 壞了」。在 Mihomo 中此概念常對應 override-destination（或 GUI 上的同義選項）：開啟後，符合條件的連線會以還原出的網域參與規則評估。

若您發現日誌已顯示嗅探到正確 SNI，但策略仍落在 GEOIP 或 MATCH 的預設出口，優先檢查覆寫是否啟用，以及該連線是否落在 skip-domain。某些企業內網或本機服務會需要關閉覆寫以避免迴圈，但一般串流解鎖多數情況需要覆寫與網域規則搭配使用。

YAML（覆寫目的地）sniffer:
  enable: true
  override-destination: true

第三步：規則優先級——把 DOMAIN-SUFFIX 放在會「提早結束」的規則之前

Clash 系規則由上而下匹配，命中即停止。常見錯誤是：在檔案底部寫了漂亮的 DOMAIN-SUFFIX,netflix.com,STREAM，但上方已有 GEOIP,CN,DIRECT 或訂閱內建的寬鬆規則，導致連線在抵達串流規則前就被送進直連或其他策略群組。嗅探再正確也無法扭轉「已經被上一行送走了」的事實。

實務作法：將您關心的串流根網域（例如大型平台的 DOMAIN-SUFFIX）移到足夠靠前、且與其他邏輯不衝突的位置；並為串流單獨準備一個 proxy-groups 項目（例如 STREAM_PROXY），避免與一般瀏覽器流量混在同一個 url-test 群組裡難以除錯。更完整的規則順序觀念可對照 規則分流詳解 一文中的「匹配順序」段落。

YAML（規則置前示意）rules:
  - DOMAIN-SUFFIX,netflix.com,STREAM_PROXY
  - DOMAIN-SUFFIX,nflxvideo.net,STREAM_PROXY
  - DOMAIN-SUFFIX,disney-plus.net,STREAM_PROXY
  # ... your other rules ...
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

若您使用 rule-providers 載入第三方規則集，請注意merge 順序與「自訂規則插入點」：不少 GUI 允許「訂閱規則在前／自訂在後」或相反，錯一次就會讓自訂串流規則永遠排不上用場。

第四步：DNS 模式與 fake-ip 是否「說同一種語言」

在 dns.enhanced-mode: fake-ip 下，應用程式拿到的常常是核心配置的虛擬位址，真正的網域解析與規則匹配依賴核心內部狀態。此時若嗅探失敗、覆寫關閉、或規則仍以 IP 呈現，就容易出現「瀏覽器看起來正常、客戶端 App 卻異常」的分裂現象。除錯時請同步檢查：nameserver／fallback 是否會繞過政策、fake-ip-filter 是否把串流相關網域排除在 fake-ip 之外（依需求二擇一），以及 串流專文中提到的「DNS 與出口一致」原則。

若您懷疑 fake-ip 與嗅探互動不良，可做對照實驗：在理解風險與後果的前提下，暫時改用較傳統的解析模式（例如 redir-host，視核心版本與用戶端而定），觀察規則命中是否恢復正常；再回頭微調 fake-ip 篩選與嗅探設定，而不是永遠只靠其中一邊硬撑。

YAML（dns 骨架示意）dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.example/dns-query
  fallback:
    - tls://dns.example:853

串流場景除錯檢查清單（建議順序）

• 流量有進核心嗎？僅系統代理時，部分 App 仍直連；可交叉比對 TUN 教學 中的情境。
• 嗅探有啟用且埠口涵蓋 443？並確認 GUI 與實際載入 YAML 一致。
• override-destination 是否開啟？並排除 skip-domain 誤傷。
• 串流 DOMAIN 規則是否夠前面？未被 GEOIP／MATCH 提前帶走。
• DNS 與 fake-ip 設定是否與嗅探結果一致？必要時做 A／B 對照。

結語

總結來說，Clash Sniffer 解決的是「連線只有 IP、規則卻寫網域」的命名空間問題；而串流能否走對節點，還要疊加覆寫目的地、規則順序與 DNS／fake-ip 是否一致。把這四項拆開排查，比反覆複製網路上的片段規則更有效率。

相較於零散工具，使用持續更新的 Mihomo 核心與可信用戶端，通常較能跟上 TLS 與嗅探邏輯的演進；若您尚未安裝合適的 Clash 用戶端，可先從本站下載頁取得對應平台版本，再依 Clash Verge Rev 教學 完成模式與設定檔路徑確認。