システムプロキシが効かないときの対処法：ブラウザはプロキシ経由なのに、ターミナルが接続できない理由

システムプロキシ・アプリ内プロキシ・TUNの違いを理解する

Clash Nyanpasuで「システムプロキシ」を有効にすると、クライアントが端末のプロキシアドレスをOSの設定へ書き込みます。一般的な構成では、プロキシサーバーは 127.0.0.1、混合ポートは 7890 です。ブラウザがこの設定を読み取ると、HTTPリクエストやCONNECTで確立したHTTPS接続がClashへ渡されます。Clashは現在の設定にあるルール、プロキシグループ、ノードに従って通信を処理します。

重要なのは、システムプロキシがアプリのための設定であり、OSがすべてのネットワークパケットを強制的に転送する仕組みではない点です。Chrome、Edge、Safariなどのデスクトップブラウザは通常システムプロキシに従いますが、多くのコマンドラインプログラム、ゲームランチャー、開発ツール、独自のネットワーク処理を持つアプリは、プロキシ設定を読み取るかどうかを自分で決めます。そのため「ブラウザはアクセスできるのに、ターミナルは直接接続する」という状態は矛盾しません。多くの場合、プロキシコアとノードは動作しており、問題はターミナルがプロキシ情報を取得する方法にあります。

通信の取り込み方法	適用範囲	主な設定場所	適した用途
システムプロキシ	OSのプロキシ設定を読み取るアプリ	Clash Nyanpasu「設定」→「システムプロキシ」	ブラウザと一般的なデスクトップアプリ
アプリ内プロキシ	指定したアプリ自身	アプリのネットワーク設定または起動オプション	Git、ブラウザ拡張機能、開発ツール
環境変数	現在のターミナルと、そこから起動したプロセス	HTTP_PROXY、HTTPS_PROXY、ALL_PROXY	curl、パッケージマネージャー、コマンドラインツール
TUNモード	仮想ネットワークインターフェースを通過する幅広い通信	Clash Nyanpasu「設定」→「TUNモード」	プロキシ設定を読み取らないアプリとUDP通信

手順1：Clashコアとローカルポートが正常か確認する

いきなりOSのネットワーク設定を変更するのは避けてください。まずClash Nyanpasuで設定が有効になっているか、プロキシコアが実行中かを確認し、現在のモードが「ルール」「グローバル」「ダイレクト」のどれかを確認します。ルールモードでは、対象によってはルールにより直接接続されるため、これは想定された動作です。テスト対象のドメインが DIRECT に一致している場合、リクエストがClashに入っていても、プロキシノードの出口にはなりません。

混合ポートとリッスンアドレスを確認する

「設定」→「Clash設定」、または使用中のバージョンに対応するポート設定画面を開き、mixed-port を確認します。一般的な値は 7890 ですが、設定のインポート、ポートの競合、手動変更によって実際の値が 7891、7897 などになることもあります。以降のコマンドでは、画面に表示されたポートを使用してください。

通常、リッスンアドレスにはループバックアドレス 127.0.0.1 を使用します。コマンドを同じ端末上で実行するなら、LANアクセスを有効にする必要はなく、プロキシアドレスに端末のWi-Fi IPを指定するべきでもありません。コンテナ、仮想マシン、同じLAN内の別端末からアクセスする場合に限り、allow-lan、ファイアウォール、リッスンアドレスを組み合わせて設定します。

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

まずシステムプロキシ設定を迂回し、ClashのHTTPプロキシを明示してリクエストを送ります。

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

HTTP/2 200、HTTP/1.1 200 OK、または対象サイトによる正常なリダイレクトが返れば、ローカルポートへ接続でき、HTTPSトンネルも確立できています。Failed to connect や Connection refused と表示される場合は、まずポート、コアの実行状態、ローカルファイアウォールを確認します。接続確立後にタイムアウトする場合は、Clashのログでルールの一致、ノードエラー、DNSの結果を確認してください。

SOCKS5入口を指定してテストすることもできます。混合ポートは通常HTTPとSOCKS5の両方を受け付けますが、現在の設定を優先してください。

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

socks5h の h は、プロキシ側で対象ドメインを解決することを示します。ローカルDNSの問題とプロキシ経路の問題を切り分けるのに適しています。HTTPプロキシのテストは成功するのに直接リクエストが失敗する場合、原因をOS設定またはアプリ設定にほぼ絞り込めます。

ブラウザが使える場合は、拡張機能とプロキシの上書きを確認する

ブラウザで正常にアクセスできても、「ブラウザが現在使っているどこかのプロキシ経路が利用可能」と分かるだけで、システムプロキシ設定が正しいとは限りません。ChromeとEdgeは通常システムプロキシを読み取りますが、プロキシ拡張機能、企業ポリシー、起動オプション、ブラウザ内蔵のセキュアDNSによって実際の動作が変わることがあります。Firefoxには独自の接続設定があり、システムプロキシ、手動プロキシ、直接接続を選択できます。

ブラウザ拡張機能の独自プロキシ設定を除外する

プロキシ切り替えを担当するブラウザ拡張機能を一時的に無効にします。
ブラウザを完全に終了してから再起動し、バックグラウンドプロセスが古い接続を使い続けないようにします。
Clash Nyanpasuのシステムプロキシだけを有効にして、テストページへ再度アクセスします。
Clashの接続履歴で対象ドメインが表示されることを確認し、適用されたルールを確認します。

拡張機能を無効にした直後にアクセスできなくなった場合、以前は拡張機能が 127.0.0.1:7890 へ直接接続しており、システムプロキシが有効だったわけではありません。この場合は、OSのプロキシアドレスが古いポートを指していないか、別のプロキシソフトがシステムプロキシの設定を上書きしていないかを確認します。

Firefoxの接続設定を確認する

Firefoxでは「設定」→「一般」→「ネットワーク設定」→「接続設定」と進みます。「システムのプロキシ設定を使用」を選ぶとOSに従います。「手動でプロキシを設定する」を選んだ場合は、HTTPプロキシとHTTPSプロキシに 127.0.0.1 と実際の混合ポートを入力します。SOCKSを使う場合はSOCKS v5を選び、必要に応じてSOCKS経由のDNS解決を有効にします。

セキュアDNSによる違いを確認する

ブラウザのDNS over HTTPSにより、ドメイン解決の経路がターミナルと異なることがあります。ターミナルは通常システムDNSを使いますが、ブラウザは独自の暗号化DNSサービスへ問い合わせる場合があります。ブラウザにはアクセスできるのに、ターミナルで「ホストを解決できません」と表示される場合は、まず nslookup または dig でシステム側の名前解決を確認し、前述の socks5h リクエストでプロキシ側の名前解決をテストします。原因はプロキシポートではなく、システムDNS、VPNの残存設定、ネットワークインターフェースの優先順位にある可能性もあります。

ターミナルがシステムプロキシに自動追従しない理由

コマンドラインツールはクロスプラットフォームで動作するため、デスクトップOSのプロキシAPIに依存しないことが多くあります。curl、Git、Python、Node.js、各種パッケージマネージャーのプロキシ変数への対応も完全には統一されていません。最も確実なのは、現在のターミナルセッションに環境変数を設定してから対象コマンドを起動する方法です。テスト後は変数を削除し、ポート変更後も古いアドレスへ接続し続ける事態を防ぎます。

Windows PowerShellで一時的に設定する

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

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

HTTPS_PROXY の値に http:// を指定するのは、一般的で正しい設定です。これはクライアントがHTTPプロキシ経由でCONNECTトンネルを確立し、そのトンネル内でHTTPS通信を行うことを意味します。変数名にHTTPSが含まれているからといって、ローカルのプロキシポートがTLSプロキシサービスを明示的に提供していない限り、プロトコルを https:// に変更しないでください。

これらのPowerShell変数が影響するのは、現在のウィンドウとそこから起動した子プロセスだけです。ウィンドウを閉じると設定は無効になります。削除するには次のように実行します。

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

Windows CMDで一時的に設定する

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

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

WindowsにはWinINETとWinHTTPという2種類のプロキシ機構もあります。ブラウザや多くのデスクトップアプリはシステム画面のプロキシ設定を読み取り、一部のシステムサービスはWinHTTPを使用します。netsh winhttp show proxy でWinHTTPの状態を確認できますが、通常のターミナル通信を直すために、いきなり全体設定をインポートしないでください。まず対象プログラムがどの設定を読み取るのかを確認します。

macOSとLinuxで現在のセッションに設定する

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"
export NO_PROXY="localhost,127.0.0.1,::1"

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

小文字の変数名しか読み取らないツールにも対応できるよう、小文字の変数も同時に設定します。

export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export all_proxy="$ALL_PROXY"
export no_proxy="$NO_PROXY"

現在のセッションから変数を削除するには、次のように実行します。

unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY
unset http_proxy https_proxy all_proxy no_proxy

~/.zshrc、~/.bashrc、その他のシェル設定ファイルへ書き込む場合は、ポートを固定するのではなく、プロキシの有効化・無効化用の関数を定義することをおすすめします。Clashを起動していないときに、ターミナルが存在しないローカルプロキシを待ち続けるのを防げます。設定ファイルを変更した後は、ターミナルを開き直すか、適切な source コマンドを実行してください。

Git、パッケージマネージャー、開発ツールは個別に確認する

環境変数を正しく設定しても、独自設定で上書きされるツールがあります。切り分けでは「システム設定、環境変数、アプリ設定」の3階層を確認し、設定の優先順位にも注意してください。よくあるのは、Gitに古いポートが保存されている、またはnpmの設定が停止済みのプロキシアドレスを指しているケースです。

Gitのプロキシ設定

Gitが現在読み取っているプロキシの設定元を確認します。

git config --show-origin --get-regexp "http\..*proxy|https\..*proxy"

現在のユーザーにプロキシを設定する場合は、次のコマンドを実行します。

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

今後、環境変数またはTUNモードを使う場合は、この2項目を削除してください。固定設定が新しい経路を上書きするのを防げます。

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

npmとpnpmに残ったプロキシ設定

npm config get proxy
npm config get https-proxy
pnpm config get proxy
pnpm config get https-proxy

出力に古いアドレスが表示される場合は、現在のポートへ更新するか、該当設定を削除します。パッケージマネージャーは、ミラー、証明書チェーン、DNS、リポジトリの稼働状況にも影響されます。そのため「ダウンロードに失敗した」からといって、プロキシの有効・無効だけを確認するのは不十分です。まずcurlで同じリポジトリのドメインへリクエストし、次にコマンドの詳細ログを確認して、TCP接続失敗、名前解決失敗、TLSエラー、サーバー側のレート制限を区別します。

コンテナと仮想マシン内での127.0.0.1

Dockerコンテナ、WSL、仮想マシン内の 127.0.0.1 は通常、それぞれ自身のネットワーク環境を指し、ホストOSを指すとは限りません。ホスト上のClashアドレスをそのまま入力すると、接続拒否になることがよくあります。その場合は、仮想ネットワーク上でのホストOSのアドレスを使用し、必要に応じてClashでLANアクセスを有効にし、OSのファイアウォールも設定します。公開ネットワークへ直接露出させず、信頼できるネットワークに範囲を限定してください。

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

対象アプリがHTTPまたはSOCKSプロキシに対応せず、環境変数も読み取らない場合、システムプロキシではカバーしにくくなります。ゲームランチャーの一部、UDPを使うプログラム、直接接続に固定されたデスクトップアプリ、複数の開発ツールを同時に制御したい環境などが典型例です。この場合はTUNモードを検討できます。通信をまず仮想ネットワークインターフェースへ通し、その後mihomoコアに渡してルールに従って処理します。

TUNモードが解決するのは通信の取り込み範囲

TUNはノードの品質を自動的に高める機能ではなく、サブスクリプション内の誤ったサーバーパラメータを修正するものでもありません。主に、通信がClashへ入る方法を変えます。有効にすると、これまでシステムプロキシを迂回していたTCPまたはUDP通信も一括して取り込める可能性がありますが、ルールモード、プロキシグループ、ノード選択は現在の設定に従います。

Clash Nyanpasuでは、「設定」→「TUNモード」から関連機能を有効にできます。Windowsで初めて有効にする際は、仮想ネットワークインターフェースの作成に管理者権限が必要になることがあります。macOSではネットワーク拡張機能やシステム権限の確認が表示される場合があります。Linuxでは通常、適切なネットワーク管理権限が必要です。クライアントのバージョンによってメニュー名は多少異なりますが、TUNスイッチ、ネットワークインターフェースの状態、コアログを基準に判断してください。

有効化前後に確認する順序

他のVPN、アクセラレーター、同種のTUNプログラムを終了し、複数のソフトが同時にルーティングテーブルを変更しないようにします。
現在のシステムプロキシ、混合ポート、DNS設定を記録しておき、元に戻せるようにします。
TUNを有効にした後、仮想インターフェースが正常に作成されたか確認し、コアログに権限エラーがないか確認します。
まずブラウザとcurlをテストし、その後、これまで取り込めなかったアプリをテストします。
LAN上のアドレス、プリンター、開発サーバーへ引き続きアクセスできるか確認し、必要に応じてダイレクト接続ルールを設定します。

一部のクライアントではTUNとシステムプロキシを同時に有効にできますが、トラブルシューティング中は一度に1種類の取り込み方法だけを検証するのがおすすめです。同じリクエストが異なる入口を通ると、原因がシステムプロキシ、環境変数、仮想インターフェースのどれなのか判断しにくくなります。TUNの動作を確認した後、利用状況に応じてシステムプロキシを残すか決めてください。

DNS、ルール、ループバックアドレスで起きやすい誤判定

ターミナルでドメインの名前解決に失敗する

プロキシへ接続する前にエラーが発生し、たとえば Could not resolve host と表示される場合は、HTTPプロキシとSOCKSのどちらを使っているかを確認します。HTTP CONNECTリクエストでは通常、対象ホスト名がプロキシへ渡されます。一方、socks5:// はローカルで名前解決してから接続する場合があり、socks5h:// はプロキシ側での名前解決を明示します。2種類の書式で比較テストすれば、障害がシステムDNSにあるのか、プロキシ経路にあるのかをすばやく判断できます。

リクエストはClashに入っているのにDIRECTになる

ルールモードでは、ドメイン、IP、プロセス、ルールセットに基づいてポリシーを選択します。ログに DIRECT と表示されるなら、リクエストはすでに取り込まれていますが、ルールによって直接接続が選ばれたということです。現在の設定におけるルールの順序、対象ドメインが属するルールセット、最終的なフォールバックルールを確認してください。一時的にグローバルモードへ切り替えると比較できますが、テスト後は元のモードへ戻してください。本来直接接続すべきLANや中国国内のサービスまで、すべてプロキシノードへ送るのを防ぐためです。

localhostがプロキシ経由になりアクセスできない

開発サーバーでは localhost:3000、127.0.0.1:5173、その他のローカルポートをよく使います。環境変数を設定する際は NO_PROXY に localhost、127.0.0.1、::1 を指定し、一部のツールがローカルリクエストをプロキシへ送らないようにします。イントラネットのサービスへアクセスする場合は、ツールが対応する形式で社内ドメインやネットワーク範囲を追加することもできますが、ワイルドカードやCIDRへの対応はプログラムごとに異なります。

症状別に原因を絞り込むチェックリスト

ブラウザは正常、curlの直接接続は失敗： -x でプロキシを明示します。成功したら、ターミナルまたはツールに環境変数やプロキシを設定します。
ブラウザは正常、プロキシを指定したcurlも失敗： ブラウザが拡張機能の別ポートを使っている可能性があります。拡張機能の設定とClashの現在の混合ポートを確認します。
プロキシを指定したcurlは成功、環境変数では失敗： 変数名の綴り、大文字・小文字、現在のシェルの有効範囲、ツールが変数に対応しているかを確認します。
接続履歴に対象リクエストがない： リクエストはまだClashへ入っていません。アプリ設定、ローカルアドレス、コンテナのネットワーク、ポートの使用状況を確認します。
接続履歴はあるがルールがDIRECT： ルールの一致結果を確認し、直接接続をシステムプロキシの無効と誤解しないでください。
接続履歴があり、プロキシノードでエラー： プロキシグループ内の別ノードを試し、サブスクリプションの更新、ノードの可用性、ネットワーク接続を確認します。
ドメインだけ失敗し、IPには接続できる： システムDNS、ClashのDNS設定、SOCKSでのドメイン解決方式を重点的に確認します。
アプリがプロキシパラメータにまったく対応していない： TUNモードを検討し、仮想インターフェースの権限、ルーティングの競合、LANへのダイレクト接続ルールを確認します。

最も効率的な切り分け順は、まずローカルポートを確認し、次にプロキシを明示してテストし、その後にシステムプロキシまたは環境変数を確認し、最後にTUNを検討することです。ブラウザですでにアクセスできているなら、ノードやサブスクリプションを何度も変更する必要は通常ありません。ターミナルがプロキシを読み取っているか、ポートが一致しているか、DNSがどこで解決されているか、リクエストが本当にClashコアへ入っているかに注目してください。