redir-host と fake-ip の違いは何ですか

fake-ip は仮想アドレスを先に返し接続時に置き換えますが、redir-host は上流 DNS から得た実アドレスを返します。P2P や証明書検証の相性は redir-host が安定しがちですが、OS が直接再帰 DNS に逃げる設計では両方とも単体では防げません。TUN やシステム DNS の向き先も合わせて設計してください。

fallback が発動しないようです

fallback-filter の geoip や ipcidr 条件が環境と合っているか、nameserver が先に「応答してしまう」偽情報を返していないかを確認してください。条件が緩すぎると主系のまま終わります。ログレベルを上げてどちらの上流が使われたか追跡すると切り分けが早いです。

nameserver だけ増やせば十分では

冗長化には有効ですが、特定地域で改ざんされた応答を検知して別上流へ切り替える役割は fallback と fallback-filter の組です。運用地域と脅威モデルに応じて両方を書くのが安全です。

Mihomo redir-host DNS|Clash

1 なぜ今でも redir-host を選ぶのか

Clash Meta（Mihomo）では名前解決の挙動を enhanced-mode で切り替えられ、多くの解説が fake-ip 前提になっています。ところがゲームのマッチング、特定のビデオ会議、証明書ピン留めが厳しい SDK、あるいは社内が split tunnel のポリシーで Fake-IP を禁じているケースでは、仮想アドレスを返す方式がむしろ不都合になります。redir-host は上流 DNS から得られた実アドレスをアプリケーションへ返すため、「実 IP が見えないと成立しない」通信との相性が比較的よいのが利点です。

一方で実アドレスを返す以上、どの上流に問い合わせるかがそのまま攻撃面と運用品質になります。改ざんされた応答や局所的な DNS 汚染を考えると、単一の再帰に頼るのは危険で、nameserver を複数並べ、異常検知時は fallback へ乗り換える、という二段構えがドキュメントでも実運用でも出てくる定石です。ここからは、その定石を YAML 上でどう分割して書くかに絞って説明します。

本稿の前提： OS やブラウザがシステム DNS を Mihomo のリスナへ向けている、あるいは TUN でクエリを捕捉できる、といった「トラフィックがコアに届く」前提は別途必要です。TUN モードやルーター側 DHCP の話まで含めると長くなるため、ここではコアの dns: ブロックだけを深掘りします。

2 redir-host 時の解決の流れと注意点

redir-host では、コアが選んだ上流から A/AAAA を取得し、その結果をクライアントへ返します。プロキシルールは「ドメインではなく、この時点で分かった IP」とマッチングへ進むため、GEOIP ルール中心の構成では、DNS が返した実アドレスとルールの整合が重要になります。意図せず国内サーバの IP が返り、期待したアウトバウンドに乗らない、といった現象は DNS 設定とルールの両方を見る必要があります。

また nameserver に DoH を並べる場合、その TLS 接続を成立させるために default-nameserver が別途必要になる、というのが多くのユーザーがはじめて躓くポイントです。ここが抜けると「暗号化 DNS を書いたのに解決が不安定」という症状に直結します。次節以降では、まず素の UDP/TCP をブートストラップ用に置き、その上で HTTPS/TLS 形式の上流を nameserver に積み上げます。

3 ステップ1：`dns` ブロックの骨格

最小限、次のキーを揃えます。enable: true は必須で、enhanced-mode に redir-host を指定します。listen は環境に合わせ、デスクトップ GUI クライアントが自動で衝突回避してくれることも多いですが、headless の Linux では systemd-resolved とポートがぶつからない値にするのが無難です。IPv6 を本気で扱うなら ipv6: true と経路側の設定をセットで見ます。ここでは分かりやすさのため ipv6: false から始めます。

YAML (骨格)

dns:
  enable: true
  ipv6: false
  listen: 0.0.0.0:1053
  enhanced-mode: redir-host
  use-hosts: true

use-hosts: true は OS の hosts を参照するかどうかのスイッチです。検証中に挙動を切り分けたい場合は一時的に false にして差分を見る方法もあります。redir-host は「実 IP」を返すモードなので、社内ゾーンを hosts で矯正している環境ではこの値が結果に効いてきます。

4 ステップ2：`default-nameserver`（ブートストラップ）

nameserver に https:// や tls:// を書いたとき、その接続先ドメイン自体を解決するには平文の再帰が必要になります。これを供給するのが default-nameserver です。レイテンシとポリシーにより値は変わりますが、「自宅回線ではキャリア DNS」「オフィスでは社内再帰」など、環境の一次リゾルバをここに寄せるのが現実的です。グローバルな公開再帰を置く場合も、到達性が高くフィルタリング方針が明確なものを選びます。

YAML (default-nameserver 例)

  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29

社内プロキシやフィルタ： 企業網では平文 DNS すら特定ホストのみ通すことがあります。default-nameserver が失敗すると、その先の DoH 列全体が不安定になるため、インフラ管理者に「ブートストラップ用の許可先」を確認してから書き込んでください。逆に言うと、この段階が通らない限り nameserver の美しいリストも現場では役に立ちません。

5 ステップ3：`nameserver` 主系

主系は日常の問い合わせに使う上流です。公開 DoH を複数系統混ぜる、ローカルの AD に向ける、あるいはプロキシ経由の DoH を #ProxyName 形式でぶら下げる、といった器用な書き方が可能です。地理的に離れたリゾルバを並べると RTT のばらつきが出るので、まずは遅延を見ながら 2〜3 系統に絞り、安定したものを残すのが実務的です。中国本土ドメインだけ国内 DoH に寄せたいときはこの段階で全部書き切らず、後述の nameserver-policy に逃がすと読みやすいです。

YAML (nameserver 例)

  nameserver:
    - https://dns.google/dns-query
    - https://1.1.1.1/dns-query
    - tls://8.8.8.8:853

アウトバウンド側でしか到達できないリゾルバを使う場合は、既存の Fake-IP 解説記事でも触れた https://example-dns.example/dns-query#GroupName 形式でプロキシグループ名をサフィックスします。実在する proxy-groups 名と一致させないと期待どおりにハイジャックされません。

6 ステップ4：`fallback` と `fallback-filter`

主系が返した応答が信頼できない可能性があるときに使うのが fallback です。たとえば特定国の GEOIP に落ちた IP だけを疑う、プライベート帯に紛れた返答を弾く、といった条件は fallback-filter に宣言します。条件の緩さと厳しさはトレードオフで、厳しすぎると常に fallback 側に流れて遅延が増え、緩すぎると汚染された主系のままです。運用で一度チューニングしたら、ルールセットやジオブデータ更新のタイミングで再確認する癖をつけると安全です。

YAML (fallback 一式の例)

  fallback:
    - https://1.1.1.1/dns-query
    - tls://dns.google:853
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
      - 0.0.0.0/32
    domain:
      - '+.google.com'
      - '+.youtube.com'

実際の geoip-code や domain リストは、自分が「主系の応答を疑うべきパターン」に合わせて調整してください。ここに書くドメインは「フォールバックを追加で試すべきサイン」として機能する理解をするとミスが減ります。詳しい DNS 漏えい対策や Fake-IP 併記の文脈は前稿の DoH／FakeIP 解説とあわせて読むと全体像が繋がります。

設定だけでは終わらない： redir-host は「実 IP を返す」モードなので、ブラウザのセキュア DNS が別リゾルバを直接向いていると、YAML 上の丁寧な fallback もすり抜けます。Windows では「追加のアプリごとの DNS」、Android では Private DNS、Chrome の設定など、端末側の二重リゾルバを疑ってください。ブラウザ Secure DNS をオフにする手順も参照ください。

7 任意：`nameserver-policy` でゾーン分割

サフィックスや GEOIP に応じて「このドメインはこの上流へ」と分岐させたい場合は nameserver-policy を使います。国内限定サービスを国内 DoH に、グローバル CD を海外 DoH に、といったマッピングが可能になり、redir-host でも「どの IP が返るか」をルール設計に寄せやすくなります。サンプルは環境差が大きいためここでは省略しますが、分岐を増やすほど運用コストが上がる点は意識してください。小さく始めて、問題が出たドメインから順に足していくのが安全です。

8 トラブルシューティングの着眼点

DoH なのに遅い： RTT が大きい上流を先頭に置いていないか、または fallback が過剰に発動してタイムアウト待ちが増えていないかを確認します。
期待と違う国の IP が返る： 主系リゾルバのエッジロケーションと、GEOSITE／GEOIP ルールの前提が一致しているかを見直します。
社内名が解けない： intranet ゾーンを nameserver-policy でローカル DNS に割り当てる、など split DNS を明示していない可能性があります。
Linux の 127.0.0.53： systemd の stub と listen ポートの衝突は別問題ですが、症状が DNS 全体に見えることがあります。stub と Mihomo の共存記事を併読ください。

9 よくある質問

redir-host と fake-ip はどちらを優先すべきですか

優劣ではなく用途です。互換性とデバッグのしやすさを取るなら redir-host、ルールとの一体化や早期ルーティングを取るなら fake-ip 、という整理が現場では扱いやすいです。同一端末でもプロファイルを分けて切り替えるユーザーは多いです。

fallback を厚くすれば安全ですか

数を増やすだけでは遅延と失敗確率が増えます。地理的・論理的に独立した 2 系統を確実に動かし、filter で必要なときだけ乗り換える、という方針の方が安定しやすいです。

10 まとめ

Mihomo／Clash Meta で redir-host を使うときの要点は、ブートストラップ用の default-nameserver、日常用の nameserver、異常時の fallback と fallback-filter を YAML 上で役割分担させることです。Fake-IP を使わない構成ほど、上流の信頼性と端末側の DNS 出口の二者が露骨に効いてくるため、コアの設定と OS／ブラウザの設定をセットで見る習慣が結果を分けます。

一方、汎用 GUI だけに任せると「購読ルールを入れたら終わり」になりがちで、DNS スタックがブラウザや OS の別リゾルバに吸われたままになる例は珍しくありません。コマンドライン専用ツールや古いフォークでは YAML を手編集する手間も残ります。Clash Verge Rev のように Mihomo コアを同梱し、DNS モードや TUN、ルール編集まで一つの画面から扱えるクライアントであれば、本稿のような nameserver／fallback の意図を保ったまま日常運用に落とし込みやすく、設定の食い違いによる「設定したつもりの解析事故」も起こりにくいです。同等のユースケースで迷っているなら、まずはダウンロードページで自分の OS 向けビルドを試して、redir-host でも一貫した名前解決経路になるか確かめてみるのがおすすめです。