配置 2026-10-04 · 約 12 分鐘閱讀

Clash TUN 模式如何避免 DNS 外洩？進階設定與排查實戰

進入 2026 年，Perplexity AI 憑藉其強大的實時搜索與生成能力，已成為許多用戶不可或缺的生產力工具。然而，隨著其風控系統的升級，越來越多的用戶在使用 Clash 代理時遇到了「Access Denied」或無限加載的問題。本文將深度解析其背後的技術原因，並提供一套從基礎規則到進階 TUN 模式的完整配置方案，確保您的 AI 搜索體驗穩定無障礙。

TUN 模式開啟後，DNS 為什麼仍可能外洩？

不少使用者會把「TUN 已啟用」直接等同於「所有 DNS 查詢都由 Clash 處理」，但兩者並非同一件事。TUN 的主要作用是建立虛擬網路介面，接管符合路由條件的 IP 封包；DNS 則還涉及應用程式如何發出查詢、作業系統把查詢交給哪個 DNS 伺服器，以及 Mihomo 如何將查詢送往上游。只要其中一段沒有接上，就可能出現網頁流量走代理、DNS 卻仍交給路由器或網路服務商的情況。

一般的 DNS 查詢使用 UDP 或 TCP 的 53 埠。若作業系統把查詢送往區網閘道，而 TUN 沒有攔截這些封包，或虛擬網卡路由優先順序不正確，查詢便可能直接離開裝置。另一種常見情況是瀏覽器啟用了「安全 DNS」、DNS over HTTPS（DoH）或其他 DNS 外掛。這類查詢通常走 HTTPS 的 443 埠，單靠攔截傳統 53 埠無法識別它是 DNS；它會被當成一般網頁連線，依照 IP、網域規則或瀏覽器自己的代理設定處理。

因此，排查時要分清三個環節：裝置是否把封包交給 TUN、DNS 查詢是否進入 Mihomo 的 DNS 模組，以及上游解析請求最後走直連還是代理。這三者任何一處不符合預期，都可能產生 DNS 外洩、解析結果不一致，或部分網域無法連線。TUN 負責接管流量，DNS 設定負責處理查詢，路由規則則決定查詢與後續連線的出口，不能只檢查其中一項。

先建立正確預期

Fake-IP 可以協助 Mihomo 將網域解析與後續連線關聯起來，但它不是加密 DNS，也不會自動修補系統路由、瀏覽器 DoH 或其他 VPN 的設定。避免外洩需要 TUN、DNS 接管、上游路由與 IPv6 行為彼此配合。

Mihomo DNS 設定：Fake-IP、上游與規則路由

開始調整前，先確認用戶端實際使用的是 Mihomo 核心，並檢查訂閱或覆寫設定是否會在更新時重置自訂內容。不同版本與圖形介面的欄位名稱可能略有差異；下方設定是用來說明常見選項之間的關係，不宜不加檢查地整段貼入既有設定檔。套用前應先備份原檔，並以目前核心版本的設定檢查結果為準。

dns.enable 用來啟用 DNS 模組；listen 指定本機 DNS 監聽位址與埠；enhanced-mode: fake-ip 選擇 Fake-IP 模式。若要讓進入 TUN 的傳統 DNS 封包交由核心處理，通常還要在 TUN 設定中配置 DNS hijack。請勿任意把監聽位址暴露到區域網路：若沒有分享 DNS 服務的需求，應依用戶端的執行方式選擇適當的本機監聽設定，避免其他裝置不必要地存取。

tun:
  enable: true
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  respect-rules: true
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query
  fake-ip-filter:
    - "*.lan"
    - "localhost"

這段範例的重點不是固定使用哪一家 DNS，而是各選項的分工。dns-hijack 針對傳統 53 埠查詢；它不會自動攔截所有以 DoH 發出的 HTTPS 請求。respect-rules: true 讓 DNS 上游連線依規則決定出口，但上游本身的網域或連線也需要能正確解析與建立。若代理節點的伺服器名稱需要先解析，proxy-server-nameserver 可提供核心建立代理連線所需的解析來源；務必避免讓這個啟動階段的查詢繞回尚未建立的代理路徑，造成循環依賴。

nameserver-policy 可依網域指定解析服務，適合需要讓特定網域使用指定上游的情況。設定時應使用核心支援的網域匹配格式，並測試子網域是否符合預期；不要假設一條規則必然涵蓋所有相似網域。若同時維護 nameserver、fallback 和 policy，應先確認各欄位的作用與優先順序，再逐步加入，避免同一網域收到不同來源的答案。

fake-ip-filter 則用來讓某些網域不使用 Fake-IP，常見用途包括區域網路名稱、需要取得實際地址的服務，或在特定環境中有相容性問題的網域。清單不宜過度擴張；若把常用網域大量排除，便可能讓解析更依賴系統 DNS，增加路徑判斷的複雜度。調整時一次新增一個必要項目，並記錄變更前後的解析結果。

注意 DNS 監聽埠與用戶端功能

部分圖形用戶端會自動管理 TUN、DNS 劫持或設定合併；手動加入相同欄位可能造成重複、覆寫或核心啟動失敗。若用戶端有「DNS 劫持」「覆寫 DNS」等選項，先確認它實際生成的核心設定，再決定是否需要自行新增對應項目。

動手操作：逐步確認 DNS 是否進入 TUN

建議以「先驗證接管，再驗證解析，再驗證出口」的順序操作。不要同時更換上游 DNS、切換 Fake-IP、改代理規則和關閉 IPv6，否則即使問題消失，也很難知道真正原因。每次只改一項，並在每次修改後重新載入設定檔或重啟核心，確認新的設定確實生效。

  1. 備份並確認核心版本。在用戶端的設定或日誌頁面查看核心類型與版本，匯出目前設定檔。確認自訂設定是寫在用戶端支援的覆寫區域，而不是只改了會在訂閱更新時被替換的暫存檔。
  2. 確認 TUN 已建立並取得路由。在用戶端啟用 TUN，依系統提示授權管理員權限或建立虛擬網卡。查看核心日誌是否有介面建立、路由安裝成功的訊息；若出現權限不足、介面建立失敗或路由衝突，先處理這些錯誤，不要急著改 DNS 上游。
  3. 確認 53 埠查詢有被處理。保留一個容易辨認、且之前未查詢過的網域進行測試，同時查看 Mihomo 日誌或用戶端的連線紀錄。若紀錄中完全沒有對應 DNS 活動，應檢查 TUN 的 DNS hijack、作業系統路由和用戶端是否真的套用了目前設定。
  4. 比較不同網域的解析結果。選一個一般網站、一個需要代理的網域和一個區域網路名稱，分別記錄查詢結果與連線行為。Fake-IP 模式下，系統工具顯示的地址可能屬於設定的 Fake-IP 網段，不能單憑「不是網站的公開 IP」就判斷外洩；應同時查看核心的 DNS 與連線紀錄。
  5. 確認上游請求的出口。檢視連線紀錄或核心日誌，核對 DNS 上游連線是否依照預期走代理或直連。若設定了 respect-rules，也要確認對應規則沒有將上游、解析服務網域或必要的節點連線送進錯誤策略組。
  6. 重新測試瀏覽器 DoH。暫時查看瀏覽器的安全 DNS 設定，記錄目前是否啟用及所使用的服務。可以在受控測試期間關閉瀏覽器自訂 DoH，再重複同一組查詢；若結果因此改變，問題可能在瀏覽器的 DNS 路徑，而不只是 Mihomo 的 53 埠接管。
  7. 逐項檢查 IPv6 並復原測試設定。確認 TUN、系統介面和 DNS 上游對 IPv6 的處理是否一致。測試期間可依需求暫時排除 IPv6 作為變因，但不要把永久停用 IPv6 當成通用修復；完成後逐項恢復，確認問題在哪個設定改動時重現。

測試時最好使用相同裝置、相同網路和相同網域，並記下時間、解析結果、命中的規則與節點。若用戶端有 DNS 快取或作業系統快取，重複查詢可能直接取得舊答案，造成「設定已改但結果沒變」的錯覺。遇到這種情況，可依系統與用戶端文件清除快取或重啟相關服務，再以新的網域重新測試；不要只依賴一次網頁載入結果下結論。

DNS 外洩與分流失效的排查方法

先觀察問題範圍：如果所有網域都解析失敗，優先檢查 DNS 模組是否啟用、監聽埠是否被占用，以及核心是否成功載入設定；如果只有個別網域失敗，則檢查 nameserver-policy、Fake-IP 排除清單、網域規則和策略組。若網頁能開啟但測試網站顯示外部 DNS，則需要再確認測試頁面測到的是傳統 DNS、DoH、IPv6 解析，還是其他應用程式自行指定的解析服務。

觀察到的現象 優先檢查項目 建議驗證方式
核心日誌沒有 DNS 查詢 TUN 路由、dns-hijack、應用程式是否自行使用 DoH 查看虛擬介面狀態，暫停瀏覽器自訂 DoH 後重測
部分網域解析到意外結果 nameserver-policy、規則匹配、DNS 快取 用新網域測試，逐項停用可疑 policy 驗證
IPv4 正常，IPv6 網站仍直連或失敗 IPv6 路由、TUN 接管範圍、AAAA 查詢與出口規則 分別測試 IPv4 與 IPv6 可達性，核對連線日誌
開啟 respect-rules 後節點無法連線 代理節點名稱解析、bootstrap DNS、上游路由循環 檢查代理伺服器名稱是否能在代理建立前解析

Fake-IP 模式下，作業系統可能看到的是 Fake-IP 位址；這是預期行為之一，應再從 Mihomo 的連線紀錄確認該地址是否對應到正確網域，以及後續連線命中了哪條規則。反過來說，即使 DNS 測試網站顯示的解析服務看起來正常，也不代表所有應用程式都使用同一路徑；瀏覽器、遊戲、容器或自行指定 DNS 的程式可能各有設定。測試結果應與核心日誌、系統路由和應用程式設定交叉比對。

IPv6 是容易被忽略的另一條路徑。即使 IPv4 已由 TUN 接管，若系統仍有可用的原生 IPv6 預設路由，而 TUN 或規則沒有處理 IPv6，部分應用可能透過 IPv6 直接連線。這不一定表示 DNS 查詢本身外洩，但可能造成連線繞過代理，看起來像 DNS 分流錯誤。應檢查虛擬網卡是否接管 IPv6、設定檔是否啟用 IPv6，以及網路環境是否提供原生 IPv6；若服務或客戶端不支援完整 IPv6 代理，需按實際需求調整，並在每次變更後重新測試。

如果日誌出現上游連線逾時，先判斷是 DNS 伺服器無法連線，還是規則把它送往不可用的出口。可以暫時使用一個已知可用的解析服務進行對照，但不要在診斷完成後留下未經確認的公共 DNS 設定。若使用加密 DNS，也要確認 TLS 憑證驗證正常、伺服器名稱可解析，且服務端點沒有被其他規則誤判為需要經過同一個尚未建立的代理。

判斷外洩時不要只看單一測試網站

線上 DNS 測試通常只能呈現測試當下可觀察到的解析服務，結果會受瀏覽器 DoH、快取、IPv6、網路環境及測試站點演算法影響。較可靠的做法是以同一組網域同步比對核心 DNS 日誌、連線紀錄、系統路由與瀏覽器設定，再判斷查詢實際離開裝置的路徑。

Clash TUN 與 DNS 常見問題

啟用 Fake-IP 就能完全避免 DNS 外洩嗎？

不能。Fake-IP 是一種解析與網域關聯方式，不等於加密 DNS，也不會自動接管瀏覽器 DoH、其他應用程式指定的 DNS 或未納入 TUN 路由的 IPv6 流量。仍需確認 DNS 模組、TUN 劫持、上游出口和應用程式設定。

什麼情況下需要開啟 respect-rules？

當您希望 DNS 上游連線也依照 Clash 規則選擇出口時，可評估使用此選項。啟用後應檢查代理節點名稱的解析來源與啟動順序，並確認上游連線沒有形成循環依賴。若核心版本或用戶端的設定合併方式不同，請先以實際生效設定和日誌驗證。

瀏覽器開啟安全 DNS，TUN 還有用嗎？

仍然有用，但傳統 53 埠的 DNS hijack 不會因此自動攔截瀏覽器的 DoH。DoH 通常使用 HTTPS 連線，可能按一般連線規則處理。若要求瀏覽器解析也遵循同一套路徑，應檢查瀏覽器的安全 DNS 設定、代理設定和核心連線紀錄，不要假設 TUN 會辨識所有加密 DNS 請求。

為了避免外洩，是否應永久停用 IPv6？

不一定。停用 IPv6 有時可作為定位問題的短期對照測試，但也可能影響依賴 IPv6 的服務。更合適的做法是確認 TUN 與規則是否完整處理 IPv6；只有在目前核心、用戶端或網路環境無法可靠代理 IPv6 時，才依自身需求採取限制措施，並記錄設定影響。

有些只提供簡單系統代理開關的工具，在 TUN、DNS 路由和 IPv6 同時參與時，可能難以清楚呈現每筆查詢的處理路徑；Mihomo 搭配 Clash 圖形用戶端則可集中管理核心設定、規則與日誌，方便逐項驗證。若您想更直接地查看流量走向並測試本文提到的設定，可前往 下載 Clash，開始測試。

準備好恢復您的 AI 工作流了嗎？

獲取 2026 最新版 Clash，內建優化分流規則，一鍵解決 Perplexity 與 ChatGPT 存取難題。

免費下載 Clash（Windows / macOS）