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

先釐清 DNS 上游、回應模式與請求接管

mihomo 的 DNS 設定分為三個層次：由誰接收請求、向哪個上游查詢，以及回傳什麼位址給應用程式。nameserver 與 fallback 負責上游解析；enhanced-mode 決定使用真實位址或 fake-ip 對應；tun.dns-hijack 則負責將符合條件的 DNS 流量導入內建解析器。這三個層次彼此相關，但不能互相取代。

只在設定檔中填入 DNS 位址，不代表瀏覽器就會使用它。系統仍可能向路由器查詢，瀏覽器也可能透過自己的 DoH 進行加密解析。排查時應先確認請求是否進入 mihomo，再檢查上游是否可用。

nameserver 與 default-nameserver：解析上游與引導解析

nameserver 是預設使用的 DNS 上游清單。位址可使用一般 DNS、DoH 等支援的格式。一般 DNS 範例為 223.5.5.5，DoH 範例為 https://dns.alidns.com/dns-query。DoH 會加密與解析伺服器之間的查詢傳輸，但不會自動讓應用程式的連線透過代理。

為什麼還需要 default-nameserver

上游位址使用網域名稱時，核心必須先取得該伺服器的 IP。例如連線至 dns.alidns.com 前，必須先解析這個網域本身。default-nameserver 用於這類引導解析；指定明確的 IP 位址，可避免「解析 DNS 伺服器還得先連上同一台 DNS 伺服器」的循環。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query

• 127.0.0.1:1053 僅供本機使用，不會將 DNS 服務開放給區域網路中的裝置。
• redir-host 會將實際解析位址回傳給應用程式，適合作為第一輪連線測試的基準。
• ipv6: false 會讓內建 DNS 對 AAAA 查詢回傳空結果，但不代表關閉作業系統的 IPv6，也不會阻止應用程式直接連線至已有的 IPv6 位址。
• 清單中填入多個上游，不代表會「嚴格依照由上而下的順序逐一嘗試」。請勿依賴排列順序來分流網域。

以上是獨立的 dns 設定範例，不包含節點與代理規則。請將它合併至現有設定中，而非用來取代整份訂閱。如果目前網路封鎖了某個解析服務，請改用實際可連線的上游。

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

fallback 這個名稱容易讓人以為它只會在 nameserver 故障時運作。實際上，設定 fallback 後，核心可以同時向兩組上游查詢，再依據 fallback-filter 判斷採用哪一方的結果。因此，正常連線時看到 fallback 查詢，不一定代表主要上游已經故障。

常見做法是讓主要上游處理適用於本地網路的解析結果；若網域指定使用 fallback，或主要上游回傳的位址不符合篩選條件，就採用 fallback 的解析結果。這個流程處理的是 DNS 回應的選擇，後續連線仍須比對代理規則。

GeoIP 與位址範圍篩選範例

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
  fallback:
    - https://dns.google/dns-query
    - https://cloudflare-dns.com/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
    domain:
      - '+.google.com'

• 搭配使用 geoip: true 與 geoip-code: CN，透過 GeoIP 資料判斷主要上游回傳的位址是否屬於指定地區；若不符合，便傾向採用 fallback 的結果。
• 主要上游回傳的位址若符合 ipcidr 清單中的項目，就會觸發使用 fallback。範例中的 240.0.0.0/4 是位址篩選條件，不是節點網段或 TUN 位址池。
• 符合 domain 的網域會直接使用 fallback 的解析結果；+.google.com 表示符合該網域及其子網域。
• GeoIP 判斷取決於核心使用的資料。資料庫過舊或 CDN 採用跨區域部署，都可能導致實際選擇與預期不同。

不要把所有私有網路位址都視為遭污染的結果。企業內網網域回傳 10.0.0.0/8、家用裝置回傳 192.168.0.0/16 都可能是正常情況。若把這些範圍全部加入 ipcidr，反而會讓內部網域被送往公網解析。針對明確的內網網域，應優先考慮指定解析，而不是擴大 fallback 篩選範圍。

fake-ip 與 redir-host：回傳對應位址或實際位址

enhanced-mode: fake-ip 會從位址池中為網域配置一個對應位址。應用程式收到位址後發起連線，流量進入 mihomo，核心再透過對應關係還原網域並比對規則。這能減少對應用程式端真實 IP 解析的依賴，但前提是這些連線確實由核心接管。

redir-host 則會回傳實際解析位址，並保留相關網域資訊。它的行為較接近一般 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'
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query

fake-ip-filter 應加入哪些網域

在一般的黑名單篩選模式下，符合 fake-ip-filter 的網域不會配置 fake-ip，而是回傳實際位址。範例用來說明本機與區域網路名稱的例外處理；若設定另外指定了 fake-ip-filter-mode，請先確認篩選模式，不能直接套用本文所述的含義。

• 區域網路裝置探索、部分遊戲或需要取得真實 IP 的應用程式，可依個別網域加入例外，避免直接加入範圍過大的萬用字元規則。
• 篩選只會改變回應方式，不會自動將 printer.lan 交由路由器解析。內網名稱仍需要交給能解析它的本地上游。
• .local 通常與 mDNS 有關。將它加入篩選清單，不代表 mihomo 會代理多點傳送探索，也不會自動修復投放畫面的問題。
• 不要只因為看到 198.18.x.x 就認定解析結果遭到污染。在這個範例中，這是預期的 fake-ip 回應；真正的檢查重點是連線能否進入核心並還原網域。

從 fake-ip 切換至 redir-host，或反向切換後，請清除系統 DNS 快取並重新啟動測試中的應用程式。如果瀏覽器仍快取舊的對應位址，可能會出現設定已變更、連線卻仍使用舊位址的情況。

TUN DNS 劫持：將 53 埠請求交給內建解析器

「fake-ip 劫持」通常混淆了兩個概念：fake-ip 是回應模式，DNS 劫持則是請求重新導向。以下的頂層 tun 設定片段可與前述任一個 dns 範例合併，接管進入 TUN 且符合條件的 UDP、TCP 53 埠請求。

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

any:53 用於 UDP DNS，tcp://any:53 用於 TCP DNS。這裡的 53 是符合條件的流量目的埠；前文 dns.listen 的 1053 則是本機測試監聽埠，兩者不必設為相同值。核心會將符合條件的請求交給內建 DNS，而不是要求系統先直接連線至 1053。

啟用後仍可能繞過接管的流量

1. 瀏覽器 DoH：通常使用 HTTPS 443 埠，不屬於一般的 53 埠查詢。診斷期間可暫時關閉瀏覽器的安全 DNS，測試結束後再依需求重新啟用。
2. 應用程式內建 DoT：常見的目的埠是 853。只設定上述兩條規則，不會將它轉換成內建 DNS 查詢。
3. 未進入 TUN 的流量：路由排除、其他 VPN、網卡選擇與平台限制，都可能讓請求繞過接管路徑。
4. 區域網路裝置：電腦啟用 TUN，不代表它就成為整個網路的 DNS 閘道。其他裝置的閘道、DNS 與轉送路徑都需要分別設定。

只有系統代理時，瀏覽器的 HTTP 請求可能已經透過代理傳送，但系統 DNS 仍由路由器處理。這不代表 dns.enable 失效，而是請求尚未送入內建解析器。請依使用方式選擇將系統 DNS 指向適當位址、透過 TUN 接管，或採用其他明確的重新導向方案。

內網指定解析與代理節點網域解析

家用 NAS、公司內部服務與公網網域，通常不適合共用同一條解析路徑。mihomo 的 nameserver-policy 可依網域指定上游，其優先順序高於一般的 nameserver、fallback 組合。以下片段應合併至既有的 dns 設定中；範例假設路由器位址確實是 192.168.1.1。

  nameserver-policy:
    '+.home.arpa':
      - 192.168.1.1
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query

home.arpa 用於家庭網路的本地域名。若路由器未設定相應記錄，加入解析策略也不會憑空產生解析結果。使用 fake-ip 時，若應用程式必須取得真實的內網位址，也應將該網域加入適當的 fake-ip 篩選規則。

proxy-server-nameserver 用於解析代理節點伺服器本身的網域，不負責解析所有代理網站的網域。為節點提供可直接連線的解析入口，可降低「DNS 上游依賴代理，而代理又必須先透過 DNS 才能連線」的循環風險。

需要讓 DNS 遵循代理規則時

respect-rules: true 可讓 DNS 上游連線遵循路由規則；使用時應一併設定 proxy-server-nameserver，並檢查規則最終選擇的路徑。這不是解決解析失敗的通用開關。如果節點網域解析、上游連線與規則選擇彼此依賴，即使每個位址單獨看起來都正確，整體仍可能無法啟動。

依序確認監聽、解析、接管與規則

排查時請保留一份可還原的設定，每次只修改一個層次。先用 redir-host 確認實際解析，再測試 fake-ip，最後才加入 fallback 或 DNS 出站規則；比起一次啟用所有功能，這樣更容易找出錯誤。

第一步：確認 YAML 已載入

• 同一層級只保留一個 dns:。重複的鍵可能導致錯誤，也可能讓前一段設定被後一段覆蓋。
• 縮排請使用空格，不要使用 Tab；tun: 與 dns: 是同一層級的鍵，不可將整段 TUN 設定縮排到 DNS 底下。
• 訂閱更新可能會覆蓋本機修改。長期使用的設定應放在用戶端支援的覆寫機制中，並於更新後檢查最終產生的設定。

第二步：直接查詢本機 1053 埠

在提供 dig 的 macOS 或 Linux 環境中，可執行以下兩個指令，分別測試 UDP 與 TCP。若系統沒有這項工具，請先透過該系統的套件管理方式安裝，或改用支援指定 DNS 埠的查詢工具。

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

redir-host 模式應回傳實際解析結果；fake-ip 模式下，未經篩選的網域通常會回傳設定位址池中的對應位址。若兩個指令都逾時，請先檢查 1053 監聽、設定載入與本機防火牆，而不是立刻修改代理規則。若回傳 SERVFAIL，再搭配記錄檢查引導解析、上游連線與憑證驗證問題。

第三步：檢查系統查詢是否進入核心

在 Windows 使用 ipconfig /flushdns 清除系統 DNS 快取；使用 systemd-resolved 的 Linux 可執行 resolvectl flush-caches。接著先關閉測試用瀏覽器再重新開啟，減少應用程式自身快取造成的干擾。若直接查詢 1053 成功，但一般應用程式存取失敗，請優先檢查 TUN 路由與應用程式自有的 DNS 設定。

第四步：區分 DNS 解析成功與連線成功

查看用戶端連線記錄中的目標網域、比對規則、出站策略與錯誤訊息。DNS 回傳位址只代表解析階段已完成；節點無法連線、規則將目標送往錯誤出口，或目標埠遭封鎖，都可能導致網頁無法開啟。fake-ip 位址能還原成網域，也不代表選用的代理節點一定可用。

若要繼續檢查系統代理、連接埠或 TUN 環境，請參閱故障排除；首次匯入訂閱與切換模式的操作順序，請參閱設定教學。DNS 設定應配合目前的網路路徑，而不是一味增加解析伺服器。