Clash システム代理が効かない原因:ブラウザとターミナルは別々に対処する

B-01まずどの階層で問題が起きているかを見極める

「Clash を起動したのに効かない」という言い方は曖昧すぎます。本当の原因を突き止める前に、まず「システム代理が及ぶ範囲」を整理して把握する必要があります。Clash クライアントがシステム代理モードで行っているのは、OS のネットワーク設定(Windows の インターネット オプション レジストリ項目、macOS のネットワークサービスのプロキシ欄)を書き換え、システム代理のプロトコルスタックに従うプログラムがローカルのリスニングポート(一般的には HTTP プロキシ 127.0.0.1:7890 やミックスポート)を自動的に使うようにすることです。ただし OS の「システム代理」というスイッチは、そのシステム代理設定に従うプログラムにしか効きません。ブラウザ、ターミナルのコマンドライン、一部のバックグラウンドサービスでは、この設定の反映度がまちまちです。

つまり同じ「効かない」という症状でも、ブラウザ側とターミナル側では調査の切り口がまったく異なります。一緒に対処しようとするとむしろ混乱するだけです。本稿では「ブラウザ側 → システム層 → ターミナル側」の3段階に分けてチェックリストを示し、最後に検証コマンドを付けています。順番通りに一つずつ確認し、途中を飛ばさないようにしてください。

B-02ブラウザ側の調査:拡張機能の競合と内蔵プロキシ設定の優先順位

ブラウザがプロキシを通らないという報告は最も多く、原因は主に3つに集中しています。優先度順に確認していきましょう。

1. プロキシ管理系の拡張機能がインストールされている

SwitchyOmega や Proxy SwitchySharp といった拡張機能は、ブラウザのプロキシ設定インターフェースを乗っ取ります。インストールして有効化すると、ブラウザは OS のシステム代理よりも拡張機能側の設定を優先します。この種の拡張機能が現在「直接接続」や、失効した別のポートを指す設定になっている場合、Clash 側でシステム代理を設定していてもブラウザは通信できません。対処法は、拡張機能側に Clash のローカルポートを指す規則を新規作成すること、あるいは一時的に拡張機能を無効化して復旧するか確認することです。

2. ブラウザの企業ポリシーや過去の残存設定

一部のブラウザ(特に企業環境でプリインストールされているもの)は、グループポリシーによってプロキシ設定がロックされており、システム代理側の変更が反映されません。ブラウザのアドレスバーから内蔵のネットワーク設定ページにアクセスし、プロキシの取得元が「システムのプロキシ設定を使用」になっているか、「直接接続」や「手動設定」になっていないかを確認してください。手動設定になっていて古いアドレスを指していた場合は、その設定を削除してブラウザを再起動すれば解決します。

3. PAC スクリプトモードでポートや規則が誤っている

Clash クライアントの一部バージョンは、PAC(Proxy Auto-Config)スクリプト方式でシステム代理を制御する機能を備えています。PAC スクリプトの判定ロジックに誤りがあったり、リスニングポートがクライアントの実際のポートと一致していなかったりすると、ブラウザが PAC スクリプトから受け取る結果は「直接接続」になり、プロキシが一切効かないように見えます。まずは標準の「システム代理」モード(PAC を使わない方式)に切り替えて、問題が解消するかを確認し、その後 PAC を使い続けるかどうか判断することをお勧めします。

B-03システム層の調査:システム代理が実際に書き込まれているか確認する

ブラウザ側の調査で解決しない場合は一歩戻り、「システム代理」という層そのものが本当に有効になっているかを確認します。Clash のスイッチをオンにしたからといって、必ず反映されているとは限りません。

Windows:インターネットオプションを確認する

「コントロールパネル → ネットワークとインターネット → インターネット オプション → 接続 → LAN の設定」を開き、「LAN にプロキシ サーバーを使用する」にチェックが入っていて、アドレスとポートが Clash クライアントの設定画面に表示されているものと一致しているかを確認します。ここが空欄の場合、クライアントの「システム代理として設定」というスイッチが実際には正しく書き込まれていないことを意味します。よくある原因はクライアントの権限不足(管理者として実行する必要がある)や、他のプロキシソフト(企業 VPN クライアントなど)との書き込み競合で、後から起動した側が前の設定を上書きしてしまうケースです。

macOS:ネットワークサービスのプロキシ欄を確認する

「システム設定 → ネットワーク → 現在使用中のネットワークサービス → 詳細 → プロキシ」で、「Web プロキシ(HTTP)」と「セキュリティ Web プロキシ(HTTPS)」にチェックが入り、Clash のリスニングアドレスとポートが入力されているかを確認します。macOS で複数のネットワークサービスが同時に有効(例えば有線 LAN と Wi-Fi が両方オンライン)な場合、Clash は現在優先されているサービスにしか書き込まないため、実際にルーティングされているのが別のサービスだと「設定したのに効かない」という現象が起こります。有効になっているネットワークサービスと Clash が書き込んだサービスが同一かどうか確認してください。

B-04ターミナルのコマンドラインがプロキシを通らない:環境変数がカギ

ターミナル(Terminal、PowerShell、Bash)で使う curl、wget、git、npm、pip などのコマンドラインツールは、そのほとんどがシステム代理の設定を読み込みません。代わりに、それぞれが定めた環境変数を参照します。これがターミナルでプロキシが効かない最大の、かつ最も見落とされがちな原因です。システム代理の書き込みは成功していて、ブラウザも正常に通信できているのに、ターミナルではタイムアウトや接続失敗が出るというのは、まったく正常な現象であり、故障ではなく追加の設定が必要な段階に過ぎません。

手動で設定が必要な環境変数

多くのコマンドラインツールが参照しているのは http_proxy と https_proxy(大文字形式の HTTP_PROXY、HTTPS_PROXY)という2つの環境変数で、値には Clash クライアントのローカル HTTP プロキシのリスニングアドレスを指定します。

macOS / Linux(Bash または Zsh)、一時的に有効化する場合。現在のターミナルセッション内でのみ有効です:

export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"

ターミナルを開くたびに自動で有効にしたい場合は、上記2行を ~/.zshrc または ~/.bash_profile の末尾に追加し、保存後に source ~/.zshrc を実行すればすぐに反映されます。

Windows PowerShell、一時的に有効化する場合:

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"

常時有効化したい場合は、PowerShell のプロファイル($PROFILE が指すスクリプト)に同じ2行を追加するか、システムの環境変数画面からユーザー環境変数を新規作成してください。

独自のプロキシ設定を持つツールもある

git は上記の環境変数を設定していても、HTTPS プロトコルのリポジトリに対しては別途設定が必要になるバージョンもあります:

git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

npm や pip も同様で、それぞれ npm config set proxy / npm config set https-proxy、あるいは pip install 実行時に --proxy オプションを追加するか、pip.conf に設定を記述します。こうしたツール独自の設定項目は環境変数よりも優先されるため、環境変数を設定済みなのにツールがプロキシを通らない場合は、まずそのツールに独自のプロキシ設定があり、それに上書きされていないか確認してください。

B-05TUN モードでシステム代理と環境変数の二重設定を回避する

システム代理にも従わず、環境変数も読み込まないアプリ(一部の GUI アプリ、ゲームクライアント、一部の言語ランタイムのネットワークライブラリなどでよく見られます)に頻繁に遭遇する場合は、TUN モードに切り替えるほうが手間が省けます。TUN モードは Clash Meta(mihomo コア)およびそれをベースとするクライアント(Clash Verge Rev、FlClash など)がサポートしており、仮想ネットワークカードを作成してシステムの全アウトバウンド通信を横取りする仕組みです。アプリケーション層がプロキシ設定を読み込むかどうかに依存しないため、ブラウザとターミナルのコマンドラインが同時に有効になり、個別に設定する必要がありません。

TUN モードを有効にするには、通常クライアントが管理者権限/Root 権限を取得して仮想ネットワークカードを作成する必要があります。macOS や一部の Linux ディストリビューションでは追加のネットワーク拡張コンポーネントのインストールが必要になることもあります。具体的な有効化手順は各クライアントの「TUN モード」または「Tun アダプター」設定項目にあります。有効化する前にシステム代理オプションをオフにしておくことをお勧めします。2つの横取り方式が重なるとルーティングが異常になる可能性があります。

B-06一つずつ検証する:修正が本当に効いているか確認する

設定を変更した後は「なんとなくつながった気がする」で判断せず、以下のコマンドを一つずつ実行して検証してください。システム代理が効いているのか、ターミナルが効いているのか、それともまだ効いていないのかを明確に区別できます。

ターミナルの環境変数が読み込まれ、実際にプロキシを通っているかを検証する:

curl -x http://127.0.0.1:7890 https://www.gstatic.com/generate_204 -I

HTTP/1.1 204 No Content が返れば、プロキシポート自体は正常に動作しています。続けて -x オプションを付けず、設定済みの環境変数だけに依存して再度テストします:

curl https://www.gstatic.com/generate_204 -I

この時も 204 が返れば、環境変数が確実に curl に読み込まれ、有効になっていることを意味します。タイムアウトや失敗が発生する場合は、環境変数が現在のセッションに正しくエクスポートされていないことを示しています。変数名の大文字・小文字や、設定ファイルが正しく読み込まれているかを再確認してください。

システム代理のポートがシステムに正しく登録されているかを検証する(Windows PowerShell):

netsh winhttp show proxy

このコマンドが表示するのは WinHTTP 層のプロキシ設定であり、ブラウザが使用する WinINet 層の設定と完全には一致しない場合があります。両者が示すアドレスが異なる場合、それがブラウザでプロキシが通らない原因の一つになっていることが多いため、ブラウザのプロキシ設定側でも手動で確認してください。

• ブラウザがプロキシを通らない場合:まず拡張機能、次に内蔵プロキシの取得元、最後に PAC スクリプトの誤りを確認する。
• システム代理スイッチがオンなのに効かない場合:Windows のインターネットオプション / macOS のネットワークサービスのプロキシ欄が実際に書き込まれているか、複数ネットワークサービスの競合がないかを確認する。
• ターミナルのコマンドラインがプロキシを通らない場合:http_proxy / https_proxy 環境変数を設定し、git、npm、pip などのツールについては個別に設定項目を確認する。
• 同種の問題が繰り返し発生する場合:TUN モードへの切り替えを検討し、全体の通信を一括で制御する。