Windows / ブラウザ · · 読了まで約 17 分

Clash は起動しているのにブラウザだけ直結?Windows で「安全な DNS(DoH)」をオフにしシステム代理を校正する(2026)

Clash(mihomo 系含む)をオンにし、クライアント上では「システム代理」も有効なのに、Chrome や Microsoft Edge だけ挙動がおかしい──海外サイトが自宅回線直結のように見える、IP 系の表示だけ国内、あるいはルール上は代理行きのはずのドメインが想定外のエッジに着く。こうした相談のなかに、ブラウザ内蔵の「安全な DNS(多くは DNS over HTTPS, DoH)」が、OS のプロキシ設定や Clash 側の DNS 処理をすっ飛ばすパターンが定番で埋もれています。本稿は購読取得の TLS 失敗専用稿や TUN+UWP 回りとは線を引き、「まずブラウザだけ挙物が違う」層に焦点を当て、Windows 上で安全な DNS の解除 → OS と Clash の DNS のすり合わせ → 手動プロキシの有無の順に潰す手順を日本語で整理します。初回の GUI 導入の全体図は Windows 11 の Verge Rev 導入稿と併読すると、用語の対応づけが速いです。

1. 典型症状:クライアントは有効、ブラウザだけ「直結」っぽい

手元の症状が次のいずれかに近いなら、本稿の切り口が当たりやすいです。(1)ターミナルや一部デスクトップアプリは期待どおりの出口なのに、Chrome・Edge だけ同じ URL が別の経路に見える。(2)「今の接続元 IP」を表示するサイトで、ブラウザ枠と Clash のログ上の接続先が食い違う。(3)名前解決の出口だけ別で、DNS 系の挙動が想定外(例:国外ドメインなのに国内 CDN エッジに着く、あるいはその逆)。(4)拡張機能を全部オフのプロファイルやシークレットで試しても再現する──つまり拡張では説明しきれない。ここでいう Clash には mihomo コア+ GUI(例:Clash Verge Rev)を含めた総称的な使い方を想定します。

逆に、Microsoft Store 由来の UWP アプリだけ挙物が違う、ゲームランチャーや UDP 主体の通話だけ届かない、といった層は TUN・ループバック系の専用稿の方が当たることが多いです。併せて、サブスクリプションの取得が Clash 単体で落ちる悩みは、ブラウザとコアの TLS 経路差が主役になりやすく、Windows の購読・TLS・DNS ログ診断稿が補完です。本稿の主役はあくまで一般ブラウザの HTTP(S) スタックです。

2. なぜ「ブラウザだけ」に偏るのか

多くの環境で、システムの「手動プロキシ」は Clash のローカル・リスナー(例:127.0.0.1mixed-port)へ向いています。通常、ブラウザもこの設定に従い、HTTP 接続先はまずローカル代理へ、実際の出口ノードは Clash 側のルールで決まります。ところが Chrome/Edge には、プロキシより先に「自前の DoH 解決器」に名前解決を投げる独立したスイッチがあり、有効化されていると、名前の見え方が Clash の dns セクションや redir-host / fake-ip の前提と食い違うことがあります。加えて Windows 11 以降の「DNS の暗号化」は OS レベルでも同種の衝突を生み、ブラウザと OS の両方に「平文 53 ではない経路」が同居すると、想定外の AS /エッジに着地する、という体験になります。

用語の整理です。「安全な DNS」「セキュリティーで使用する DNS(Chrome の旧表記に近い)」はベンダ表記差がありますが、いずれも従来の OS リゾルバ/ルータ経由 53 番ではなく、HTTPS 上で DNS クエリを送る DoHを指すことが多いです。本稿では便宜上まとめて DoH 前提で書き、実装の差は画面のスイッチ名で補正してください。重要なのは、「Clash 側の DNS 設計を変える前に、ブラウザと OS の上書きを外す」方が A/B テストが速い、という点です。

3. Google Chrome:安全な DNS(DoH)の確認とオフ

手順(バージョンにより文言差あり)。アドレスバーに chrome://settings/security を開き、「安全な DNS を使用する」(英語版では *Use secure DNS* に相当)の項目を探します。ここは二段構えのイメージで、まず「オフ」にして挙動を比較するのが最速です。オフのあと、ターゲット URL を二回通し、ハード再読み込みCtrl+Shift+R)を挟みます。企業管理ポリシーで締められている端末は項目が灰化するため、その場合は IT 部門向けの例外が必要です。

切り分け用に、新しい Chrome プロファイル(人型アイコン → 他のプロファイルの追加)を一時的に作り、拡張ゼロのクリーンな枠で同じ URL を開く、という方法も有効です。ここで差が出るなら、元プロファイルの拡張・起動引数の影響を疑います。なお、--host-resolver-rules 等の起動ショートカット改変を過去にしたことがある端末は、同様に名前解決だけ別経路になるので、併せて確認してください。サブスクリプション導入やルール全般の土台は サブスクリプション取り込みチュートリアル総覧にありますが、DNS の見え方はルール以前の土台です。

4. Microsoft Edge:セキュリティで DNS 設定を揃える

Edge では、設定の 「プライバシー、検索、サービス」(または新 UI の同カテゴリ)に 「セキュリティ」小節があり、「セキュリティーで使用する DNS(英 *Use secure DNS*)に相当するスイッチがあります。手順の骨格は Chrome と同型で、いったん「オフ」にして、同じ URL の再現性を比較します。Edge は Windows と親和性が高く、システム既定の DNS 設定に合わせる(表記のある場合)のような中間的な肢もあります。迷ったら「Clash 側の解決方針に寄せる」か「一時的に平文 53 系へ戻す」か、どちらを採用するかを一文でメモし、A/B テストがブレないようにします。

Edge のワーク/スクールプロファイルを併用している場合、組織ポリシーで DoH が固定されていると画面から直せません。個人枠の「プロファイル 1」で再現が消えるなら、管理側のテンプレが原因枠に入れます。家庭内では、子ども向け 家族の安全 やルータのフィルタと重なることもあるため、同じ回線上の他端末でも一度確認すると切り分けが早いです。

5. Windows 本体の「DNS の暗号化設定」と競合

Windows 11 では、「設定」→「ネットワークとインターネット」→ 使用中のイーサネット/Wi-Fi」→ その接続のプロパティのなかに、「DNS サーバーの割り当て」や「DNS の暗号化」の項目が見えます。ここで DoH やプロバイダ付属の暗号化 DNS をオンにしており、同時に Clash が仮想 TUN やローカル DNS リスナーで解決方針を上書きしていると、「どの層の名前解決が勝つか」の競合が出ます。切り分けの実務的な打ち手は、一時的に DNS 暗号化をオフ、あるいは 意図した DNS サーバ表記へ明示、のどちらかです。有線/無線のプロファイルを複数持つユーザーは、再現中の接続名だけを直す、と書き留めると戻し忘れを防げます。

併せて、企業 VPN クライアントがルートと DNS サフィックスを上書きしている場合、ブラウザ外では正常でもブラウザ枠のスプリットが起きることがあります。本稿範囲外ですが、社用 VPN オン/オフで症状が二値化するなら、まず IT セキュリティ方針と衝突していないかを確認する価値があります。

6. Clash 側の DNS モードと OS 解決の整合

Clash / mihomo では、dns ブロックの enableenhanced-moderedir-host / fake-ip)、nameservernameserver-policy の組み合わせで、アプリに返す IP の見え方を制御します。ブラウザが DoH別の権威解決器を見に行くと、Clash ログ上の dst_iphost の対応が期待とズレる──典型的には fake-ipDNSIP の不整合、あるいはルール上は代理行きだが SNI / HTTPS 検査と矛盾する症状です。したがって、ブラウザの DoH をオフにしてから、Clash 側の dns 設計を微調整する方が、原因と結果の因果が追いやすいです。

運用のすり合わせ方の一例を挙げます。テスト中だけ log-level: debug に上げ、対象 URL 開封時の どの FQDN が最初に connect されているかを追います。期待する CDN 名に置き換わっていなければ、ルールにその FQDN を足す前に、名前解決の出口がどこかを固定します。nameserver-policy で地域別 DNS へ分ける、clash 内蔵 DNS だけ :80:853 のどちらを使うか、といった微調整は、プロバイダや宅内ルータ、IPv6 優先度に依存するため、ここは網羅表よりログドリブンを推奨します。

# config.yaml — excerpt: align DNS for troubleshooting (revert after)
dns:
  enable: true
  enhanced-mode: redir-host  # or fake-ip — keep one story per test run
  nameserver:
    - 223.5.5.5
    - tls://1.1.1.1

7. システム手動プロキシと自己参照(ループ)の一瞥

「ブラウザが直結」に見えて、実は延々とタイムアウトする場合は、Windows の手動プロキシが、いまの mixed-port を指しており、外向き :443 まで自分のリスナーを踏み回している自己参照型の不具合が混ざっていることがあります。典型は購読更新の稿で触れたパターンで、同稿の「mixed-port・システムプロキシ」節と併せて読むと早いです。本稿の焦点は DNS ですが、症状が「解決はできているのに 遅延爆増」なのか、IP 自体が想定外」なのかを分けると、当たり所が変わります。前者は loop や帯域、後者は DNS 出口の上書き、という大まかな地図で構いません。

8. 短時間チェックリスト

下表は確定診断ではなく、現場で手を動かす順序の目安です。結果をメモしながら一列ずつ潰すと、戻し忘れが減ります。

手順 操作の要点 期待する観測
1 Chrome/Edge の「安全な DNS」相当をオフ URL の出口・IP 表示が Clash 側の期待に近づく
2 Windows 接続プロファイルの DNS 暗号化を一時オフ OS スタブと Clash 仮想 TUN の競合が解ける
3 手動プロキシが 127.0.0.1 正解ポートか確認 拡張・別クライアントの二重 HTTP 代理が入っていない
4 Clash ログ debug で最初に出る FQDN を記録 不足ドメインをルール・nameserver-policy に足す根拠になる

9. まとめ

Windows で Clash/mihomo をオンにしているのにブラウザだけ挙物が違うとき、最初に疑う価値が高いのはChrome・Edge 内蔵の「安全な DNSDoH)」と、Windows 側の DNS 暗号化です。ここを外してから、Clash の dns モードと OS 解決のすり合わせ、手動プロキシの自己参照を順に掘ると、症状の階層がきれいに分かれます。同系ツールの中でも、Clash 系は可観測性(ログ、ルール表現、仮想 TUN)のバランスが取りやすい、と評価されがちでしょう。

手元の構成に合うクライアントを選び、一度だけ比較用のクリーンプロファイルとログレベル上げをセットにすると、再現条件が文章化しやすく、あとで自分で読み返しても困りません。各プラットフォーム向けの入手導線は → 無料で Clash をダウンロードし、快適な接続体験を試す からどうぞ。

トピックの近さで選んだ関連記事 — 同じカテゴリの Clash 実践ガイド。