mihomo DNS 設定詳解：nameserver、fallback 分組與 fake-ip 劫持設定

先確認 DNS 請求的處理路徑

設定 mihomo DNS 前，先釐清三個環節：應用程式將查詢交給誰、mihomo 使用哪個上游 DNS 解析，以及最後的連線依照什麼規則轉送。將 nameserver 換成加密 DNS，只會改變中間這個環節；如果瀏覽器仍使用自己的安全 DNS，查詢可能根本不會進入 mihomo 的 DNS 模組。

本文適用於由 Clash Meta 持續發展而來的 mihomo 核心。不同客戶端可能會在介面中覆寫 DNS 或 TUN 欄位，因此應以實際載入的執行設定為準，而非只看訂閱原始檔。舊版 Clash 核心不一定支援本文提到的所有欄位。

備份目前的設定，記下系統代理、TUN、DNS 覆寫三個選項的狀態。
查看客戶端的核心資訊，確認目前執行的是 mihomo，不要只憑客戶端名稱判斷。
先透過本機 127.0.0.1:1053 測試解析，再決定是否啟用 TUN 接管。
每次只調整一組欄位；重新載入後先檢查記錄，再測試同一個網域。

nameserver 與 default-nameserver：先讓最小設定正常運作

以下是可合併至現有設定的 DNS 範例，不是完整的代理訂閱。內容不包含節點和規則，也不需要刪除原有的 proxies、proxy-groups 或 rules。設定中只保留一個頂層 dns:，將欄位合併其中，避免重複鍵造成載入結果不明確。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "localhost"
    - "*.lan"
    - "*.local"
    - "+.home.arpa"
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query

欄位	此設定的作用
`enable`	啟用 mihomo 內建的 DNS 模組。
`listen`	在本機迴環位址的 1053 埠接收 DNS 查詢，不對區域網路開放。
`default-nameserver`	解析上游 DNS 服務的網域名稱，避免一開始就無法取得 DoH 伺服器的位址。
`nameserver`	設定一般解析使用的上游；範例採用兩個 HTTPS DNS 位址。
`ipv6: false`	在 DNS 模組中，對 AAAA 查詢回傳空結果，方便先排查 IPv4 連線；這不會停用作業系統的 IPv6。

不要把上游清單視為固定的主要／備援順序

nameserver 列出兩個項目，不代表「第一個失敗後才使用第二個」。核心可能會同時查詢並採用可用的回應，不應依賴清單順序實現嚴格的主備切換。先選擇目前網路確實連得上的上游，再考慮延遲；加入十幾個位址通常只會增加排查變數。

default-nameserver 也不是「所有網站預設都從這裡解析」。它主要用來解析 DNS 服務本身的網域名稱。範例使用 IP 位址進行引導解析，但後續改用 DoH，不會讓這些初始查詢自動變成加密查詢。

fallback 與 fallback-filter：依結果篩選，不只是逾時備援

fallback 是另一組解析上游，不是代理策略群組，也不會建立可供選擇節點的群組。設定同時包含 nameserver 和 fallback 時，核心可能會並行解析，並依據 fallback-filter 判斷是否採用 fallback 的結果。若將它理解成「主要 DNS 逾時才啟用的備援 DNS」，很容易誤判查詢流量。

需要依 IP 地理位置篩選結果時，可將以下欄位合併到前面同一個 dns: 區塊。請先確認這些上游在目前網路中都連得上；填入無法連線的 DoH 位址，不會自動解決 DNS 污染或連線問題。

  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

透過這三個條件理解篩選流程

地理位置條件：啟用 geoip: true 並設定 geoip-code: CN 後，若一般解析結果不屬於指定地區，系統會傾向採用 fallback 結果。這裡檢查的是解析出的 IP 位址，而非網域後綴。
位址範圍條件：ipcidr 用來標示應排除的一般解析結果位址範圍。範例中的 240.0.0.0/4 是明確的篩選條件，不是網站流量的代理路由。
資料依賴：GeoIP 判斷取決於核心使用的地理位置資料。資料缺失、過舊，或 CDN 位址的歸屬變更，都可能影響選擇結果。

這套機制無法保證「中國大陸網域使用中國大陸 DNS，其他地區網域使用海外 DNS」。網域可能部署在多個地區，CDN 也可能回傳不同位址。若要為內部業務網域或已知服務進行明確分流，使用 nameserver-policy 會比依賴地理位置判斷更直接。

nameserver-policy：為指定網域選擇解析上游

辦公室網路、家用 NAS 和印表機常使用只有內部 DNS 才能解析的名稱，這類網域不適合交給公共解析器。以下以家庭網路為例：只有在路由器位址確實是 192.168.1.1，而且能解析 home.arpa 的內部記錄時，才使用這段設定。

  nameserver-policy:
    "+.home.arpa":
      - 192.168.1.1

這仍是要合併至現有 dns: 的局部欄位。符合條件的網域會依照此策略選擇上游，不要假設它會完整沿用一般 nameserver/fallback 的篩選流程。這裡的 +.home.arpa 用來匹配該網域及其子網域；改用公司內部網域前，請先向網路管理員確認解析伺服器和存取需求。

nameserver-policy 和 fake-ip-filter 解決的是不同問題：前者決定向哪個上游查詢，後者決定是否向應用程式回傳假位址。為內部網域設定 DNS 策略後，如果裝置探索或直連服務仍需要真實 IP，也應將相應網域加入 fake-ip 排除清單。

fake-ip 與 redir-host：回傳假位址還是真實位址

enhanced-mode 控制 DNS 增強模式。fake-ip 會回傳一個保留位址範圍內的映射位址給應用程式；連線再次進入 mihomo 時，核心會依映射還原網域名稱，再執行規則及出口處理。這個位址不是網站的真實伺服器位址，也不能交由未經 mihomo 處理的裝置直接連線。

比較項目	fake-ip	redir-host
應用程式收到的 A 記錄	通常是設定位址池中的映射位址	實際解析取得的位址
網域關聯	透過假位址映射保留網域資訊	依賴 DNS 快取關聯等機制還原網域
連線要求	連向假位址的連線必須回到對應的 mihomo 執行個體	取得真實 IP，但連線仍須依預期進入代理或路由鏈路
常見相容性問題	區域網路探索、需要驗證真實 IP 的應用程式、繞過接管的連線	共用 IP、快取關聯及應用程式自帶 DNS 造成的網域識別限制

何時加入 fake-ip-filter

區域網路網域，以及需要真實位址的裝置探索服務，可以先加入排除清單。在預設的黑名單式篩選下，符合清單的網域不會回傳 fake-ip，而是依真實位址解析。不要把所有網域都加進去，否則雖然設定仍使用 fake-ip，實際效果卻會大幅改變。

如果只有某個應用程式異常，先排除它所依賴的特定網域，不要立刻切換全域模式。切換到 redir-host 後，應清除客戶端 DNS 快取並重新啟動相關應用程式；必要時也要清除系統 DNS 快取。修改 YAML 後，舊的 198.18.x.x 記錄不會立刻從所有應用程式中消失。

TUN DNS 劫持：接管傳統 53 埠查詢

此處的 DNS 劫持，是將通過 TUN 的指定 DNS 流量交由 mihomo DNS 模組處理，並非修改遠端網站的 DNS 記錄。桌面系統若要接管未使用系統代理的應用程式，通常須先正確啟用 TUN 路由，再設定 DNS 劫持。

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

any:53 用於匹配通過 TUN 的 UDP 53 查詢，tcp://any:53 則補上 TCP 53。auto-route 用於自動設定路由，auto-detect-interface 用於偵測出口介面。實際接管範圍仍受作業系統、路由和客戶端實作影響，不能只憑這段 YAML 判斷所有 DNS 都已被接管。

確認權限：桌面客戶端通常需要服務模式或相應的管理員權限，才能建立虛擬網卡和路由。請先檢查權限錯誤，再調整 DNS 欄位。
區分埠號：listen: 127.0.0.1:1053 是明確指定的查詢入口；TUN 對 53 埠的劫持由核心處理，不需要將系統 DNS 位址設為包含 1053 的字串。
檢查加密 DNS：DoH 通常使用 443 埠，DoT 通常使用 853 埠。只匹配 53 埠無法強制接管這些連線；排查時可暫時關閉瀏覽器的「安全 DNS」進行比對測試。
避免開放解析服務：只有確實要為區域網路裝置提供 DNS 時，才考慮監聽區域網路位址，並同時設定防火牆。不要為了方便測試就直接對公網開放。

Android 客戶端通常透過系統 VPN 介面接管流量，桌面版的自動路由欄位不一定適用；iOS 客戶端也會受到自身網路延伸功能實作限制。不要將桌面 TUN 區塊直接複製到所有平台，請優先使用客戶端提供的 VPN、DNS 和略過設定。

驗證與排錯：分別檢查解析、接管和連線

第一步：直接查詢本機 DNS

啟用設定後，在已安裝 dig 的系統上執行以下兩個指令。第一個查詢 UDP，第二個查詢 TCP，用來確認本機 DNS 入口是否有回應。由於指令明確指定了伺服器，因此不能單憑測試結果證明系統 DNS 已由 TUN 接管。

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com A +tcp

Windows 可使用系統內建的 nslookup，指定測試埠：

nslookup -port=1053 example.com 127.0.0.1

在 fake-ip 模式下，未被篩除的一般 A 查詢通常會回傳 198.18.0.1/16 位址池中的位址；這只能證明目前查詢使用了假位址映射，不能證明上游的真實解析和代理出口都正常。符合排除清單的網域，則應依真實解析路徑檢查。

第二步：確認連線回到同一個核心

開啟客戶端的連線面板，瀏覽 HTTPS 網站，檢查面板中是否出現相應網域。
確認連線命中預期規則，並查看最終出口是 DIRECT 還是代理策略中的節點。
若解析結果是 fake-ip，卻沒有連線記錄，請優先檢查 TUN、路由和應用程式的略過設定。
若連線已進入核心卻逾時，請再檢查節點、規則與上游連線，不要反覆更換 DNS 模式。

第三步：依症狀縮小排查範圍

症狀	優先檢查項目	下一步操作
本機 1053 查詢逾時	DNS 是否已啟用、設定是否載入，以及埠是否遭占用	查看啟動記錄，確認監聽位址後重新查詢
DoH 記錄出現 TLS 錯誤	系統時間、憑證、上游連線狀態與引導解析	校正時間並測試單一上游，不要停用憑證驗證來掩蓋問題
網頁能使用，但 NAS 網域無法解析	內部 DNS 策略與 fake-ip 排除設定	為內部網域指定路由器 DNS，並檢查是否需要真實位址
修改設定後結果沒有變化	客戶端覆寫、訂閱更新、應用程式與系統快取	核對執行設定、重新載入並清除快取
只有瀏覽器的結果不同	瀏覽器安全 DNS、代理擴充功能、獨立快取	暫時關閉相關功能，使用同一個網域進行比對測試

Windows 可執行 ipconfig /flushdns 清除系統解析快取，但瀏覽器和應用程式仍可能保留自己的記錄。分享診斷記錄時，保留時間、錯誤類型和相關欄位即可，請刪除訂閱 URL、認證資訊及敏感的內部網域。

最後，將確認有效的 DNS 調整放入客戶端支援的覆寫或合併設定入口，避免訂閱更新後遺失。請保留「最小可用設定」和「目前設定」兩份記錄；發生故障時先還原，再逐項恢復 fallback、網域策略和 TUN 接管，比一次修改所有選項更容易找出原因。若想了解設定檔與代理規則的整體關係，請繼續查看完整手冊。