なぜ「プロキシオン」のまま DNS が気になるのか

HTTP／HTTPS のトラフィックをプロキシに通しても、ドメイン解決が別経路に抜けていると、利用者の所在地付近のリゾルバにクエリが見える──いわゆる DNS 漏れが起きます。Clash（多くは Mihomo コア）では dns ブロックと Fake-IP などのモード設計によって「アプリが見ている IP」と「実際に接続に使う経路」を整理しますが、クライアントの挙動・OS のスタブリゾルバ・IPv6・TUN の有無によっては、想定とズレた見え方になります。

本記事の目的は、用語の暗記ではなく、設定の意図を説明できる状態にし、同じ手順を踏めば誰でも再現できる検証フローを持つことです。分流や TUN の全体像は別記事（例：TUN モード解説）と補い合います。一覧から関連記事を辿る場合は ブログ一覧 も参照してください。

Fake-IP と redir-host：まず押さえる二分法

Fake-IP は、ドメインに対して一時的な「偽の IP」を返し、実際の接続フェーズでコアがドメイン情報と突き合わせてプロキシ／DIRECT を決める方式です。アプリは早い段階で名前解決を終えたように見える一方、解決結果が実 IP ではないため、LAN 名や証明書ピン留めと相性が悪いケースがあります。対策として fake-ip-filter や nameserver-policy で「このドメインは実解決したい」を切り出します。

redir-host（ホストそのまま）は、解決結果を実 IP に近い形で扱う方向です（実装・表記はテンプレートによります）。ルールが IP ベースで素直に効きやすい反面、解決タイミングでどの DNS に聞くかがそのまま振る舞いに出やすく、遅延やキャッシュの体感差が出ることがあります。どちらが「正解」ではなく、自分のルール列・クライアント・社内ドメインの有無で選ぶ、と捉えるのが安全です。

ℹ️
用語メモ：GUI では「DNS モード」などの別名になっていることがあります。迷ったら設定 YAML の dns.enhanced-mode 相当の値と、ログに出る [DNS] 行を対応づけて確認してください。

dns ブロックの骨格：nameserver・fallback・policy

典型的な Mihomo／Clash Meta 系では、nameserver が第一候補のリゾルバ列、fallback がフォールバック用、fallback-filter が「いつフォールバックへ回すか」の条件、nameserver-policy がドメイン単位の上書きです。ここが空欄やテンプレのままだと、ISP の DNS へ素直に抜ける構成になり、意図せぬ DNS 漏れに見えることがあります。

運用上のコツは次のとおりです。（1）信頼できる DoH／DoT を nameserver に置き、（2）国内向けドメインだけローカルや社内 DNS を nameserver-policy で逃がす、（3）フォールバック条件（GEOIP やドメインサフィックス）を自分のリストと矛盾させない——の三段です。購読テンプレが fallback を細かく書いていても、自環境の「国内／社内」の定義が合っていなければ、見かけ上の漏れや逆に社内サイト不達が起きます。

「漏れ」や解決異常の典型パターン

OS のスタブリゾルバが先に答える

ブラウザや一部アプリは、Clash が用意したローカル DNS ではなく、OS がキャッシュした結果や ルータが配る DNS を先に使うことがあります。特にプロキシをオンにする前に解決済みの名前は、そのまま古い IP を握り続けるため、ルールを変えても挙動が追いつかないように見えます。対策はキャッシュのクリア、ブラウザのセキュア DNS 設定の確認、必要なら一度プロファイルを切り替えて強制的に再解決させることです。

IPv6 がバイパスする

IPv4 だけ丁寧にプロキシしていても、AAAA レコード経由で IPv6 が直結すると、DNS も接続も「想定外の経路」になります。ルールで IPv6 をどう扱うか、OS で IPv6 を一時オフして切り分けるかは環境依存ですが、症状が「たまにだけ漏れる」ときは IPv6 を疑う価値があります。

TUN 未使用で取りこぼす

システムプロキシだけの構成では、プロキシ非対応のプロセスからの DNS がコアに届かないことがあります。TUN モードは取り込み口を下げる手段ですが、そのぶん dns-hijack や fake-ip 周りの設計とセットで見る必要があります。

再現可能な検証手順（おすすめの順）

以下は「誰かの環境だけで閉じない」ようにするためのチェックリストです。すべてを一度にやる必要はありませんが、上から順に潰すと切り分けが速いです。

  1. クライアントのログを開く：接続直後に [DNS] やエラーが出ていないか確認します。名前解決がどのサーバへ向かっているかの手がかりになります。
  2. ブラウザだけで DNS 漏れテスト：信頼できる「DNS leak test」系のページを開き、表示されるリゾルバの国・ISP をメモします。プロキシ前後で差分が縮まるかを見ます。
  3. 設定の単純化：購読ルールをそのまま足し込むのではなく、dns だけ最小構成のプロファイルを作り、同じ手順で挙動が変わるか比較します。差が出るなら原因はノードではなく DNS／ルールの前置き側に寄ります。
  4. fake-ip-filter の見直し：社内・NAS・プリンタ名など、実 IP が必要なホストを列挙します。ここが薄いと「一部サイトだけおかしい」が続きます。
  5. 端末をまたぐ：同じ設定を別 OS や別クライアントで試し、再現するかを見ます。再現しないなら OS の DNS オーバライドやセキュリティ製品が疑わしいです。
✅
ヒント：「漏れている気がする」だけでは改善できません。プロキシオフ時のテスト結果のスクショ／メモと、オン時を並べておくと、自分でも一周後に読み返せます。

設定ファイル側で押さえるポイント（概念と例）

実際のキー名はテンプレとコアのバージョンで微妙に異なるため、ここでは考え方に絞ります。DoH／DoT の URL を nameserver に並べ、国内ドメインだけ信頼できるローカル DNS へ寄せるなら nameserver-policy を使います。fallback は「メインが返した答えを信頼できないときの保険」であり、メインと同じ ISP DNS を二重に並べても意味が薄いことがあります。

次の例はあくまで構造のイメージです。値は自環境の購読・ポリシーに合わせて置き換えてください（コメントは英語のみ）。

# Illustrative snippet — replace endpoints with your own resolvers
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.example/dns-query
  fallback:
    - https://fallback.example/dns-query
  nameserver-policy:
    "geosite:cn": tls://dns.local
  fake-ip-filter:
    - "*.lan"
    - "*.local"

この骨格に、自宅ルータや会社ドメインのサフィックスを足し込むかどうかで、「快適さ」と「見え方の筋の良さ」のバランスが決まります。

GUI 利用者へ：画面のどこを見るか

Clash Verge Rev などの GUI では、DNS モード・TUN・システムプロキシが別スイッチになっています。YAML を直接編ばない場合でも、最終的に書き出される設定が購読とマージされた結果であることを忘れないでください。「画面は正しいのに挙動がおかしい」は、購読側の dns が上書きしているパターンがよくあります。

まとめ：不安を「手順」に落とす

Clash の Fake-IP と DNS 設定は、分流や TUN と同じくらい実務上の影響が大きい領域です。redir-host か fake-ip か、nameserver と fallback をどう置くかは、ノードの速さ以前に見え方とトラブルの種類を決めます。本記事の検証手順を一度通せば、「プロキシは効いているが DNS だけ気になる」状態を、再現と説明に耐える形に落とし込めるはずです。

クライアントの導入から始める場合は、まず ダウンロードページ で OS に合ったパッケージを選び、同じバージョンのテンプレで DNS をいじったときの差分が追いやすくなります。他ツールと比べても、ルールと DNS を一つのコアで扱える点は、長く使うほど効いてくる強みです。

→ 無料で Clash をダウンロードし、設定と検証を自分の手元で試す