Mihomo redir-host DNS 怎麼設？
nameserver 與 fallback 分步 YAML 指南（Clash Meta）

1 步驟一：啟用 dns、指定 enhanced-mode: redir-host 與 listen

在根層級（與 port、proxy-groups 同級）加入或合併下列骨架。重點有三：enable 必須為真，否則後面欄位不生效；enhanced-mode 設為 redir-host 以對齊本文情境；listen 指定 Mihomo 內建 DNS 監聽位址，常見是 127.0.0.1:53 或其他未占用埠（若 53 已被系統占用，就改成 1053 等並在作業系統層做轉發或 hijack——細節見後文 TUN 小節）。下列片段中的上游位址一律為示意，請換成你實際可用、且符合服務條款的伺服器。

# Skeleton — replace upstreams; match field names to your Mihomo build
dns:
  enable: true
  listen: "[::]:1053"
  ipv6: false
  enhanced-mode: redir-host
  use-hosts: true

ipv6 是否關閉視你的網路環境而定：若在雙疊網路裡常見 AAAA 優先卻又沒有完整 IPv6 路由，暫時關閉有助於把問題收斂到 IPv4；若你在純 IPv6 或需要完整雙疊的場景，請改回與環境一致。use-hosts 讓核心尊重系統 hosts，對本機開發或內網測試通常保留為真較直覺。

2 步驟二：填好主鏈 nameserver（誰負責「首輪」）

nameserver 可以是純清單，也可以拆成「策略條目」；初學者最穩的是先用明確序列：先放延遲低、你可稽核的明文 DNS（UDP／TCP），再放加密上游。理由很現實：當你的環境尚未校正好 hijack 或路由時，過早全面依賴 DoH 可能讓啟動順序變得難以觀察。待主鏈穩定後，再把 DoH／DoT 放回同一清單做替換或增補。若你有「特定網域一定問誰」的需求（例如公司內網域只能 corporate resolver），應改用下一節的 nameserver-policy，不要把全球都硬塞同一台上游。

dns:
  enable: true
  listen: "[::]:1053"
  enhanced-mode: redir-host
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
    - "https://dns.alidns.com/dns-query#h3=true"

上面示範混合明文與 DoH：#h3=true 分段在部分版本用於偏好 HTTP/3；若你的構建不支援，刪去修飾符即可。重點是順序與語意：與你規則中「直連」「國內站」的期待一致時，首輪解析才會給規則一個「在地」的答案，而不是一開始就把查詢送上境外供應商，導致 瀏覽器安全 DNS 或多出口環境下的錯亂體感。

3 步驟三：default-nameserver（bootstrap：先幫 DoH 主機名找 IP）

當 nameserver 含 https:// 或 tls:// 這類需要先解析「伺服器主機名」的條目時，核心必須先有一組不經過該加密通道本身就能工作的上游，否則會出現典型的「雞生蛋」：要連 DoH 卻還沒有 DoH 的 IP。default-nameserver 就是這個用途——常被稱作 bootstrap。實務上可放運營商自動下發的 DNS、閘道器、或你信任的兩台明文 IP。請避免把已被劫持風險極高的來源當唯一 bootstrap，否則加密鏈路一開始就可能被導向假節點。

dns:
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29

若你整條主鏈都只用明文 IP 形式的 UDP／TCP DNS，bootstrap 壓力會小很多；但一旦引入加密上游，請把 default-nameserver 視為必修欄位而不是可選裝飾。

4 步驟四：fallback 與 fallback-filter（什麼結果觸發第二意見）

fallback 清單裡放的是「當主 nameserver 的結果被視為需要覆核時」要再諮詢的上游。實務上常放一組你更信任、或地理位置／政策邊界更符合「境外解析語意」的伺服器。fallback-filter 則用 geoip、geoip-code、ipcidr、domain 等條件描述「哪些情況下不要採納首輪」或「哪些情況一定要聽備援」。下面是一段教學用範例：把中國大陸語意寫入過濾，讓境內解析結果不會動輒被第二輪覆蓋；細節鍵名請以你的 GeoIP 資料來源與版本為準。

dns:
  nameserver:
    - 223.5.5.5
    - "https://dns.alidns.com/dns-query"
  fallback:
    - "https://1.1.1.1/dns-query#DNS&Verify"
    - "tls://8.8.4.4:853"
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
    domain:
      - "+.google.com"
      - "+.facebook.com"
      - "+.youtube.com"

範例裡 #DNS&Verify 類註解尾碼在部分教學裡用作 TLS／SNI 行為提示，實際可用性以你的核心與上游支援為準；若貼上後無法連線，先退回最保守的 https:// URL 或明文 IP DoH。重在理解行為層級：fallback-filter 讓「境內常見解析」與「跨網情境」分流對待，降低 redir-host 模式下首輪就被送到不合語意的上游的機率。

5 進階：nameserver-policy 把「網域→上游」寫死在 DNS 層

當規則已經寫了 DOMAIN-SUFFIX,internal.corp,DIRECT 卻仍解析失敗，常見原因不是規則沒生效，而是DNS 沒有把 private suffix 送到能答的伺服器。nameserver-policy 讓你在查詢早期就把指定後綴導向專用上網：公司 resolver、區網 Pi-hole、或僅在內網路由可達的 IP。對 redir-host 特別關鍵，因為規則看到的是「真實解析」，錯上游等於永遠拿不到正確內網位址。

dns:
  nameserver-policy:
    "geosite:cn":
      - 223.5.5.5
      - 119.29.29.29
    "+.lan":
      - system
    "+.internal.corp":
      - 10.0.0.53

其中 geosite:cn 類條目仰賴你資料庫是否更新；可參考 GeoIP／Geosite 手動更新 以免規則與資料庫版本漂移。system 類型若在你所用構建不可用，改成實際 IP。system 或 OS 層委派在桌面環境會與 Linux systemd-resolved stub 互動，請確保 hijack 鏈與 stub 不打架。

6 與 TUN、dns-hijack、系統 stub 的邊界

redir-host 模式只做「在核心內部如何回答 DNS」，但應用程式實際把查詢送到哪裡仍受作業系統解析堆疊控制。若系統仍把流量丟向 127.0.0.53 或路由器 DNS，而你的 hijack 規則未涵蓋這條路徑，核心內再漂亮的 nameserver 也接不到查詢。請把本文與 Verge Rev 的 TUN 指南、以及 Linux 上 systemd-resolved 對照文 一齊閱讀：YAML 與 netfilter／路由層級要同時對齊，而不是只做其中一半。

7 驗證：靠日誌與對照實驗，別只用感覺判斷「DNS 壞了」

建議流程：先把 log-level 暫調到能看見 DNS 相關訊息的級別（完成後記得降回，以免刷屏）；再挑三個域名樣本——一個確定應該境內優化、一個確定應該走代理語意的境外大站、一個內網或本機別名。分別觀察首輪是否命中預期上游、何時觸發 fallback、以及最終回覆與規則表是否一致。若你需要更細的連線與策略對照，可延伸閱讀 Clash Meta 連線日誌與 DNS 規則，把「解析錯」與「規則錯」「節點錯」拆開。

1. 改動前將整份 config.yaml 備份到帶時間戳的檔名。
2. 每次只動一個子區塊（先 nameserver、再 fallback、最後 filter），避免多變因數疊加。
3. 重載後用同一組域名重複測試，確認行為可重現，而不是僅僅「剛剛好那次快取命中」。

8 常見問題（與頁內 FAQ 結構化資料對齊）

問：我可以完全不要 fallback，只留 nameserver 嗎？
可以，這等於接受「永遠只採納第一組世界觀」。在網路乾淨、上游可信、且無跨境語意衝突時足夠；一旦遇過污染或 CDN 異常，就會缺少第二意見。

問：redir-host 下還要不要開 fake-ip-range？
一般情況不需要也不應混用兩種 enhanced 語意；若你見到範本帶 fake-ip-range，多半複製自 fake-ip 教學文，請對照官方文件刪除或還原，避免行為未定義。

問：加密 DNS 會不會讓我看不到審計紀錄？
會，對外可見性下降是換取完整性與抗篡改的代價；企業環境請先與資安政策對齊，不要私下覆寫公司 DNS。

9 總結

Mihomo 在 redir-host 模式下要寫好 nameserver、default-nameserver、fallback 與 fallback-filter，核心目標是讓「首輪解析語意」與你的分流哲學一致，並在異常或跨境場景保留可預測的第二意見。這比到處複製別人的 Fake-IP 範本更需要理解層級關係，但一旦拆開，長期維護成本通常更低，也較少遇到「規則表面正確、底層 IP 其實早被換過」的挫折。

市面上不少泛用 VPN或輕量代理工具把 DNS 藏在一個總開關後面，遇到 redir-host 這類要細分主鏈與備援的情境時，要嘛完全不給 YAML 透明度，要嘛只能整包關閉加密解析，除錯時很難對照；也有些圖形介面會把 fallback-filter 摺疊成不容易察覺的預設值，導致你在 UI 上看起來「已設定 DoH」，實際上備援從未按預期觸發。Clash Verge Rev 這類直接綁定 Clash Meta／Mihomo、支援完整設定檔與覆寫的用戶端，通常能把 dns 區塊維持在可版本控制狀態，並與 TUN、hijack、訂閱更新在同一視圖內管理。若你希望把本篇 YAML 片段穩定跑在主力機上，不妨從本站 下載頁取得與教學命名一致的安裝來源，再把 DNS 與規則放在同一個可還原的備份流程裡。

→ 前往下載頁取得 Clash Verge Rev（Mihomo 核心）