症状の型：Chrome だけが「システム代理を読んでいない」ように見える理由
まず、次のどれに近いかを一文で決めます。第一に、同じ PC の Microsoft Edge や他アプリは期待どおり出口に乗るのに、Chrome だけ 接続ログに現れない。第二に、設定アプリやコントロールパネルのプロキシ表示は Clash のポートに見えているが、Chrome の開発者ツールのネットワーク欄や外部の IP 確認サイトでは ISP 側の経路のままである。第三に、過去に試した 起動引数 や 拡張型プロキシ が残っており、今の Clash のポートと食い違っている。第四に、職場端末で chrome://policy に Proxy 関連の強制値が出ている。
Chromium 系は基本、Windows のシステムプロキシ設定 を参照しますが、その前段で ポリシー や コマンドライン が上書きします。また、セキュア DNS（DNS over HTTPS） を Chrome 内で有効にしていると、Clash の fake-ip やローカル DNS スタックと組み合わさったときに「プロキシは通っているのに名前解決だけ別穴」という見え方になります。Firefox 稿で扱った about:config とは UI が異なりますが、責務の境界（OS・ブラウザ・Clash・拡張）は同じです。ここを固定してから YAML を疑うと、復旧が速くなります。
ステップ1：Windows の LAN プロキシを「現在のユーザー」で既定へ戻し、Clash のシステム代理と突き合わせる
Win + R で「inetcpl.cpl」と入力し、接続 タブの LAN の設定 を開きます。ここで プロキシサーバーを使う にチェックが入っている場合、アドレスとポートが Clash のダッシュボード表示（mixed や HTTP ポートなど、利用クライアントの表記に従う）と一致しているか確認します。古い実験で別ポートが残っていると、Clash 側は「システムプロキシ ON」と言っていても OS 上の実値がズレたままになります。
一度 自動検出設定を使用する など、環境に合わせた最小構成へ戻してから、Clash で システムプロキシ をオフ→オンと切り替え、LAN ダイアログを開き直して値が書き戻されたかを見ます。「現在のユーザーのみ」 に効く設定と、管理者が配布するマシン全体ポリシーが混在している端末では、ユーザー画面では直っているつもりでも別レイヤで固定されていることがあります。この段階で Edge がログに載るなら、OS スタックはおおむね生きており、以降は Chrome 固有要因に絞れます。
UWP や localhost ループバックが絡む別症状は Windows 11 の UWP／ループバック稿 と重なることがあるため、併せて参照してください。
ステップ2：Chrome のシステム連携とセキュア DNS を一段シンプルにする
Chrome アドレスバーに chrome://settings/system と入力し、コンピューターのプロキシ設定を開く から、先ほどの OS 画面へ飛べることを確認します（ビルドにより文言は多少異なります）。続いて chrome://settings/security 付近の セキュア DNS を開き、検証中は オフ または ISP の既定 に寄せて症状が変わるかを見ます。ここを Cloudflare 等に固定したまま Clash の DNS モードと組み合わせると、他ブラウザでは再現しないズレが出やすいです。
併せて、chrome://net-export や内部のプロキシ解決ログは上級者向けですが、通常は システム設定の往復リセット と DNS の単純化 で十分なことが多いです。ルールの優先順位や購読 RULE-SET の衝突は YAML ルール分流ガイド で整理し、Chrome から出たホストがログに載ったうえでポリシー名を確認してください。購読リンク（サブスク URL）でプロファイルを更新した直後だけ挙動が変わる場合は、追記ルールが購読側に負けていないかも見ます。
ステップ3：拡張機能とセキュリティ製品の「HTTPS 検査／ブラウザ保護」を切り分ける
プロキシ系拡張（例：スイッチ型のプロキシ管理、広告ブロッカーのネットワーク層機能）が有効だと、システム代理より拡張が先に効く ことがあります。Chrome の シークレットウィンドウ で拡張を無効化できる設定にしたうえで再現するか、あるいは chrome://extensions で一旦すべてオフにして試します。
企業向けセキュリティ製品や一部の個人向けスイートは、独自のフィルタドライバと組み合わせて ブラウザに別のプロキシ／証明書 を注入します。この場合、OS の LAN 設定は Clash でも製品のローカルプロキシでも「正常」に見えつつ、Chrome だけ別表になることがあります。検証では一時的に HTTPS スキャンやブラウザ保護をオフにできるか製品マニュアルを確認し、可能なら 除外リスト に 127.0.0.1 や Clash のポート範囲を入れられるかを見ます。戻すときは必ず元の保護を有効化してください。
ステップ4：chrome://policy で ProxyMode 等を確認し、必要なら新規プロファイルで素の Chrome を試す
アドレスバーに chrome://policy と入力し、ProxyMode、ProxyServer、ProxyPacUrl などに 強制 のマーク付きの行がないかを見ます。職場の GPO や MDM で固定されている場合、GUI からは戻せず、IT ポリシーに従う か、許可されたプロファイル／端末で検証する必要があります。
ポリシーがクリーンでも症状が残るときは、新しいユーザー データ ディレクトリ で起動して切り分けます。例として、コマンドプロンプトや PowerShell から、実行ファイルへ --user-data-dir=%TEMP%\chrome-clash-test のような引数を付けて一時プロファイルを指定します（実際のパスは環境に合わせてください）。ここで期待どおりログに載るなら、既存プロファイルの破損や実験残りが疑わしく、本番プロファイルのリセットや段階的な設定移行を検討します。
ステップ5：Clash TUN を有効にし、OS ルーティング層でトラフィックを安定取り込みする
システムプロキシと Chrome の読み取りに振り回される場合、TUN モード は有力な打ち手です。仮想アダプタ経由で OS のルーティングに載せるため、ブラウザがシステムダイアログの細部を誤読していても、多くの TCP／UDP が Clash のポリシーに乗りやすくなります。手順のイメージは次のとおりです。第一に Clash クライアントで TUN／仮想ネットワークアダプタ を有効化し、管理者権限や UAC の許可が必要なら従います。第二に、別 VPN や競合するフィルタと干渉していないか確認します。
第三に TUN 有効直後に全アプリがオフラインに見えたら、まず TUN をオフにして復帰できるかを確認します。第四に安定したら Chrome を通常起動のままアクセスし、ログで主要ドメインが期待ポリシーに載るかを見ます。TUN は強力ですが副作用も大きいため、総覧記事 の注意点（復帰手順、DNS、競合）を頭に入れてから操作してください。
ステップ6：ショートカットに --proxy-server 等を付けて明示指定し、検証後に元へ戻す
最終手段として、Chrome のショートカットの リンク先 に起動引数を追加し、プロキシをコマンドラインで固定 します。例（ポートは環境に合わせて置換）：--proxy-server=http://127.0.0.1:7890 や SOCKS を使う場合 socks5://127.0.0.1:7891 形式など、クライアントの mixed／HTTP／SOCKS の定義に合わせて選びます。--proxy-pac-url で PAC を明示する構成もありますが、運用が複雑になりがちなので、まずは単一の upstream に寄せるのが扱いやすいです。
検証専用に --user-data-dir を併用すると、日常のプロファイルを汚さず試せます。ログでホストが流れることを確認したら、なぜシステム代理だけでは不十分だったか（ポリシー、拡張、DNS、LAN 実値のズレ）をメモに残し、恒久対応 を TUN 側や OS 設定の正に寄せるか判断します。起動引数はメンテナンス負荷が高いため、長期運用では Clash の TUN や正しいシステム代理運用へ戻すのが無難です。
開発者が npm や IDE を併用している場合は、環境変数 HTTP_PROXY とブラウザ設定の混線を 開発者向けプロキシ稿 で整理すると再発を防ぎやすいです。
よくある質問（補足）
Windowsの「インタネットオプション」でプロキシをオフにしたらChromeも直結になる？
Chromeは多くの場合、OSのLAN設定と整合します。手動で外すとClashが書き戻す前に不整合が出ることがあるため、Clash側のシステムプロキシトグルとセットで確認してください。
--proxy-serverを付けたショートカットは安全に戻せる？
ショートカットのプロパティから引数を削除すれば元に戻せます。検証用プロファイルを併用すると安全です。
Edgeは通るのにChromeだけダメなのはなぜ？
ポリシー、セキュアDNS、拡張、プロファイル差分が典型です。chrome://policyを比較してください。
TUNをオンにしたら全アプリが止まったら？
まずTUNをオフにし、競合VPNを切って復帰を確認します。詳細はTUN総覧記事を参照してください。
まとめ
Windows で Clash の システムプロキシ が有効でも Chrome だけが 直結 に見えるとき、YAML より前に疑うべきは LAN 実値、Chrome のセキュア DNS、拡張とセキュリティ製品、chrome://policy、そして 起動引数の残骸 です。本稿の 六手順 は、OS の LAN 設定と Clash の書き戻し確認、Chrome 内部設定の単純化、拡張／AV の切り分け、ポリシーと新規プロファイル試験、Clash TUN でのルート層取り込み、--proxy-server による明示指定と検証後の復元、という実務順に並んでいます。Firefox 向けの切り分けは 別稿 で対称的に扱っているため、ブラウザをまたいで症状が違う場合は両方を照合してください。
コア世代や GUI の表記差でトグル名が異なる場合は、Clash Meta（mihomo）のアップグレード を前提に画面と YAML を照合してください。クライアントの入手先は ダウンロードページ からまとめて確認できます。購読リンクでプロファイルを更新したあと、Chrome を再起動してログを確認する——この往復を習慣にすると、同種の不具合への復旧が速くなります。