「システムプロキシがオン」でも「すべての通信がプロキシを通る」わけではない理由
Clash クライアントの「システムプロキシ」スイッチは、本質的にはオペレーティングシステムやデスクトップ環境のプロキシ設定項目(Windows の WinINet 設定、macOS のネットワークサービスのプロキシ、Linux の GSettings や環境変数)を書き換えるものです。この種の設定はシステムのプロキシ設定を能動的に読み取るプログラムにのみ有効で、代表例はブラウザや一部の GUI アプリです。これはネットワーク層での強制転送ではないため、プロセス側が設定を無視することもできます——これこそ「プロキシは確かにオンなのに、あるアプリだけプロキシを通らない」という現象が起きる根本原因です。
コマンドラインツール(curl、wget、git、パッケージマネージャーなど)の多くはシステムプロキシの設定を読み取らず、代わりに環境変数(http_proxy、https_proxy、all_proxy)を参照します。つまり、システムプロキシがオンであることと端末がプロキシを通せるかどうかは別問題であり、それぞれ異なる調査アプローチが必要になります。
アプリの種類を問わず一律に強制プロキシしたい場合、唯一確実な方法はTUNモードです——これはネットワークインターフェース層で通信を引き受けるため、アプリ側が能動的にプロキシ設定を読み取っているかどうかに依存しません。本記事の後半でシステムプロキシとTUNモードの選び方を具体的に説明します。
調査の前に一つ確認しておきましょう。Clash 自体が正常に動作しているか、使えるノードがあるかどうかです。コアが起動していない、あるいは購読ノードがすべて無効な場合、システムプロキシの設定が正しくても接続は確立できません。この種の問題はまず実行ログでプロキシポートが正常にリスニングしているか確認することをおすすめします。
ブラウザがプロキシを通らない場合の確認手順
ブラウザがプロキシを通らない原因は主に4つに分類できます:プロキシスイッチが反映されていない、ブラウザ独自のプロキシ設定がある、拡張機能やセキュリティソフトによる干渉、DNSがプロキシを通らないことによる一部漏出です。以下の順序で一つずつ確認していきます。
ステップ1:システムプロキシのスイッチ状態を確認する
Clash クライアントの設定画面を開き、「システムプロキシ」がオンになっているか、そしてリスニングポート(通常は HTTP/Mixed ポートで、デフォルトは 7890 前後)が正しいか確認します。一部のクライアントは設定ファイルを切り替えるとこのスイッチをリセットすることがあり、アップグレードやシステム再起動後にシステム側からオフに戻される場合もあります。
- Windows:「設定 → ネットワークとインターネット → プロキシ」を開き、「セットアップ スクリプトを使う」または「プロキシ サーバーを使う」がローカルアドレスと対応するポートを指しているか確認します。
- macOS:「システム設定 → ネットワーク → 使用中のネットワークサービス → 詳細 → プロキシ」を開き、Web プロキシ(HTTP)とセキュリティ Web プロキシ(HTTPS)の両方がチェックされ、正しいポートが入力されているか確認します。
- Linux(GNOME などのデスクトップ環境):「設定 → ネットワーク → ネットワークプロキシ」で「手動」モードになっているか、「自動」や「オフ」になっていないかを確認します。
ステップ2:ブラウザ独自のプロキシ設定を除外する
一部のブラウザ(特に Firefox)はデフォルトでシステムプロキシに追従せず、独自の接続設定を使います。Firefox で手動プロキシが設定されていたり「プロキシなし」が選択されていたりすると、システムプロキシが正常でも反映されません。確認箇所:
- Firefox:設定 → 一般 → ネットワーク設定 →「システムのプロキシ設定を使用する」が選択されているか確認。
- Chrome / Edge / 多くの Chromium 系ブラウザ:デフォルトでシステムプロキシに追従するため通常は個別設定は不要ですが、企業ポリシーや一部の拡張機能がこの動作を上書きすることがあるため、ブラウザのプロキシ設定画面でロックされていないか確認してください。
ステップ3:拡張機能やセキュリティソフトによる干渉を確認する
広告ブロック系の拡張機能、企業向けセキュリティクライアント、一部の VPN クライアントは、ネットワークリクエストの経路を強制的に変更したりプロキシ設定を横取りしたりすることがあります。まずブラウザのプライベート/シークレットモード(デフォルトで拡張機能が無効)で正常に戻るか試してみましょう。正常に戻るなら原因はどれかの拡張機能にあるので、一つずつ無効化して特定します。
ステップ4:DNSリクエストもプロキシを通っているか確認する
ブラウザが「つながるが遅い」「一部のサイトは正常で一部は異常」という症状は、多くの場合 DNS の漏出が原因です——ページのデータはプロキシを通っているのに、ドメイン名解決はローカル DNS を使っており、プロバイダやローカルネットワークによって先に干渉されている状態です。これは厳密には「プロキシが効いていない」わけではありませんが症状が似ているため、ルールモードで DNS ハイジャックや fake-ip モードが有効になっているかも併せて確認することをおすすめします。
プロキシ経路そのものが正常かどうかだけを確かめたい場合は、特定のサイトを先にテストするのではなく、IP 確認系のページに直接アクセスして出口 IP が変わるかを観察することをおすすめします——特定サイトの異常はルールによる振り分けで直結グループに割り当てられているだけの場合があり、プロキシ全体の失効を意味しないことがあります。
コマンドライン端末がプロキシを通らない場合の確認手順
端末ツールがプロキシを通るかどうかは、そのツールがプロキシ環境変数を読み取るか、そして変数が正しく設定され現在のセッションに継承されているかによって決まります。以下の順序で確認します。
ステップ1:環境変数が設定されているか確認する
macOS / Linux の端末で以下を実行します:
echo $http_proxy
echo $https_proxy
echo $all_proxy出力が空であれば、現在のセッションにプロキシ環境変数が存在しないため、端末コマンドはプロキシを通りません。手動設定の例(ポートは実際のクライアントのリスニングポートに置き換えてください):
export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"
export all_proxy="socks5://127.0.0.1:7890"Windows で PowerShell を使う場合の対応コマンド:
$env:http_proxy="http://127.0.0.1:7890"
$env:https_proxy="http://127.0.0.1:7890"ステップ2:変数が正しい設定ファイルに書き込まれているか確認する
export で一時的に設定した変数は現在の端末セッションでのみ有効で、新しく開いた端末ウィンドウには継承されません。長期的に有効にしたい場合は shell の起動時読み込みファイル、例えば ~/.zshrc、~/.bashrc、~/.bash_profile(使用している shell やシステムによって異なります)に書き込む必要があり、変更後は source ~/.zshrc を実行するか端末を開き直して反映させます。
ステップ3:ツール自体がこれらの変数を読み取るか確認する
ツールによって従うルールが異なります:
curl、wget:デフォルトでhttp_proxy/https_proxyを読み取ります。大文字小文字は通常区別されませんが、小文字で統一することをおすすめします。git:システム環境変数を自動で転送しないため、git config --global http.proxyとhttps.proxyを個別に設定する必要があります。- パッケージマネージャー(npm、pip、apt など):それぞれ独自のプロキシ設定項目があり、環境変数を認識するとは限らないため、対応する設定ファイルにプロキシアドレスを個別に記載する必要があることが多いです。
- Docker、Docker Compose:コンテナ内のプロセスはデフォルトでホストの環境変数を共有しないため、Docker の設定または
docker-compose.ymlにプロキシ変数を明示的に渡すか、Docker daemon 側で個別にプロキシを設定する必要があります。
ステップ4:最小限のコマンドでプロキシ経路を検証する
ツール自体のロジックによる干渉を排除するため、curl で直接プロキシポートが本当に使えるかテストします:
curl -x http://127.0.0.1:7890 -I https://www.example.comこのコマンドが正常にレスポンスヘッダーを返すなら、プロキシポート自体は正常に動作しており、問題は該当ツールがプロキシ設定を正しく読み取れていないことにあります。このコマンド自体がタイムアウトやエラーになる場合は、問題は Clash クライアントまたはノード側にあるので、クライアントに戻ってノードの接続状況とリスニングポートを確認してください。
端末系の問題に対しては「curl に -x パラメータを付けて手動でプロキシを指定してテストする」ことを最初の検証手順とすることをおすすめします——これにより問題の範囲を「プロキシポート」か「個別ツールの設定」かのどちらかに素早く絞り込むことができ、ツール自身の複雑な設定項目の中で堂々巡りすることを避けられます。
システムプロキシスイッチとTUNモード、どちらを選ぶべきか
システムプロキシと TUN モードは適用範囲がまったく異なる2つの仕組みです。選ぶ前にまず自分の使用シーンを明確にしておくことをおすすめします。
システムプロキシスイッチの特徴
システムプロキシはオペレーティングシステムやブラウザが読み取るプロキシ設定項目を書き換えるだけで、負荷が小さく切り替えが柔軟で、システムのネットワークスタックに対して非侵襲的という利点があります。欠点は適用範囲が完全ではないことです——システムプロキシの設定を能動的に読み取らないプログラム(一部のコマンドラインツール、ゲーム、一部のバックグラウンドサービス)はプロキシの適用対象外となり、環境変数やアプリ内のプロキシオプションを別途手動設定する必要があります。
TUNモードの特徴
TUN モードはシステム内に仮想ネットワークインターフェースを作成し、Clash コアがそのインターフェースを通過するすべての通信を引き受けます。アプリがプロキシを能動的に設定しているかどうかを問いません。つまり、コマンドラインツール、バックグラウンドサービス、ゲームなど、もともと「システムプロキシを通らない」通信も一括して処理され、グローバルプロキシに近い効果が得られます。代償として設定項目が複雑になり(通常はプロセスモードの追加、ルーティングテーブルやファイアウォールルールの調整が必要)、一部のシステムでは仮想ネットワークカードの作成に管理者/root権限が必要です。
2つの方式の選び方
- ブラウザと一般的なデスクトップアプリだけプロキシを通せばよい場合:システムプロキシスイッチを優先しましょう。設定が簡単で、問題が起きた際も該当ソフトを特定しやすいです。
- コマンドラインツール、スクリプトタスク、バックグラウンドサービスを一括してプロキシに通したいが、一つずつ環境変数を設定したくない場合:TUN モードを優先的に検討しましょう。一度の設定で大半のシーンを網羅できます。
- 細かい振り分け制御(一部のアプリは直結、一部はプロキシ経由)も必要な場合:TUN モードとプロセスルールや IP セグメントルールを組み合わせるほうが、ツールごとに個別設定するより手間が少なくなりますが、ルール設定の書き方を理解する時間が必要です。
- 接続異常が発生した際は、まず現在使っているのがシステムプロキシか TUN モードかを確認し、それに応じて調査してください——両者の障害の現れ方や確認経路は異なるため、混同して調査すると回り道になりやすいです。
TUN モードをオンにしても一部の通信がプロキシを迂回する場合、多くはルーティングテーブルやファイアウォールルールの衝突が原因です。まず他の VPN やネットワーク加速系ツールを一時的に停止して再テストし、複数のネットワーク引き受けツールが互いに衝突していないか確認しましょう。
よくある誤判定のケースと調査の心構え
システムプロキシ関連の問題では、いくつかの現象が「プロキシが効いていない」と誤判定されがちですが、実際の原因はプロキシ設定そのものにはありません:
- ルールによる振り分けで特定サイトが直結になっている:設定ファイル内に特定のドメインや IP セグメントに対する直結ルールがある場合、そのサイトがプロキシを経由しないのは想定どおりの動作であり、故障ではありません。
- ノード自体の接続異常:プロキシ設定は正しいがノードが無効になっている場合も「ページが開けない」という現象は同じです。まずクライアント内で個別にノードの遅延と接続性をテストする必要があります。
- DNSキャッシュが更新されていない:プロキシやノードを切り替えた後、ローカルの DNS キャッシュが古い解決結果を指したままの場合があります。調査前にシステムの DNS キャッシュをクリアするか、ネットワークサービスを再起動することをおすすめします。
- 複数のプロキシツールが同時に動作している:他のプロキシソフトや VPN を同時に起動していると、システムプロキシの設定が後から起動したツールに上書きされることがあります。調査時は現在ネットワーク設定を変更しているツールが一つだけであることを先に確認しましょう。
全体の調査の流れとしては、まず Clash 自体が正常に動作し使えるノードがあることを確認し、次にシステムプロキシのスイッチや環境変数の設定が正しいことを確認し、最後に個別のアプリがこれらの設定に従っているかを確認する、という順序でまとめられます。この順序で階層ごとに検証していくことで、間違った階層で堂々巡りをして原因を見つけられないという事態を避けられます。