ブラウザーはプロキシを通るのにターミナルは通らない？システムプロキシが効かない場合の切り分け

まず、どの層で問題が起きているかを切り分ける

Clash、Clash Meta（mihomo）、およびこれらのコアを使ったデスクトップクライアントは、通常ローカルで HTTP、SOCKS5、mixed のプロキシポートを待ち受けます。クライアントの「システムプロキシ」スイッチは、OSのプロキシアドレスを 127.0.0.1:7890 のようなローカルの待受アドレスに変更するだけです。アプリがこの設定を読み取るか、リクエストがコアに届くか、最終的にどのポリシーが選ばれるかは、それぞれ独立した3つの段階です。

したがって、「システムプロキシがオン」でも、すべてのプログラムが自動的にClashを経由するとは限りません。ChromeやEdgeなどのブラウザーは通常システムプロキシに従いますが、Firefoxは独自のプロキシ設定を使用できます。curl、Git、npm、Pythonのパッケージマネージャー、リモートターミナルは、環境変数や個別の設定ファイルを参照することが多いです。ゲーム、UDPを使うプログラム、一部のストアアプリは従来のHTTPシステムプロキシを迂回する場合があり、その場合はTUNモードによる取り込みが必要です。

4つの結果で問題の範囲をすばやく判断する

テスト結果	可能性の高い原因	優先して確認する項目
ブラウザーは使えるが、ターミナルは使えない	ターミナルがシステムプロキシを読み取っていない	環境変数、Git/npmの個別設定
ブラウザーもターミナルも使えない	ポート、コア、設定、またはノードの異常	待受ポート、実行ログ、プロキシグループ
プロキシを明示すると使えるが、システムプロキシでは使えない	システムプロキシの書き込みに失敗した、または上書きされた	OSの設定、ブラウザーのポリシー、拡張機能
Webページは使えるが、ゲームやUDPは使えない	システムプロキシの適用範囲が不足している	TUN、DNS、ルーティング、ファイアウォール

ステップ1：Clashの実際の待受ポートを確認する

クライアントによってデフォルトポートは完全には同じではありません。よくある設定は、HTTPまたはmixedポートが 7890、SOCKS5ポートが 7891、外部コントロールポートが 9090 です。9090 はコントロールパネルからAPIを呼び出すためのもので、Webプロキシ用のポートではありません。システムプロキシをここに向けると失敗します。最終的には、よくある番号を当てにせず、クライアントの現在の設定と設定ファイルを確認してください。

GUIクライアントでは、まず「設定」→「パラメーター設定」または「設定」→「ネットワーク設定」を開き、HTTP、SOCKS、Mixed Portを確認します。設定が mixed-port: 7890 のみの場合、HTTPとSOCKS5のどちらでも7890に接続できます。port と socks-port を個別に指定している場合は、使用するプロトコルに合うポートを指定してください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

ローカルHTTPプロキシを直接テストする

ターミナルでプロキシを明示的に指定すると、システムプロキシ設定を介さずにClashのポートが動作しているか確認できます。次のコマンドは標準のテストページにアクセスし、正常ならHTTPレスポンスヘッダーを返します。-v を追加すれば、127.0.0.1:7890 に接続しているかどうかも確認できます。

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

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

プロキシを明示すると成功し、-x なしのコマンドだけ失敗する場合、コア、ノード、ポートはおおむね正常で、問題はシステムプロキシまたはターミナル設定に絞られます。明示的なプロキシでも Connection refused が発生するなら、ポートの指定ミス、コアの未起動、またはセキュリティソフトによるローカル待受のブロックが考えられます。ローカルポートには接続できるものの、その後に timeout が出る場合は、ノード、ルール、DNSを確認してください。

ポートが待ち受け中か確認する

# Windows
netstat -ano | findstr :7890

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -lntp | grep 7890

出力にはローカルの待受アドレスが表示されるはずです。自分のPCだけで使う場合、127.0.0.1:7890 で待ち受けるのは正常です。LAN内の他の端末から接続する必要がある場合に限り、allow-lan を有効にしてファイアウォールを確認してください。ローカルのブラウザーの問題を直すためだけに、安易にLAN向け待受を開放しないでください。

ブラウザーがプロキシを通らない：上書き設定とプロキシの参照元を確認する

WindowsやmacOSのChromeとEdgeは通常システムプロキシを読み取りますが、拡張機能、企業ポリシー、起動パラメーター、セキュリティソフトによって上書きされることがあります。Firefoxには独立したネットワーク設定があり、「プロキシなし」「システムのプロキシ設定を使用」「手動でプロキシを設定」から選べます。ブラウザーによって結果が異なる場合は、こうした設定の参照元が違うことが原因であるケースが多いです。

ChromeとEdgeの確認手順

ブラウザーを完全に終了してから再起動し、古い接続プールで直接接続が再利用されるのを防ぎます。
ブラウザーの「設定」→「システムとパフォーマンス」→「パソコンのプロキシ設定を開く」に進み、アドレスが 127.0.0.1、ポートがClashの設定と一致していることを確認します。
プロキシを管理する拡張機能を一時的に無効にします。特に、PACの切り替え、固定プロキシ、プロファイル切り替えに対応した拡張機能を確認してください。
ショートカットや起動スクリプトに --proxy-server、--no-proxy-server などのパラメーターがないか確認します。
Clashの接続一覧またはリアルタイムログを開いた状態でWebページを再読み込みし、対象ドメインが表示されるか確認します。

ブラウザーのログに新しい接続がまったく表示されない場合、リクエストはまだClashに届いていません。システムプロキシまたはブラウザーの上書き設定を確認してください。接続が表示され、ポリシーが DIRECT なら、システムプロキシは機能していますが、現在のルールによってそのドメインが直接接続になっています。この場合は、システムプロキシを何度も切り替えるのではなく、ルールの判定結果を確認します。

Firefoxは独自のプロキシ設定を使用する

Firefoxで「設定」→「一般」→「ネットワーク設定」→「設定」を開きます。Clashのシステムプロキシに従わせる場合は「システムのプロキシ設定を使用」を選択します。「手動でプロキシを設定」を選ぶ場合は、HTTPプロキシを 127.0.0.1、ポートを 7890 にし、SOCKSホストは実際のポートに合わせて入力します。SOCKS5を使用し、ドメイン名の解決もプロキシ側で行いたい場合は、「SOCKS v5使用時にDNSもプロキシを通す」も確認してください。

ターミナルがプロキシを通らない：システムプロキシだけでなく環境変数を設定する

macOSとLinuxのターミナルプログラムは、デスクトップのシステムプロキシを一律に引き継ぐわけではありません。Windowsでも、PowerShellのコマンド、curl.exe、WSL、各種開発ツールを分けて考える必要があります。最も確実な確認方法は、まず現在のターミナルセッションにプロキシ環境変数を設定してからリクエストを実行することです。

macOSとLinux：現在のセッション

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export all_proxy=socks5h://127.0.0.1:7890
export no_proxy=localhost,127.0.0.1,::1

curl -I https://example.com/

https_proxy の値に http:// を使っても矛盾しません。これはローカルHTTPプロキシを介し、CONNECTトンネルでHTTPSサイトへアクセスすることを示します。socks5h の h は、ドメイン名の解決をSOCKSプロキシ側に任せる意味で、ローカルDNSとプロキシ出口の不一致を減らせます。

1つのコマンドだけに適用したい場合は、コマンドの前に変数を記述します。結果を確認してから、~/.zshrc、~/.bashrc、プロジェクトのスクリプトに追加するか判断してください。起動ファイルに常時書き込むと、Clashが起動していないときもターミナルがローカルポートへ接続しようとするため、解除用のコマンドも用意しておくと安心です。

https_proxy=http://127.0.0.1:7890 curl -I https://example.com/

unset http_proxy
unset https_proxy
unset all_proxy

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"

curl.exe -I https://example.com/

旧版Windows PowerShellでは、curl が Invoke-WebRequest のエイリアスになっている場合があり、標準curlとはパラメーターの動作が異なります。切り分けでは curl.exe を明示的に実行し、curl.exe --version で実際のプログラムを確認してください。現在のPowerShellウィンドウを閉じると、上記の環境変数は無効になります。

WSLでは接続可能なWindowsホストのアドレスを使う

WSL2は独立した仮想ネットワーク上で動作するため、WSL内の 127.0.0.1 がWindows上のClashの待受アドレスを指すとは限りません。まずクライアントでLAN接続を許可し、WSLからデフォルトゲートウェイを確認して、そのアドレスをプロキシホストに指定します。WSLのネットワークモードによって挙動は異なるため、特定のプライベートIPをそのまま使わないでください。

ip route | awk '/default/ {print $3}'

export https_proxy=http://Windowsホストのアドレス:7890
curl -I https://example.com/

WSLからWindowsホストには接続できるのにポートが拒否される場合は、Clashが 127.0.0.1 のみで待ち受けていないか、LANアクセスが有効か、Windowsファイアウォールが該当するプライベートネットワークを許可しているか確認します。テスト後はローカルのみの待受に戻し、不要なLAN公開を避けてください。

Git、npm、開発ツールは個別に確認する

環境変数が有効でも、一部のツールが独自設定を優先して読み取ることがあります。逆に、システムプロキシをオフにしてもGitやnpmに保存された古いプロキシが7890を指し続け、Clash終了後にすべてのリクエストが失敗する場合もあります。切り分けでは「設定がない」ケースだけでなく、「古い設定が残っている」ケースも確認してください。

Gitのプロキシを確認・設定・解除する

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

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 --unset http.proxy
git config --global --unset https.proxy

さらに git config --show-origin --get-regexp proxy を実行して、設定元を確認します。プロジェクトの .git/config、ユーザー設定、システム設定が同時に存在する場合があり、優先度の高いプロジェクト設定がグローバル設定を上書きします。SSH形式のリモートアドレスはGitのHTTPプロキシを参照しません。SSHの ProxyCommand を設定するか、HTTPSアドレスに変更してテストしてください。

npmとその他のパッケージマネージャー

npm config get proxy
npm config get https-proxy

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

npm config delete proxy
npm config delete https-proxy

pnpm、Yarn、pip、Maven、Dockerは環境変数を読み取る場合もあれば、それぞれ独自の設定を持つ場合もあります。ブラウザーは正常なのに依存関係のインストールがタイムアウトするなら、まず詳細ログを確認し、対象ドメイン、ミラーアドレス、古いプロキシポートのどれに接続しているかを特定します。コンテナ内の 127.0.0.1 はコンテナ自身を指すため、ホスト上のClashを直接意味するわけではありません。

リクエストがClashに届いても失敗する：ルール、DNS、ノードを確認する

リアルタイムログに対象ドメインが表示されているなら、システムプロキシの段階はすでに完了しています。その後の失敗はログに沿って分けて確認します。ルールが想定したプロキシグループに一致しているか、グループが利用可能なノードを選んでいるか、DNSが正しいアドレスを返しているか、リモート接続がタイムアウトしていないかを確認してください。すべての失敗を「プロキシが効かない」とまとめると、誤った箇所で操作を繰り返すことになります。

ログの項目から原因の方向を判断する

DIRECT：リクエストがコアに届いた後、ルールによって直接接続と判定されています。ルールの順序、ルールセットの更新、現在のモードを確認してください。
REJECT：拒否ルールに一致しています。ドメインが広告・プライバシー用ルールセットによってブロックされていないか確認してください。
dial tcp timeout：ローカルポートはリクエストを受け付けていますが、接続先またはノードへの接続がタイムアウトしています。ノードの遅延、出口側のネットワーク、ファイアウォールを確認してください。
connection refused：接続先が明示的に接続を拒否しています。ノード側サービスのポート、接続先サービス、またはローカルポートが正しくない可能性があります。
dns resolve failed：名前解決の段階で失敗しています。DNSサーバー、Fake IP設定、DoHへの到達性、ルールを確認してください。

切り分け中は、クライアントのモードを一時的にグローバルプロキシへ切り替え、動作確認済みのノードを1つ選んで比較できます。グローバルモードでは使えるのにルールモードでは使えない場合は、ルールの判定を重点的に確認します。両方のモードで失敗する場合は、ノード、サブスクリプション設定、ネットワーク接続を確認してください。テスト後はルールモードに戻し、グローバルモードを恒久的な解決策にしないようにします。

TUNモードに切り替えるべきタイミング

システムプロキシは、主にHTTPまたはSOCKSプロキシを明示的にサポートするアプリ向けです。ゲームランチャー、一部のデスクトップソフト、UDP通信、常に直接接続するプログラムは、システムプロキシをまったく読み取らないことがあります。その場合、ブラウザーが正常でも対象アプリは直接接続します。TUNモードは仮想ネットワークインターフェースを使ってネットワーク層で通信を取り込み、通常はより広い範囲をカバーしますが、管理者権限が必要で、DNS、ルーティング、除外ルールの設定も増えます。

アプリにプロキシ設定がない、システムプロキシを継続的に迂回する、UDPを扱う、複数のCLIツールにClashのルールを一括適用したい、といった場合はTUNを優先的に試す価値があります。ブラウザーと少数の開発ツールだけなら、システムプロキシと環境変数を組み合わせるほうが構成が明確で、アプリ単位の制御もしやすいです。

TUNを有効にする前に4項目を確認する

現在のクライアントがTUNをサポートするmihomoコアを使用し、仮想ネットワークインターフェースの作成に必要な権限を付与されていることを確認します。
現在のDNS設定を記録し、システムDNS、ブラウザーのDoH、ClashのDNSが重なって原因を追いにくくならないようにします。
LAN内のアドレス、プリンター、開発サーバー、本機のサービスを必要な直接接続ルールに追加します。
他のVPNや仮想ネットワークインターフェースツールを終了して単一要因でテストし、デフォルトルートやDNSが互いに上書きしないようにします。

TUNを有効にした直後にすべてのネットワークが切断された場合は、まずTUNを無効にして接続を復旧し、その後コアのログと仮想ネットワークインターフェースの状態を確認します。サブスクリプション、DNS、ルール、システムファイアウォールを同時に変更しないでください。一度に1項目だけ変更し、変更前後の結果を残すことで、実際の原因を特定できます。

順番に進めて完全に切り分ける

Clashのコアが動作し、現在の設定が正常に読み込まれ、プロキシグループで接続可能なノードが選択されていることを確認します。
「設定」→「パラメーター設定」でmixed、HTTP、SOCKS5のポートを確認し、コントロールポート9090をプロキシポートと取り違えないようにします。
curl -x で 127.0.0.1:7890 を明示的に指定し、ローカルプロキシポートが使用できるか判断します。
OSのプロキシアドレスとポートを確認し、続けてブラウザー拡張機能、Firefoxの独立したプロキシ設定、起動パラメーターを確認します。
ターミナルの現在のセッションに http_proxy、https_proxy、all_proxy を設定し、同じリクエストを再実行します。
Gitやnpmなどのツールに保存された個別のプロキシ設定を確認し、すでに使われていない古いポートを削除します。
Clashのリアルタイムログを確認します。接続記録がなければアプリ側を再確認し、記録があればルール、DNS、ノードをさらに確認します。
対象プログラムが実際にシステムプロキシを迂回していることを確認してから、TUNモードを有効にするか検討します。

ブラウザーはプロキシを通るのにターミナルは通らない場合、最も多い原因はClashのコア障害ではなく、アプリによってプロキシの読み取り方法が異なることです。まずプロキシを明示するコマンドでポートを検証し、ブラウザーの上書き設定とターミナルの環境変数を個別に確認すれば、問題の範囲をすばやく絞り込めます。リクエストがコアに届いてから初めて、ルール、DNS、ノード、TUNを次の確認対象にします。