症状の整理：システム プロキシはオンなのにブラウザだけ直結しがち

Clash／Mihomo 系のクライアントを起動し、「システム プロキシに設定」や OS の手動プロキシも有効にしたつもりでも、Google Chrome や Microsoft Edge を開くと特定サイトだけ国内のまま読み込まれる、速度が極端に違う、ターミナルの curl や別アプリだけは通る――といった経路のずれに悩むことがあります。これはプロキシが「壊れている」より、Chromium 系ブラウザが参照するプロキシ決定の優先順位が、想像している OS 設定と一致していないことが多い、という理解が実務的です。

逆に、すべてを端末や TUN に任せたい場合は経路が一本化されますが、開発用途で「ブラウザだけ別ポリシー」「特定ドメインだけ別プロファイル」といった細かい分流をしたい読者も多いでしょう。本章では最終的に SwitchyOmega（正式名称は拡張機能ストア掲載名により Proxy SwitchyOmega など）のようなブラウザ内スイッチを前提に、Clash の mixed-port と 127.0.0.1 を軸に組み立てます。

なぜ Chrome／Edge は OS とすれ違うのか

第一に、拡張機能や独自ポリシーがプロキシ設定を上書きしている場合があります。企業端末では管理ポリシーによりプロキシが固定され、ユーザーの OS 設定より優先されることも珍しくありません。

第二に、セキュア DNS（HTTPS DNS や DNS over TLS）をブラウザ側だけが有効にしていると、名前解決と実トラフィックの組み合わせが期待と異なり、挙動が「直結に見える」と感じることがあります。切り分けの段階で一時的にオフにし、Clash 側の DNS モード（fake-ip と redir-host の読み分け）を合わせるのが第二段になります。深掘りはTUN／ルーティングの稿や接続ログ中心の記事も併読ください。

第三に、そもそも「システム プロキシに反映」を押したつもりでも、クライアントが指しているポートと、ブラウザが実際に接続している待受が別番号になっているケースです。YAML や GUI で mixed-port を変更したあと、古い 7890 を叩き続けている、などが起こりえます。疑わしいときはポート占有の稿で listen を確認すると早いです。

Clash 側：mixed-port、127.0.0.1、SOCKS と HTTP

Clash Meta／Mihomo 互換の典型構成では、mixed-port が単一の入口で HTTP プロキシと SOCKS5 の両方を受け付けます（クライアント実装により細部は差があります）。したがってブラウザ拡張の「プロトコル」としては、まず HTTP で 127.0.0.1 と ご自身の mixed-port 番号を指定するのがわかりやすいです。localhost でも動きますが、IPv4／IPv6 の解決差で悩む環境では 127.0.0.1 に固定すると安定しやすいです。

別途 socks-port だけを開いている構成なら、拡張側のプロトコルを SOCKS5 に合わせ、ホストとポートをそちらに揃えます。ポイントは「ブラウザが見に行く URL」と「Clash のログに SYN が届いているか」を一致させることであり、プロトコル名より番号の取り違えのほうが対応コストが高いです。

Allow LAN（allow-lan に相当）をオフにしていると、まれにループバック以外の経路と噛み合わず挙動が不安定になる報告があります。まずは同一マシンのブラウザだけを対象にする場合でも、検証中だけオンにしてから戻す、という運用でも構いません。

SwitchyOmega の導入とプロファイル作成

Chrome／Edge とも Chromium ベースのため、同系統の拡張機能が利用できることが多いです（ストアの掲載状況や組織ポリシーで禁止されている場合は管理者設定が必要です）。インストール後、オプション画面で新しいプロファイルを追加し、種別は プロキシ プロファイルを選びます。

プロトコルを HTTP とし、サーバーに 127.0.0.1、ポートに設定ファイルの mixed-port（例としてよくある 7890）を入力します。HTTPS の欄が別にある UI では、同じ値を複製して構いません。SOCKS5 で張る場合はスキームを SOCKS5 に変え、同じホスト／ポートを指定します。

# Example — replace 7890 with your mixed-port from Clash / client UI
HTTP   127.0.0.1 : 7890
HTTPS  127.0.0.1 : 7890  (same as HTTP in most setups)
# or SOCKS5 profile:
SOCKS5 127.0.0.1 : 7890

「認証が要るリモート プロキシ」ではなく、ローカルの Clash 入口に向ける構成なので、ユーザー名／パスワードは通常空のままで問題ありません。もし拡張が接続エラーを示すときは、TLS の中間者ではなく拒否・タイムアウトの区別をログで確認してください。

自動切替：条件に応じてプロキシ／直結を分ける

すべてのタブを常時プロキシにすると、国内の金融サイトや社内ポータルが遅くなることがあります。自動プロキシ切り替え（Auto Switch）プロファイルでは、ドメインのパターンごとに「先ほどのプロキシ プロファイルへ」または「直接つなぐ」を割り当てられます。Clash 側ですでに細かいルールを書いている場合でも、ブラウザ拡張はブラウザが送るトラフィックの入口だけを切り替えるレイヤーである点を押さえておくと設計がブレません。

運用のコツは、衝突しやすいドメイン（開発者向け CDN や API ホスト）を明示リストの先頭に置き、最後にデフォルトを「直接接続」か「プロキシ」かで揃えることです。チームで共有するなら、パターンを文章化しておくと再現実験が速くなります。

Edge 利用時の補足

Microsoft Edge でも基本手順は Chrome と同様です。組込みの「プロキシ設定」画面から手動で 127.0.0.1 とポートを指定する方法もありますが、サイト別の細かい切替まで含めると拡張機能のほうが操作しやすい読者が多いです。別プロファイル（仕事用／個人用）を分けている場合は、プロファイルごとに拡張の有効化状態が異なる点に注意してください。

動作確認と切り分け

まず Clash のダッシュボードやログで、ブラウザからのアクセス試行に対応するエントリが増えるかを見ます。次に、意図したプロファイルが拡張のアイコンから選択されているかを確認します。複数の拡張がプロキシを争う場合は、競合を一時的に無効化して単純化します。

Windows クライアントの初期設定全般はWindows 向けセットアップ稿と揃えると、システム反映ボタンと実ポートのズレが減ります。

セキュリティとポリシー

ローカル プロキシへトラフィックを寄せる構成は、マルウェア対策ソフトや会社のポリシーに抵触する場合があります。個人利用でも、信頼できる拡張機能のみを入れ、権限の過剰付与に注意してください。ソースコードの透明性を確認したい場合は公式リポジトリを参照するのは有用ですが、実行ファイルの入手経路は後述のサイト内導線と混同しないようにしてください。

まとめ

Chrome／Edge がシステム プロキシとすれ違うとき、第一歩は「ブラウザが最終的にどのプロキシ決定を使っているか」を特定することです。OS や Clash の「システムへの反映」が正しくても、拡張・ポリシー・DNS・ポート番号のいずれかで分岐します。SwitchyOmega 系のツールで 127.0.0.1 の mixed-port へ明示接続させれば、少なくともブラウザ内の経路は再現可能に固定でき、ルールの検証もしやすくなります。

クライアントの入手や各 OS 向けの入口はダウンロードページで整理しています。GitHub をソース確認に使う場合も、配布物の取り違えを防ぐ意味でサイト側の導線を起点にすると安全です。設定が腹落ちしたら、→ Clash を無料ダウンロードし、ブラウザと mixed-port の組み合わせを一度通してみるところから進めてください。