Clash Meta Sniffer 開啟後 HTTPS 報錯？跳過憑證與域名排除逐步修復

Sniffer 在解決什麼問題

在 redir-host 或部分 TUN 場景下，連線在核心裡可能先以「目標 IP」的形式出現；若規則大量依賴 DOMAIN / DOMAIN-SUFFIX，缺少主機名就難以命中正確策略。開啟 Sniffer 後，核心會在早期從 TLS 流量中解析出域名線索，讓規則引擎有機會依真實存取的網站做決策，而不只是憑 IP 猜測。

這與「中間人解密 HTTPS」完全是兩回事：標準 Sniffer 讀取的是握手元資料，而非應用層明文。也正因如此，若你看到的報錯是瀏覽器提示憑證與域名不符、憑證鏈無效，往往需要再分辨：究竟是嗅探與路由改寫帶來的副作用，還是上游節點、系統時間、訂閱 TLS、或目標網站本身的問題。

典型現象：如何判斷是否與 Sniffer 相關

下列幾種情況值得在更改規則前先做「開關對比」——相同節點、相同分流，只切換 sniffer.enable 或 GUI 中的嗅探開關：

• 僅部分域名報錯，其他網站正常；關閉 Sniffer 後立即恢復。
• 銀行、政府機構、企業 VPN、部分本地化 App 在代理環境下突然無法登入，日誌中可見 TLS 相關失敗或反覆重試。
• 使用 fake-ip 時，規則依賴域名匹配；開啟 Sniffer 後策略命中漂移（該直連的走了代理，或相反），並伴隨偶發憑證提示。
• 開啟 override-destination 後問題顯著增多——代表「改寫目的地」與目標應用程式的預期不一致。

若關閉 Sniffer 後問題依舊，請優先回到 《DNS 洩漏與 fake-ip 排查》的路徑：核對 dns.enhanced-mode、nameserver 與 fallback，以及系統、瀏覽器的 DoH 是否繞過了核心 DNS。

第一步：嗅探排除（skip-domain）

最穩妥的修復方式通常不是全面關閉 Sniffer，而是把已知敏感或不相容的域名加入嗅探排除，讓這類連線不參與嗅探邏輯，從而避免對目的地解析的額外干擾。各發行版 GUI 可能顯示為「跳過嗅探域名」、「Sniffer 排除」等，底層多對應設定中的 skip-domain 清單。

寫法上常見支援後綴比對，例如使用 +.example.com 涵蓋子域；具體萬用字元規則以你所用的 Mihomo 版本文件為準。以下是一段示意結構，請依本機 YAML 合併位置與縮排調整：

# Illustrative sniffer block — align with your Mihomo version docs
sniffer:
  enable: true
  sniff:
    TLS:
      ports: [443]
    QUIC:
      ports: [443]
  skip-domain:
    - '+.bank.example'
    - '+.internal.corp'
  force-dns-mapping: true
  parse-pure-ip: false
  override-destination: false

實操建議：不要一次性貼入超長清單。先在連線日誌中確認異常網站的精確主機名，每次加入 1～3 個域名欄位，重新載入設定後複測；穩定後再考慮是否合併訂閱或樣板裡帶來的預設排除項。

override-destination 與 fake-ip 協同

override-destination: true 會讓核心用嗅探到的域名資訊去改寫連線目標，在部分複雜 CDN 或多憑證場景下能改善分流，但也更容易觸發「客戶端以為連的是 IP / 某一憑證 SAN，而實際鏈路被導向另一路徑」的問題。若你剛開啟該選項就出現集中爆發，可先回退為 false，確認基線恢復後再單獨評估每個策略組是否需要更細緻的域名規則。

fake-ip 與 Sniffer 都是為了讓「域名級規則」可用，但組合不當時會出現解析與連線階段不一致的狀況。建議與 同站 DNS 專題一致：每次只改一個變因——先固定 DNS 模式與 nameserver，再動 Sniffer；或先關 Sniffer 驗證 DNS，再開 Sniffer 加排除。

選項	常見收益	常見風險
sniffer.enable	補全 TLS 域名，域名分流更準	少數網站與嗅探邏輯不相容
override-destination	修正「只看 IP 走錯路」	與部分憑證校驗假設衝突
fake-ip	規則早匹配、體驗快	與嗅探、Redir 堆疊組合需對齊

何時才談「跳過憑證驗證」

社群裡常把 skip-cert-verify 當作救命開關，但它幾乎總是作用在代理出站（連接你的機場節點或自架入口）的 TLS 校驗上，而不是替代 Sniffer 修復業務網站的憑證問題。把它設為 true 意味著客戶端不再嚴格驗證與節點之間鏈路的憑證——這會顯著增加被劫持或誤連偽造入口的風險，只適合短期排障或你完全信任的封閉環境。

更健康的順序是：先換用憑證鏈完整的節點或通訊埠；檢查本機系統時間；確認沒有公司資安軟體截斷 TLS；最後再在單一代理項上臨時開啟 skip-cert-verify: true 驗證猜測。切勿在全域樣板裡長期套用此選項。

圖形客戶端裡應調整什麼

Clash Verge、OpenClash 與各 Windows 前端對 Sniffer 的暴露程度不同：有的提供嗅探總開關、TLS／QUIC 通訊埠、跳過清單；有的需要直接編輯原始設定。無論哪種入口，請保持單一真相來源——避免同時在「覆寫 YAML」與「訂閱合併片段」裡重複定義 sniffer，後者可能以你意想不到的順序覆蓋設定。

若你剛接觸 TUN 或 Meta 核心，可先完成 《Clash for Windows 安裝與設定》或 《Clash Verge Rev macOS》的基線，再疊加 Sniffer；否則容易把「驅動或權限問題」誤判成嗅探問題。

TLS 與 QUIC 嗅探的細節差異

Mihomo 核心的 Sniffer 支援針對不同通訊協定分別啟用嗅探，最常見的是 TLS（TCP 443）與 QUIC（UDP 443）。兩者的行為略有差異：

• TLS 嗅探：讀取 ClientHello 中的 SNI 欄位，適用於絕大多數 HTTPS 站點；準確性高，副作用相對較少。
• QUIC 嗅探：在 UDP 封包中解析 QUIC Initial 的 SNI；部分網路環境對 UDP 443 有限速或封鎖，現象可能看起來像憑證錯誤，實際上是 QUIC 握手走不完。
• 若問題集中在特定應用程式且懷疑與 HTTP/3 相關，可嘗試先停用 QUIC 嗅探，觀察是否恢復；或在系統層面強制 TCP（如設定 QUIC_BLOCKED），讓瀏覽器退回 HTTP/2。

另外，force-dns-mapping 選項在 fake-ip 模式下能確保域名與 IP 的映射保持一致，減少嗅探結果與 DNS 解析不同步的問題；若你在 fake-ip 環境下遇到分流漂移，優先確認此項是否開啟。

憑證釘扎（Certificate Pinning）與嗅探的衝突

部分應用程式（尤其是金融、醫療、電子商務類）會在程式碼中內建特定的憑證指紋或公鑰雜湊，稱為憑證釘扎（Certificate Pinning）。這類 App 即使在 Sniffer 並未解密 TLS 的情況下，也可能因為路由路徑改變導致連線目的地的 IP 或 SNI 產生偏差，進而觸發釘扎校驗失敗。

遇到這類情況，最直接的解法是：

1. 將該 App 相關的所有域名加入 skip-domain，讓嗅探不干預這條連線。
2. 若嗅探排除後仍失敗，考慮為該 App 的流量設定 DIRECT 規則，完全繞開代理路徑。
3. 部分 App 的 API 域名與網頁域名不同，需要從行動裝置的抓包工具（如 Stream、Thor）確認完整的目標主機名清單。

常見問題

一開啟 Sniffer 幾乎所有 HTTPS 都變紅

這更像是全域網路、系統時間或訂閱節點 TLS 問題。先關閉 Sniffer 對比；若仍全紅，檢查節點可用性與通訊埠，排除本機資安軟體的 HTTPS 掃描干擾。

只有某個 App 不行，瀏覽器正常

高機率是憑證釘扎或 App 自訂校驗。對該 App 相關域名做 skip-domain，或讓該 App 流量 DIRECT 繞過嗅探路徑（依你的規則能力選擇）。

HTTP/3 / QUIC 異常

若設定了 QUIC 嗅探，可與 TLS 分支分別對比；部分網路環境對 UDP 443 有限速或封鎖，現象類似「憑證錯誤」，實際是握手無法完成。

覆寫 YAML 與訂閱片段衝突

若你在訂閱合併與覆寫裡都定義了 sniffer 區塊，請確認哪一份「排在後面」；Mihomo 合併時後者覆蓋前者，可能把你精心設定的 skip-domain 清單覆蓋掉。建議只在一處定義 sniffer 完整區塊，其他地方留空或刪除。

實操檢查清單

用可維護的客戶端收斂複雜度

Sniffer 是 Meta 系核心的進階能力：能顯著改善域名分流的命中率，也值得為少數不相容目標維護一份小而清晰的排除表。把「嗅探開關、排除清單、DNS 模式」寫進自己的設定筆記，下次升級核心或換 GUI 時能快速還原。當「哪條連線命中哪個策略」這條鏈路能清楚說明，Sniffer 只是眾多進階選項之一，而不是讓人摸不著頭緒的黑盒。

立即免費下載 Clash，開啟流暢上網新體驗