症狀先講清楚：這不是「整條線掛了」的那一種壞
很多人描述問題時會說「Clash 開著但網頁打不開」。若細問下去，常見其實是：延遲測試或訂閱更新都正常，甚至大部分網站能開，只有特定幾個網域一直轉圈、顯示空白、或瀏覽器提示憑證／連線異常。這種「局部失效」與「節點整批死掉」的排查路線不同，也更容易讓人誤以為要狂換節點，卻忽略底層是 DNS 模式與連線還原邏輯在打架。
在 Mihomo（原 Clash Meta）生態裡，dns.enhanced-mode 常見兩種取值：fake-ip 與 redir-host（圖形介面可能用不同中文或英文標籤，但語意相同）。再加上是否啟用 sniffer（TLS／QUIC 等嗅探以還原真實目標），三者組合會直接影響「規則看到的是網域還是 IP」「握手階段誰在說話」。本文目標是：當你已確認不是單純節點逾時時，用可重複驗證的順序縮小範圍，避免同時改十個開關後無法還原。
請在合法合規前提下閱讀與實作；下文僅討論技術設定與常見相容性問題，不提供規避法規或濫用網路資源的指引。若你同時看到連接埠佔用或 dial tcp 類訊息，可先交叉閱讀本站連線與日誌排查文，再回來對照 DNS 這一側。
Fake-IP 與 Redir-Host：一句話與一張心智圖
Redir-host 比較接近傳統流程：應用程式或系統先拿到「真實解析結果」（真實 IP），連線目標在 IP 層已經確定，核心再依規則決定要不要把這條 TCP／UDP 流送去代理。好處是語意直覺，部分只信任 IP 的舊規則或診斷工具較好理解；壞處是在複雜規則與多段解析（本機、DoH、fallback）並存時，較容易出現「解析走 A 路徑、實際連線卻像走 B 路徑」的錯位感，尤其在 CDN 與多網域跳轉場景。
Fake-ip 則刻意在本地為「尚未真正對外解析的網域」配置一個虛擬位址區段內的假 IP，讓連線較早進入核心，以便用網域名稱做細緻分流。對大量依賴 DOMAIN、DOMAIN-SUFFIX 規則的使用者，這通常帶來較一致的體驗。缺點是少數應用、舊版函式庫或特殊外掛會假設「DNS 回傳的一定是公網可路由位址」，再疊加 TLS 中間邏輯時，就可能出現怪異行為；此時就會聽到「改回 redir-host 就好了」這類經驗談。
重點在於：沒有絕對較好的模式，只有與你的規則集、嗅探設定、以及 TUN／系統代理組合較吻合的那一組。接下來兩節把兩種模式各自常踩的雷講細一點，後面再接 sniffer 與故障樹。
Fake-IP 常見「網頁打不開」機制：從假位址到真連線
在 fake-ip 下，瀏覽器以為自己要連的是某個 IP，實際上核心要先把這個 IP 對回網域，才能正確挑規則、挑鏈路。若這條「對回」鏈路任何一環失準，表面症狀就是白屏、資源載入卡住、或 HTTPS 握手怪怪的。實務上常見幾類原因：
- 嗅探與覆寫目標不一致：sniffer 關閉或規則排除導致無法從 TLS Client Hello 還原 SNI，核心只能用 IP 或不全的資訊做決策，與你預期的域名規則對不起來。
- fake-ip 區段與區網或 VPN 區段衝突：若
fake-ip-range與其他虛擬介面、公司內網路由撞車，會出現間歇性連不上特定類型網站的情況。 - 規則大量依賴 IP 規則，但解析與連線敘事分裂：例如先被解析到某 CDN 邊緣 IP，規則卻期待仍以網域命中；在 fake-ip 與 redir-host 之間切換時，這類差異會被放大。
因此遇到「只有少數站壞掉」時，在 fake-ip 前提下，我會優先懷疑嗅探與 TLS 行為，而不是先換節點。下面關於 sniffer 的一節會把「該不該關」說清楚。
Redir-Host 常見痛點：解析太早、規則太晚
Redir-host 的經典矛盾是：誰先解析、誰就有話語權。若系統或瀏覽器先把網域送到「不在你掌控下的解析器」（例如路由器強制 DNS、瀏覽器內建安全 DNS、公司代理），核心收到的可能已經是「被引導過的 IP」，後續規則再怎麼寫網域，也難以挽回第一次解析的偏誤。
另一種常見現象是 GEOIP 或 IP-CIDR 規則誤判：站點解析到你所在區域的 CDN 節點，規則以為要 DIRECT，實際業務邏輯卻需要走代理，或相反。此時使用者會描述成「同一個網站，別人能開我開不了」，其實是解析結果與規則預設不一致。對策方向包括：把關鍵業務網域改以 DOMAIN 規則置頂、檢查 dns 區塊的 nameserver／fallback 是否與分流語意一致，必要時暫時改回 fake-ip 觀察差異。
若你希望系統性理解 nameserver、fallback 與防洩漏設定，可搭配本站DNS 防洩漏指南一起閱讀；本文則專注在「模式二選一＋嗅探」與網頁打不開的交集。
Sniffer（嗅探）在做什麼？什麼時候該關
簡化地說，sniffer 會在允許的條件下從流量中還原「這條連線真正想連的網域名稱」（常見來源是 TLS SNI），讓核心在 fake-ip 或某些隧道場景下仍能以域名做策略。沒有它時，部分連線在核心眼中可能「只剩 IP」，導致你明明寫了域名規則卻命不中，或命中順序與預期不同。
但嗅探不是免費午餐：少數網站、內網服務、或對中間還原特別敏感的應用，可能與預設嗅探邏輯不相容；有些圖形介面還會把「覆寫目標」類選項一併打開，放大了誤判空間。實務上我建議把 sniff 相關調整視為二分法實驗：
- 先完整關閉 sniffer（或僅保留最小必要範圍），清快取、重啟用戶端，測問題網站是否恢復。
- 若關閉後問題消失，再分段打開：先只允許常見 HTTPS 埠、排除內網與已知會炸的網域，避免一次全開。
- 若關閉後仍壞，代表主因較可能落在 DNS 模式、規則排序、或純節點／路徑，請往下走故障樹。
故障樹：依序做，避免同時改一堆
下面這張順序是專門給「節點大致可用、只有部分網站異常」的情境。若你從第一步就發現所有網站都壞，請先回到連線與日誌那一側。
步驟 1：確認瀏覽器沒有「第二套 DNS」
Chrome／Edge／Firefox 的「安全 DNS」或 DoH 若指向與 Clash 策略無關的解析器，會讓你在 redir-host 下特別痛苦。請暫時關閉瀏覽器層級安全 DNS，只用系統解析路徑測一次。
步驟 2：關閉或限縮 sniffer，重測問題網站
若症狀是少數 HTTPS 站點憑證錯誤、資源碎片化載入失敗、或只有特定 App 異常，這一步命中率很高。
步驟 3：在 fake-ip 與 redir-host 之間做一次對照
僅切換 dns.enhanced-mode，其他 DNS 與規則先不動；重啟後測同一組網址。若其中一邊明顯穩定，就以那一邊為基線，再回頭微調 nameserver。
步驟 4：檢查規則置頂與「域名優先於 IP」的需求
對問題網域加上明確的 DOMAIN／DOMAIN-SUFFIX 規則並放在 GEOIP 與寬鬆 MATCH 之前，避免被 IP 規則提前帶去錯誤策略組。
步驟 5：對照 TUN 與系統代理
有些程式不讀系統代理；若你只在系統代理模式下測試，會誤判成「Clash 壞了」。改以 TUN 覆蓋測一次，或反過來關 TUN 只留系統代理，觀察差異。
步驟 6：看日誌關鍵字
搜尋與 DNS、嗅探、TLS 相關的錯誤行，確認是解析失敗、握手失敗，還是規則命中後上游逾時。日誌判讀與連接埠議題可再對照前文連結。
規則與 DNS 要講同一種語言
無論 fake-ip 或 redir-host，規則敘事與解析敘事不一致時，最容易出現「偶發壞站」。實務上可記三句話：域名規則要能被核心看見真實域名；IP 規則要基於你信任的解析結果；fallback 與 geoip 過濾不要與業務網域打架。
若你使用第三方規則集，請留意更新頻率與置頂自訂規則的位置；過大的規則集若與本地 DNS 模式不匹配，會放大延遲與誤命中。更多 provider 與排序觀念可參考本站Rule Providers 進階指南。
設定檔裡你可以對照哪些鍵（示意）
下列片段僅協助你與手邊 YAML 對照語意，請勿直接複製未知來源的 DNS 端點：
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- https://dns.example.net/dns-query
sniffer:
enable: false
sniffing:
- tls
- http在實驗時，你可以先把 sniffer.enable 設為 false，再把 enhanced-mode 改為 redir-host 各測一輪；每輪之間清快取並重啟用戶端。完整欄位說明亦可交叉查閱本站文件總覽與上游版本更新日誌。
開源與版本相容
Mihomo 核心持續調整 DNS、嗅探與規則引擎的細節；若你懷疑某個行為是版本回歸，建議到 GitHub 上的 Mihomo 倉庫核對對應版本的說明與 issue。安裝包下載與更新仍建議以本站頁面為主，以降低「圖形殼與核心版本不匹配」的機率。
小結：先嗅探、再模式、最後才動規則大手術
Clash Fake-IP 與 Redir-Host 不是誰比較進階，而是兩種讓「網域／IP／規則」對齊的策略。當你已能連上節點卻遇到網頁打不開的局部症狀時，請優先懷疑嗅探與 DNS 模式是否讓核心看不見你以為它看得見的那個網域，再來調規則與解析器。把變因一次一個拆開，你會比較快找到穩定組合，也不用在社群裡丟一句「壞了」卻無法復現。
若你希望略過手動對齊核心與圖形介面預設值的時間，可選用已整合 Mihomo、並對常見 DNS 模式與診斷入口整理過的用戶端；與零散教學拼裝相比，升級後也比較不容易出現「規則還在、解析行為已變」的錯位。建議前往本站下載頁依平台取得安裝包，再依本文順序逐步驗證。