なぜ「システムプロキシ」と切り離すのか
システムプロキシは、対応するスタックを持つ多くのデスクトップアプリに一括で効きます。便利な反面、社内VPNやMDMが別経路を前提にしている環境では、Clashが書き換えた設定と競合しやすいです。また、UWPや一部のバックグラウンド更新は、ユーザーが思っている以上にWinHTTP／WinINETの実効値に敏感です。そこで「Chromeだけ手元のClashに乗せ、それ以外は今までどおり」という分離は、副作用を抑えつつ目的を達成しやすいパターンになります。なお、職場端末では利用規約とセキュリティポリシーを必ず確認してください。本稿は個人環境での技術整理を主眼にしています。
Clash側の前提（ポートと稼働）
ブラウザからは通常、HTTPプロキシ（CONNECTを含む）としてClashのリスナーに接続します。Clash Verge Revの初期構成ではmixed-portがよく使われ、例として127.0.0.1:7890のような形になります。実際の番号は設定画面と生成YAMLの双方で一致しているか確認してください。Allow LANをオンにする必要は基本的にありません（同一端末上のChromeから127.0.0.1へ繋ぐだけなので）。システムプロキシトグルはオフのまま運用するのが本稿の想定です。Windowsでの初回セットアップの全体像はWindows向けセットアップ記事、macOSでシステム代理が絡む症状の切り分けはmacOSのシステムプロキシ診断記事と併せて読むと流れが掴みやすいです。
補足：ChromeにSOCKS5だけを直接指定することもできますが、環境によっては拡張やデバッグのしやすさからHTTPのPROXY行をPACで返す方式が扱いやすいです。
PACで何を返すか（最小の考え方）
PAC（Proxy Auto-Configuration）は、JavaScriptで「このホスト名ならこのプロキシ、それ以外は直結」といった分岐を書く仕組みです。Chromeは自動プロキシ設定URLとしてPACを読み込みます。典型例は、社内イントラやローカルはDIRECT、特定のサフィックスや海外サービスだけPROXY 127.0.0.1:ポートへ送る、という書き方です。ドメインリストは利用サービスに合わせて増減してください。以下は例示であり、実環境のホスト名に合わせて編集します。
function FindProxyForURL(url, host) {
if (isPlainHostName(host) ||
dnsDomainIs(host, ".local") ||
isInNet(dnsResolve(host), "10.0.0.0", "255.0.0.0") ||
isInNet(dnsResolve(host), "172.16.0.0", "255.240.0.0") ||
isInNet(dnsResolve(host), "192.168.0.0", "255.255.0.0") ||
isInNet(dnsResolve(host), "127.0.0.0", "255.0.0.0")) {
return "DIRECT";
}
if (dnsDomainIs(host, ".your-corp.example") || host === "intranet") {
return "DIRECT";
}
return "PROXY 127.0.0.1:7890; DIRECT";
}
dnsResolveは環境によって失敗しうるため、運用ではホスト名ベースの条件を厚くする・あるいは確実にDIRECTにしたい名前を列挙する、といった堅牢化が必要になることがあります。社内プロキシをChromeだけ経由させたい場合は、returnをPROXY 社内プロキシ:ポートに差し替える、といった二段構えもあります（その場合はClash側のルールと役割分担を誤らないよう注意）。本稿の主眼は「その他はOS既定のまま、Chromeの自動設定だけClashへ」という形です。
Windows：ChromeへPACを渡す
ローカルPACファイルを使う
テキストエディタで上記のような内容をchrome-clash.pacなどの名前で保存します。Chromeのアドレス欄にchrome://settings/systemを開き、コンピューターのプロキシ設定を開くではなく、Chrome自身の起動オプションでPACを指定する方法が分かりやすいです。ショートカットの「リンク先」に例えば次のフラグを追加します（パスは実ファイルに合わせてください）。
--proxy-pac-url="file:///C:/Users/YourName/AppData/Local/clash/chrome-clash.pac"
file:///のあとのドライブ文字はスラッシュ三つ＋パスという一般的な記法です。スペースを含むフォルダは避けるか、適切にエンコードしてください。複数プロファイルを使う場合は、プロファイルごとにショートカットを分けると切り替えが明確です。
小さなHTTPサーバーでPACを配る
ポリシーやバージョンによってはfile://のPAC読み込みに制限があることがあります。そのときは、ローカルでhttp://127.0.0.1:何番/pacのようにループバック上のHTTPでPACを配布する方法もあります。セキュリティ上、外向きに開かないことと、信頼できる生成元だけを置くことが前提です。
macOS：ChromeへPACを渡す
macOSでも基本は同様で、Chromeの起動引数に--proxy-pac-url=を付与するのが直球です。PACファイルを/Users/あなた/...に置くなら、file://形式のURLに変換します。ネットワーク環境（ロケーション）でシステム全体の自動プロキシを切り替える手法もありますが、それはSafariや他アプリにも波及するため、本稿の「ブラウザだけ分離」とは趣旨が異なります。システム側を触りたくない場合は、Chrome専用の起動ランチャーやAutomatorラッパーにフラグを固定する運用が扱いやすいです。
動作確認のすすめ方
まずClashの接続ログで、Chromeからのリクエストが期待どおりのルールと出口に乗っているかを見ます。次に、意図どおり社内サイトがDIRECT側に残っているか、証明書警告が増えていないかを確認します。Windowsで「ブラウザは通るがストア系だけおかしい」といった話題はUWPとループバックの記事の領域と隣接しますが、本構成ではシステムプロキシをClashが占有しないため、切り分けの軸が整理されやすいです。
限界と代替案（短く）
PACは主にプロキシ対応のHTTP(S)の振り分けに向きます。非HTTPやプロキシ非対応のUDP主体アプリまで同一端末で揃えたい場合は、TUNなど別レイヤの検討が必要になります。また、拡張機能型のプロキシはChromeに閉じますが、ポリシー・パフォーマンス・信頼性のトレードオフがあります。用途に応じて--proxy-server=の固定指定より--proxy-pac-urlの方がメンテしやすい、という判断もよくあります。
注意：会社支給機ではグループポリシーやEndpoint管理で起動引数やプロキシが上書きされることがあります。自己責任の範囲を越えないよう、事前承認を得てください。
まとめ
ChromeだけClashのローカルポートへ流し、システムプロキシは社内要件や直結のまま保つ——このパターンは、副作用を抑えつつブラウジングだけを整えたいときに有効です。手順の核は、Clashを常時リッスンさせ、PACでPROXY 127.0.0.1:実ポートを返すこと、そしてChrome起動時にそのPACを明示することです。設定の見直しはログと実ホスト名をセットで追うと再現性が上がります。同系のGUIクライアントでも、思想は共通で、安定した分流とDNS設計があれば運用は軽くなります。
パッケージの入手と更新確認は、リリースノートと対応関係が整理された公式配布導線を使うのが安全です。オープンソースの参照やIssueは各リポジトリが適していますが、日々のインストールの入口は分けて考えると迷いが減ります。