1. 検索意図：「Clash はオンなのに Chrome が素直じゃない」をレイヤーに分解する

典型的には、(A) Windows のプロキシ設定と Clash が書き換えている値が一致していない（別ポートや PAC の残骸）、(B) QUIC が UDP で別経路に逃げているためログの見え方と体感がズレる、(C) Chrome のセキュア DNS が OS／Clash の DNS 設定と別レイヤーで名前解決している、(D) ルール順や GEOIP／DOMAIN-SUFFIX の漏れで一部ドメインだけ DIRECT に落ちている、(E) 拡張機能や別プロファイルがプロキシを上書きしている、のいずれかです。まず「Chrome だけか」「Edge や curl でも再現するか」を分けると、あとの chrome://flags や設定画面の見どころがはっきりします。

購読やポリシー名がまだ整理できていない場合は、サブスクリプション取り込みで全体像を押さえてから読み進めてください。

2. Firefox 稿との棲み分け：なぜ Chrome だけ別記事にしたか

Firefox は GUI と about:config で明示プロキシを細かく固定でき、SOCKS の DNS 転送もブラウザ側で宣言しやすい一方、Chrome は多くの環境でシステムプロキシ設定に従う前提に近く、ユーザが触るべき項目の中心が QUIC やセキュア DNSに寄りがちです。同じ「ブラウザが Clash と噛み合わない」題材でも、スタックが違うため手順を分けた方が検索意図に応えやすく、本稿は Windows 上の Chromium 固有の切り口に絞ります。

3. Windows のシステムプロキシと Clash の「注入」が一致しているか

設定 → ネットワークとインターネット → プロキシで、手動プロキシやスクリプト（PAC）が期待どおりのホスト／ポートになっているか確認します。Clash 系クライアントの「システムプロキシをセットする」機能は、多くの場合 HTTP（および環境により HTTPS）プロキシとして 127.0.0.1 と mixed-port または別途公開しているポートを書き込みます。ブラウザが SOCKS を直接読んでいない構成では、HTTP 用ポートと SOCKS 用ポートを取り違えると「動いているように見えるが別アプリだけ失敗」になります。

複数 NIC や VPN が同居している環境では、プロキシ例外リストに広すぎるパターンが残っていると、特定ドメインだけ直結します。ループバックは IPv4 に統一する（::1 と混在させない）ほうが切り分けが楽です。ストア系アプリやループバック制限が絡む話題はUWP とループバックの記事と補完的です。

4. QUIC を疑う理由と無効化のしかた（優先度高）

Google 系や CDN が QUIC を優先すると、ブラウザはUDP で別経路を試みます。HTTP プロキシ経由の TCP とUDP の出口が一致しない構成では、「ページは開くが判定だけおかしい」「ログに UDP がほとんど出ない」などのようにレイヤーのずれが表れます。実務では一度 QUIC を無効化して挙動が変わるかを見るのが費用対効果が高いです。

手順の一例として、Chrome アドレスバーに chrome://flags/#enable-quic を開き、Experimental QUIC を Disabled にして再起動します。チャネルやバージョンによりフラグ名・既定値が変わるため、検索ボックスで QUIC と打って現行ビルドに存在する項目だけを触ってください。企業環境ではポリシーで QUIC が固定されていることもあり、その場合は管理者ドキュメントと衝突しないよう確認します。

5. Chrome のセキュア DNS（DNS-over-HTTPS）と Mihomo の DNS を揃える

設定 → プライバシーとセキュリティ → セキュリティ配下のセキュア DNSで、プロバイダ固定・オフ、あるいは OS 既定などが選べます。ここが Cloudflare や Google Public DNS といった外向きリゾルバに固定されていると、Clash の fake-ip やローカルの DNS ハンドシェイクと矛盾し、分流ルールが期待どおりに載らないことがあります。切り分けではいったんセキュア DNS をオフにして症状が変わるかを見るか、「OS の既定を使用する」寄せにして名前解決が Mihomo の DNS 設計と整合する側に寄せます。

詳細パラメータ（fallback、nameserver-policy など）は利用中の Mihomo／Meta のドキュメントと照合してください。TCP の出口と DNS の出口が別々に見える状態は、ログ上では「プロキシ経由だが GEO が変わらない」ように読めることがあります。

6. 接続ログ・分流ルール・ノードとの突き合わせ方

Chrome で問題のサイトを開いた直後に、クライアントの接続一覧で対象ホストがどのポリシーに載ったかを確認します。DIRECT に落ちているなら RULE の順序や GEOIP、DOMAIN-KEYWORD の漏れを疑います。PROXY に載っているのに体感が変わらないなら、別レイヤー（本章までの QUIC／DNS）かノード側の実出口を疑います。

複数プロファイルや複数ウィンドウで異なる拡張が有効だと、同一マシンでも挙動が分岐します。ゲストウィンドウや新規プロファイルで再現するかを試すと、拡張起因かどうかが切り分けやすくなります。

7. TUN と mixed-port：HTTP だけでは握りきれないとき

TUN を有効にすると OS のルーティングからトラフィックを取り込み、ブラウザ設定より下のレイヤーからUDP を含む経路を揃えやすくなります。一方で権限や競合ドライバがあり、常時オンにできない環境もあります。HTTP プロキシのみで運用している場合は、本章までの QUIC／DNS を先に潰してから TUN を検討すると迷いが減ります。概要はTUN モードの記事を参照してください。

8. 実測チェックリスト（この順で試す）

  1. Clash が起動し、システムプロキシが期待ポート（mixed または HTTP）を指していることを OS の設定画面で確認する。
  2. Chrome で QUIC を無効化し、症状が変わるか見る。
  3. セキュア DNS をオフまたは OS 既定寄せにし、名前解決が Mihomo と矛盾しないか確認する。
  4. 接続ログで当該ホストのポリシー（PROXY／DIRECT）とノードを確認する。
  5. ゲストまたは拡張オフのプロファイルで再現するか試す。
  6. 必要なら TUN をオンにし、UDP を含む経路がログで揃ったか検証する。

ポート競合やコア未起動など汎用症状はトラブルシュート記事へ。本稿はChrome Windows と QUIC／セキュア DNS／システムプロキシに焦点を当てています。

9. 追加の落とし穴：IPv6・HTTPS DNS 記録・キャッシュ

IPv6 が有効な環境では、名前解決結果が AAAA を返し別経路に乗ることがあります。Chrome のキャッシュや Service Worker が古い接続性を引きずると、設定を直した直後だけ挙動が更新遅れに見えることもあります。OS 側のネットワークリセットは最終手段として、まずは本章の順序とログで切り分けるのが安全です。

10. まとめ：Chrome Windows・Clash・QUIC・セキュア DNS・システムプロキシを一枚に束ねる

Chrome は OS のシステムプロキシに追従しやすい一方、QUIC とセキュア DNSが別レイヤーから経路を変え、Clash のログと体感がズレることがあります。QUIC を止める → DNS を Mihomo と整合させる → ログで DIRECT／PROXY を確認するという順は、実務でも再現性が高いです。

GUI でポートとログを並べられるクライアントなら、試行錯誤のたびに見落としが減ります。安定した出口設計から試したい方は、→ Clash を無料ダウンロードして、快適な接続体験を始める