什麼是 DNS 洩漏，為什麼代理使用者特別在意
當你開啟瀏覽器或 App 時，裝置通常會先把網址中的網域名稱送去 DNS 解析，換成 IP 位址後才真正連線。若這一步發生在未受代理保護的解析路徑上，對外可見的查詢就可能落在 ISP、學校或公司 DNS、路由器轉送等環節，這就是一般所說的 DNS 洩漏。
對代理使用者而言，TCP／UDP 隧道或許已經走節點，但若系統或應用程式仍習慣向「本地網路提供的解析器」發問，對方仍可能依查詢內容推斷你的造訪意圖；若你同時在意地理定位一致性（例如 CDN 節點選擇），錯誤的解析路徑也會讓影片緩衝、下載速度或登入驗證變得不穩定。換句話說，DNS 不只是隱私議題，也會直接影響體感速度與規則命中。
下文以 Mihomo（原 Clash Meta）用戶端為主，說明如何在設定檔中讓「解析」與「分流／隧道」講同一套故事。請在合法合規前提下閱讀與實作；本文僅討論技術設定與風險觀念，不提供規避法律或濫用網路資源的指引。
Clash／Mihomo 如何處理 DNS：先搞懂三個層次
多數圖形介面會把複雜選項藏起來，但心裡若有這三層結構，較不容易被單一開關搞混。
1. 誰在「發起」查詢
可能是瀏覽器、作業系統解析器、或已啟用 TUN／虛擬網卡時由核心攔截的查詢。不同模式之下，第一個接手 DNS 的元件會變，必須對照你實際開的是系統代理、PAC、還是全裝置 TUN。
2. 查詢最後交給誰解析
在 Mihomo 中主要由 dns.nameserver、fallback 與相關過濾條件決定。若這裡指向不可信或與分流策略衝突的伺服器，就會出現「連線已走節點，但解析仍在本地」的錯位。
3. 規則與解析結果是否一致
域名規則依賴正確的解析結果；若你使用 fake-ip，還涉及本機對假位址的對應與還原流程。當規則集與 DNS 模式打架時，常見現象是網頁能開、影片不能播，或解析到錯誤地區的 CDN。此時可搭配本站Rule Providers 進階指南一併檢視規則排序與資料來源。
enhanced-mode：fake-ip 與 redir-host 該怎麼選
dns.enhanced-mode 是 Mihomo 在「域名分流」場景下非常核心的開關，常見取值為 fake-ip 與 redir-host（或介面上對應的中文／英文描述）。
fake-ip 會在本地為域名配置一個「虛擬 IP」，讓連線較早進入核心，以便依域名做細緻規則匹配；對多數訂閱＋規則集使用者來說，這通常帶來較一致的體驗。缺點是少數應用會假設「DNS 回傳的一定是真實公網位址」，若再加上特殊插件或舊版邏輯，可能出現怪異行為，需要改回 redir-host 或調整規則。
redir-host 則較接近傳統「先解析成真實 IP 再走規則」的流程，對某些僅認 IP 的規則較直覺，但在複雜規則下可能較容易遇到「解析與連線路徑不一致」的邊角案例。實務上建議：若你主要依域名規則分流，且用戶端版本夠新，可優先嘗試 fake-ip；若遇到特定 App 異常，再評估改回 redir-host 並重測。
enhanced-mode 或更動 dns 區塊後，建議清掉系統 DNS 快取、重啟用戶端，並用固定測試網站跑一輪對照，避免舊連線殘留造成誤判。
nameserver、fallback 與 fallback-filter
實務上常把「日常解析」與「敏感／跨境解析」拆開：nameserver 處理一般情況，fallback 在觸發條件時接手，避免單一路徑被污染或劫持時整站失聯。
fallback-filter 典型會搭配 geoip 與 geoip-code：當主要解析結果落在特定地理或不可信特徵時，改走備援解析器。請依你的實際所在地與分流目標調整代碼與清單，而不是直接複製網路上的片段；錯誤的 GeoIP 資料庫或代碼會讓「該走 fallback 的沒走、該走主要的卻繞遠路」。
下列為結構示意（請替換成你信任的 DoH／DoT 端點與合理的 geo 設定）：
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- https://dns.example.net/dns-query
fallback:
- tls://dns.example.net:853
fallback-filter:
geoip: true
geoip-code: TW
ipcidr:
- 240.0.0.0/4
domain:
- +.google.com
- +.facebook.com
- +.twitter.com
- +.youtube.com重點不在背誦欄位名稱，而是理解：主要與備援解析器是否都經加密、是否與你的規則語意一致。若 nameserver 仍指向 ISP 提供的明文 DNS，即便隧道啟用，部分查詢仍可能在握手前就先曝光。
DoH／DoT 與「信任邊界」
DNS over HTTPS 與 DNS over TLS 能把解析請求包在加密通道內，降低中途竊聽與竄改的機率。選擇解析服務時，建議同時考量營運主體、日誌政策、節點地理位置與可用性，而不是只看延遲毫秒數。
若你使用訂閱範本，偶爾會遇到預設 DNS 與你的法域或風險承受度不符；此時應以「可審核、可還原」的方式改寫，而不是在多個來源之間來回貼上互相矛盾的片段。完整欄位語意可交叉查閱本站使用文件總覽與上游核心說明。
IPv6、分流與「以為有代理但其實繞路」
IPv6 若在未受控的情況下優先於隧道外建立連線，可能出現看似已連上節點，實際部分流量仍從本地出口離開的狀況。對策方向包括：在系統層確認 IPv6 路由、在核心設定中關閉或對齊你不希望裸露的介面，以及用測試工具分別觀察 IPv4 與 IPv6 的出口。
另一個常見陷阱是「規則寫了 DIRECT，但 DNS 仍走遠端解析」，或相反情形；兩邊敘事不一致時，最容易產生地區判斷錯亂與登入異常。調整時請一次只改一個變因，並保留設定檔備份。
TUN 模式與系統代理：檢查清單
TUN／虛擬網卡通常能涵蓋較多應用程式，但仍要確認沒有硬體或廠商驅動攔截 DNS；系統代理則對「不讀取系統代理」的程式較無約束力。依你的使用情境選模式，然後用下列順序自查：
- 用戶端是否成功載入
dns區塊、是否與tun／listeners設定相容。 - 作業系統「主要 DNS」是否指向 Mihomo 監聽位址，或已由 TUN 正確導流。
- 瀏覽器是否啟用獨立「安全 DNS」而繞過系統；若有，需與整體策略對齊或暫時關閉以利測試。
- 防毒、公司資安代理、其他 VPN 是否插入了自己的解析器。
如何測試是否仍在洩漏
線上測試站點會以不同方式觸發查詢；建議在開啟代理前後各測一次，並固定同一瀏覽器設定以利對照。觀察重點包括：查詢是否仍指向本地 ISP 名稱、是否出現預期外的國家／ASN、以及 IPv6 路徑是否一致。
請留意測試網站本身也有資料處理政策；僅將結果作為粗粒度診斷，並結合本機日誌與核心除錯輸出交叉驗證。若你剛升級用戶端或匯入新訂閱，務必在變更後重跑測試，因為預設值可能隨版本演進而調整。
常見症狀與建議排查順序
若你遇到下列情況，可依序收窄問題範圍：
1. 網頁顯示地區不符或串流無法播放
先確認 DNS 模式與規則是否同一套敘事，再檢查是否有硬編碼的 DIRECT 規則把流量送出隧道，但解析仍指向錯誤區域。
2. 測試站顯示 ISP 仍在解析列表中
回到「誰在發起查詢」：常是瀏覽器安全 DNS、公司代理或路由器 DNS 覆寫。逐一暫停後再測。
3. 只有特定 App 異常
該 App 可能內建 DoH 或固定使用自有解析器；必要時改以 TUN 覆蓋，或接受該 App 不納入統一策略。
開源與上游核心
Mihomo 持續演進 DNS 與規則引擎；若你想核對某欄位在當前版本的精確行為，可至 GitHub 上的 Mihomo 倉庫查閱原始碼與更新日誌。安裝包取得與版本更新仍建議以本站下載頁為主，以減少核心與圖形介面版本不相容的問題。
小結：把 DNS 變成可驗證的隱私防線
DNS 防洩漏的本質，是讓解析路徑與你期望的流量出口在設定上說同一種語言：選對 enhanced-mode、為 nameserver／fallback 建立合理冗餘、在 TUN 或系統代理場景下逐項排除攔截者，並用固定流程重測。相較於只追求單一延遲數字，這種「可重複驗證」的習慣更能長期穩住隱私與體感品質。
若你希望略過手動拼湊核心與預設值的時間，可改用已整合 Mihomo、並對常見 DNS 選項預先梳理過的用戶端；與零散來源拼裝相比，這類組合在升級後也比較不容易出現「規則還在、解析已變」的錯位。建議前往本站下載頁依平台取得安裝包，匯入訂閱後再依本文逐步核對。