トラブルシューティング 読了目安 13分

システムプロキシを有効にしても反映されない？ブラウザとターミナルを分けて調べる完全ガイド

ブラウザはシステムプロキシを使うのに、ターミナルは使わない原因を切り分け。設定、環境変数、export、ポート競合、バイパスリストを解説。

まず問題が起きている層を確認する

「システムプロキシが有効」という表示は、ClashクライアントがOSのプロキシアドレスをローカルの待受ポートに変更しようとしていることを示すだけで、すべてのアプリがその設定を読み取るとは限りません。Chrome、Edge、Safariは通常システムプロキシに従いますが、Firefoxは独自の接続設定を使えます。curl、Git、npm、Pythonのパッケージマネージャーなど、多くのターミナル用プログラムは直接ネットワークへ接続することがあります。切り分けではノードを何度も切り替えるのではなく、まずブラウザ、ターミナル、Clashのコアを分けて確認しましょう。

開始前に、クライアントで3点を確認します。設定ファイルが有効になっていること、プロキシグループに利用可能なノードがあること、コアが実行中であることです。クライアントによってメニュー名は少し異なりますが、一般的な場所は「設定」→「現在の設定」、「プロキシ」→「プロキシグループ」、「設定」→「システムプロキシ」です。ログ画面に新しい接続がまったくない場合、問題はアプリからローカルプロキシポートまでの間にあることが多く、ログに接続が出ているのにタイムアウト、ルールエラー、ノード失敗が表示される場合は、設定とリモートノードを確認します。

4つの症状からすばやく特定する

症状 優先して確認する項目 よくある原因
すべてのウェブページを開けない Clashの待受ポートとシステムプロキシのアドレス コアが起動していない、ポート番号の誤り、ポートの競合
ブラウザは使えるがターミナルは失敗する ターミナルの環境変数とプログラム独自の設定 コマンドラインツールがシステムプロキシを読み取っていない
ブラウザで一部のサイトだけ失敗する ルールの判定、バイパスリスト、拡張機能 ドメインが直接接続されている、プロキシ拡張機能がシステム設定を上書きしている
TUNを有効にすると使えるが、システムプロキシでは失敗する アプリがHTTPまたはSOCKSプロキシに対応しているか アプリがシステムプロキシを無視して直接接続している

Clashの待受ポートとシステムプロキシのアドレスを確認する

Clashでよく使われるローカル待受には、HTTPポート、SOCKS5ポート、mixed-portがあります。古い設定ではHTTPを7890、SOCKS5を7891にすることが多く、mihomoではmixed-port: 7890だけを有効にして、同じポートでHTTPとSOCKS5の両方を受け付ける構成もよくあります。ポート番号は固定ではないため、最終的にはクライアントの「設定」→「ポート設定」または現在の設定にある実際の値を確認してください。

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info

この設定は、プロキシがローカルの127.0.0.1:7890だけで待ち受けることを示します。システムプロキシのサーバーアドレスも127.0.0.1を指定し、HTTPとHTTPSには同じmixedポートを入力できます。サブスクリプションのリモートノードアドレスをOSのプロキシ設定に入れたり、Clashのコントロールポートを通信ポートと取り違えたりしないでください。

Windows 11での確認手順

  1. 「設定」→「ネットワークとインターネット」→「プロキシ」を開きます。
  2. 「プロキシサーバーを使う」が有効になっているか確認します。
  3. アドレスが127.0.0.1で、ポートがClashの現在の待受ポートと一致しているか確認します。
  4. クライアントが自動構成スクリプトを使っている場合は、「セットアップスクリプトを使う」に表示されたアドレスが有効か確認します。
  5. システムプロキシを切り替えた後は、問題のアプリをいったん終了して再起動し、古い接続プールが使われ続けないようにします。

macOSでの確認手順

  1. 「システム設定」→「ネットワーク」を開きます。
  2. 現在使用中のWi-FiまたはEthernet接続を選択します。
  3. 「詳細」→「プロキシ」を開きます。
  4. WebプロキシHTTP、安全なWebプロキシHTTPS、SOCKSプロキシのアドレスとポートを確認します。
  5. Clashクライアントに設定を管理させる場合は、別のプロキシツールが書き込んだ古いポート設定を残さないでください。

ポートが待ち受け中か直接テストする

WindowsではPowerShellで次のコマンドを実行できます。Listenが表示されるかTCP接続を確立できれば、ローカルポートは開いています。接続に失敗する場合は、まずコアを再起動するか、ポート競合を解消してください。

Test-NetConnection 127.0.0.1 -Port 7890
Get-NetTCPConnection -LocalPort 7890 -ErrorAction SilentlyContinue

macOSとLinuxではlsofで待受プロセスを確認できます。

lsof -nP -iTCP:7890 -sTCP:LISTEN
nc -vz 127.0.0.1 7890

待受プロセスが現在のClashまたはmihomoではない場合は、ポートを占有している古いクライアントを終了してから、使用中のクライアントを起動します。「設定」→「ポート設定」で未使用のポート（例：7892）に変更し、システムプロキシを再度有効にしてOSへ新しい値を反映させる方法もあります。

ブラウザで反映されない場合の確認項目

Chromium系ブラウザは通常OSのプロキシ設定を読み取りますが、ブラウザ拡張機能、組織のポリシー、独立したユーザー設定によって実際の経路が変わることがあります。切り分けではまず通常ウィンドウを開き、プロキシ切り替え用の拡張機能を一時的に無効にして対象ページへアクセスします。プライベートウィンドウでもすべての拡張機能が無効になるとは限らないため、拡張機能の管理画面で状態を確認してください。

ChromeとEdge

  • Chromeでは「設定」→「システム」→「パソコンのプロキシ設定を開く」に進み、現在のシステムのプロキシ画面へ移動することを確認します。
  • Edgeでは「設定」→「システムとパフォーマンス」→「コンピューターのプロキシ設定を開く」に進みます。
  • ブラウザのプロセスを完全に終了してから再起動します。タブを1つ閉じるだけでは、既存の長時間接続は解放されません。
  • Clashのログで対象ドメインを検索し、どのルールに判定されたか確認します。DIRECTと表示される場合は、ブラウザのポートではなくルールの順序を確認してください。
  • ブラウザが組織のポリシーで管理されている場合は、アドレスバーでchrome://policyまたはedge://policyを開き、固定プロキシポリシーが存在しないか確認します。

Firefox独自の接続設定

Firefoxはシステムプロキシに従わない設定にできます。「設定」→「一般」→「ネットワーク設定」→「設定」を開くと、通常は「プロキシなし」「自動検出」「システムのプロキシ設定を使用」「手動でプロキシを設定」の4種類があります。Clashのシステムプロキシに従わせる場合は「システムのプロキシ設定を使用」を選択します。個別にテストする場合は手動設定を選び、127.0.0.1と実際のポートを入力します。

SOCKS5を手動設定する場合、プロキシアドレスに127.0.0.1、ポートにClashのSOCKSまたはmixedポートを入力し、SOCKS v5を選択します。「SOCKS v5使用時にDNSもプロキシを使用する」という項目があれば、診断中は有効にすると、ドメイン解決も同じ経路で処理できます。

バイパスリストを確認する

システムプロキシは通常、localhost、127.0.0.1、ローカルネットワークのアドレス、ユーザーが追加したドメインをバイパスします。Windowsのプロキシ画面にある「次のエントリで始まるアドレスにはプロキシサーバーを使わない」、macOSのプロキシ画面にある「これらのホストとドメインのプロキシ設定を無視」も、該当する宛先を直接接続させます。

特定のドメインがClashのログに一度も表示されない場合は、まずバイパスリストからそのドメインとワイルドカード指定を削除し、ブラウザを再起動します。ルーターの管理画面など、LAN内のページは通常直接接続のままにしておくべきです（例：192.168.1.1）。テストのためにローカルアドレスの例外をすべて削除しないでください。

ターミナルがシステムプロキシを使わない場合の対処法

ターミナルはコマンドを実行する環境にすぎません。プロキシを使うかどうかは、curl、Git、npm、pipなど個々のプログラムが決めます。多くのコマンドラインツールはHTTP_PROXY、HTTPS_PROXY、ALL_PROXYを読み取りますが、小文字の変数だけを読むものや、独自の設定ファイルを優先するものもあります。そのためブラウザが使えていても、ターミナルには個別の設定が必要です。

macOS、LinuxとBash、Zsh

現在のターミナルセッションだけで有効になるHTTPプロキシは次のように設定します。プロキシアドレスのhttp://は、ターミナルのプログラムがHTTPプロキシプロトコルでローカルポートへ接続することを示しており、対象サイトがHTTPに限定されるという意味ではありません。

export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export NO_PROXY="localhost,127.0.0.1,::1"
export no_proxy="$NO_PROXY"

SOCKS5を使う場合は、この変数に対応したプログラムへ次のように設定できます。

export ALL_PROXY="socks5h://127.0.0.1:7890"
export all_proxy="$ALL_PROXY"

socks5hのhは、ドメイン名をSOCKSプロキシ側で解決することを示します。ローカルDNSとプロキシ経由の経路が一致しない問題を減らせます。すべてのプログラムがこの形式に対応しているわけではないため、非対応の場合はプログラム独自のプロキシオプションを使ってください。

Windows PowerShell

$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
$env:ALL_PROXY = "socks5h://127.0.0.1:7890"
$env:NO_PROXY = "localhost,127.0.0.1,::1"

これらの変数は、現在のPowerShellウィンドウと、そこから起動した子プロセスにだけ影響します。ウィンドウを閉じると無効になるため、切り分けに適しています。削除する場合は次を実行します。

Remove-Item Env:HTTP_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:HTTPS_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:ALL_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:NO_PROXY -ErrorAction SilentlyContinue

Windowsコマンドプロンプト

set HTTP_PROXY=http://127.0.0.1:7890
set HTTPS_PROXY=http://127.0.0.1:7890
set NO_PROXY=localhost,127.0.0.1,::1

一時的な診断だけなら、すぐに永続環境変数へ書き込む必要はありません。古いポートがシステムレベルの変数に残ると、Clashが別のポートへ変更された後も、新しく起動したターミナル用プログラムは古いアドレスへ接続し続けます。その結果、「システムプロキシは正しいのにコマンドだけ失敗する」状態になります。

curlでプロキシ、DNS、対象サイトを分けてテストする

curlはプロキシを直接指定できるため、システムプロキシや現在の環境変数に依存しません。まず明示的なHTTPプロキシでリクエストを送り、-vを付けて接続過程を確認します。

curl -v --proxy http://127.0.0.1:7890 https://example.com/

出力の最初に127.0.0.1:7890への接続が表示され、Clashのログにexample.comが追加されれば、ターミナルからClashまでの経路は機能しています。Connection refusedと表示された場合は、まずポートとコアを確認します。ローカル接続は成功したのにその後タイムアウトする場合は、プロキシグループのノード、ルール判定、リモート接続を確認してください。

SOCKS5は次のようにテストできます。

curl -v --proxy socks5h://127.0.0.1:7890 https://example.com/

次に、プロキシを指定しないコマンドで比較します。

curl -v https://example.com/

明示的なプロキシでは成功するのに通常のコマンドが失敗する場合、Clash自体は動作しており、問題は環境変数またはプログラム設定に絞られます。両方のコマンドが失敗する場合は、引き続きログを確認します。明示的なプロキシのリクエストがログに入らないなら、ポートの誤りである可能性が高く、ログに入ってから失敗するなら、設定、ルール、ノード経路の問題です。

環境変数の実際の値を確認する

macOSとLinuxでは次を実行します。

env | grep -i proxy

PowerShellでは次を実行します。

Get-ChildItem Env: | Where-Object Name -Match "PROXY"

古いアドレス、古いポート、重複した変数を重点的に探します。たとえばHTTPS_PROXYが127.0.0.1:7890を指している一方で、小文字のhttps_proxyが127.0.0.1:1080を指している場合があります。プログラムによって読み取り順が異なるため、重複した値が結果の不一致を招きます。診断中は大文字と小文字の変数を同じ値にそろえてください。

Git、npmなどのツール独自のプロキシ設定

環境変数が正しいのに1つのツールだけ失敗する場合は、そのツール専用の設定を確認します。専用設定は通常、システムプロキシより安定しますが、ポートを変更した後は更新が必要です。

Git

git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890
git config --global --get-regexp "http.*proxy"

グローバルプロキシを解除するには次を実行します。

git config --global --unset http.proxy
git config --global --unset https.proxy

リポジトリ単位の設定に別のプロキシがある場合は、リポジトリ内でgit config --local --get-regexp "http.*proxy"を実行します。ローカル設定はグローバル設定より優先されるため、特定のリポジトリだけ接続に失敗する原因になります。

npm

npm config set proxy http://127.0.0.1:7890
npm config set https-proxy http://127.0.0.1:7890
npm config get proxy
npm config get https-proxy

設定を削除する場合は次を使います。

npm config delete proxy
npm config delete https-proxy

永続設定より単発のコマンドを優先する

切り分け中は、まずcurlの--proxy、プログラムのコマンド引数、または現在のセッションの環境変数を使うことをおすすめします。経路が安定していることを確認してから、~/.zshrc、~/.bashrc、またはツール設定へ書き込むか判断してください。こうすれば、クライアントがポートを変更した後も起動スクリプトが古い値を注入し続ける事態を防げます。

ルール、プロキシモード、見かけ上の接続成功

リクエストがClashのログに入ったら、次はルール判定を確認します。Ruleモードでは、ドメイン、IP、GeoSite、GeoIP、フォールバックルールを上から順に照合します。ドメインがDIRECTに判定されると、選択したプロキシノードを経由せず直接接続します。特定サイトを切り分けるときは、ログで判定されたプロキシグループを確認し、設定ファイルのルール順を調べてください。

Globalモードは通常、リクエストをグローバルプロキシグループへ渡すため、ルールが原因かどうかを短時間で判断するのに適しています。Ruleモードでは失敗し、Globalモードでは成功するなら、ローカルポートとノードはおおむね利用可能です。ルール設定に戻って対応し、Globalモードを常用するのは避けてください。Directモードはリクエストを直接接続するため、プロキシノードの検証には使えません。

遅延テストの成功は対象リクエストの成功を意味しない

  • 遅延テストはクライアントにあらかじめ設定されたテスト用アドレスにアクセスするだけで、すべてのドメインにアクセスできることを示すものではありません。
  • ノードの遅延が数十ミリ秒と表示されても、その時点のテストリクエストが完了したことを示すだけで、ブラウザがそのノードを使っているとは限りません。
  • プロキシグループが「自動選択」になっていても、実際のリクエストは別のプロキシグループに判定されることがあります。
  • 既存のブラウザ接続は古い経路を再利用することがあります。ノードを切り替えた後は、ページを更新するかアプリを再起動してから再テストしてください。
  • UDP、IPv6、通常のTCPリクエストは異なる経路で処理されることがあるため、1種類のテストだけで全トラフィックを判断しないでください。

TUNモードを検討するタイミング

システムプロキシが主にカバーするのは、HTTP、HTTPS、SOCKSのプロキシ設定を自ら読み取るプログラムです。一部のデスクトップアプリ、ゲームランチャー、システムコンポーネント、独自のネットワークスタックを実装したソフトウェアは、システムプロキシを無視します。mihomoのTUNモードは仮想ネットワークインターフェースを通じて、より広い範囲のIPトラフィックを取得できます。こうしたアプリへの対応に適していますが、ポート入力ミスの代わりに使うものではありません。

TUNを有効にする前に、通常のプロキシテストで設定、ノード、ルールが利用できることを確認します。その後、クライアントの「設定」→「TUNモード」で機能を有効にします。Windowsではクライアントによるネットワークコンポーネントのインストールまたは有効化を許可する必要があり、macOSではネットワーク拡張機能の権限確認を求められることがあります。有効化したらログを再確認し、これまで記録されなかったアプリのリクエストが表示されるか確認してください。

決まった順序で最終確認を行う

  1. 現在の設定が有効で、プロキシグループに利用可能なノードが選択され、Clashまたはmihomoのコアが実行中であることを確認します。
  2. 「設定」→「ポート設定」で実際のポートを確認し、経験だけで7890だと決めつけないでください。
  3. Test-NetConnection、lsof、ncを使って、ポートが待ち受け中であることを確認します。
  4. OSのプロキシアドレスが127.0.0.1で、ポートがクライアントと一致しているか確認します。
  5. ブラウザのプロキシ拡張機能の影響を取り除き、Firefox独自の設定とシステムのバイパスリストを確認します。
  6. curlの--proxyオプションで明示的なテストを行い、同時にClashのログを確認します。
  7. ブラウザは使えるのにターミナルが失敗する場合は、現在のセッションにHTTP_PROXY、HTTPS_PROXY、ALL_PROXYを設定します。
  8. Gitやnpmなど特定のツールだけが失敗する場合は、そのツール専用のプロキシ設定を確認します。
  9. リクエストがログに入った後で失敗する場合は、Rule、Global、Directモードと、実際に判定されたプロキシグループを確認します。
  10. アプリがシステムプロキシを完全に無視し、通常のプロキシ経路を検証できた後で、TUNモードを有効にします。

有効な切り分けでは、ブラウザがログを生成するか、明示的なcurlが成功するか、通常のcurlが環境変数を読み取るか、対象ドメインがどのルールに判定されたかという比較結果を常に残します。問題を「アプリからローカルポート」「Clashのルール処理」「ノードから対象アドレス」の3段階に分ければ、システムプロキシを有効にしても反映されない原因を明確な箇所まで絞り込めます。

Clashダウンロード