Clashのシステムプロキシが効かないときの対処法｜ブラウザーとターミナルを個別に確認

システムプロキシ・アプリ別プロキシ・TUNの違いを確認

Clashクライアントの「システムプロキシ」スイッチは、通常、OSのプロキシ設定にローカルプロキシのアドレスを書き込むものです。すべての通信を強制的に経由させる機能ではありません。ブラウザー、コマンドラインツール、バックグラウンドサービスはそれぞれ異なる設定を参照することがあるため、「Webページは開けるのにターミナルはタイムアウトする」という状況は起こり得ます。

まず確認するのは、リクエストがClashのコアに届いているか、届いている場合はどのルールに一致したかの2点です。前者はプロキシへの接続経路、後者はサブスクリプションのノード、プロキシグループ、ルーティング設定に関する問題です。出口IPが変わらないからといって、すぐにシステムプロキシの故障と判断しないでください。

手順1：ローカルプロキシの接続先を確認

外部コントロールポートではなく、混合ポートを確認

クライアントの設定画面または設定ファイルの確認画面で mixed-port を探します。混合ポートはHTTPとSOCKSの両方のプロキシリクエストを受け付けます。一方、external-controller は管理APIの待ち受けアドレスであり、Web閲覧用のプロキシには使えません。よく例に挙げられる 9090 はコントロールポートです。待ち受け中だからといって、ブラウザーのプロキシ欄に入力しないでください。

mixed-port: 7890
external-controller: 127.0.0.1:9090

まずコアが起動していて、サブスクリプションの設定が選択されていることを確認し、プロキシを明示したコマンドでテストします。WindowsのPowerShellでは curl.exe を使ってください。旧バージョンのWindows PowerShellでは、curl が別のコマンドとして解釈されることがあります。

# Windows PowerShell
curl.exe -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/ -o NUL

# macOS / Linux
curl -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/ -o /dev/null

--noproxy "" は今回のリクエストでプロキシの除外リストを空にし、既存の NO_PROXY 設定の影響を避けるための指定です。ここでの10秒は接続タイムアウト、20秒はリクエスト全体のタイムアウトの上限であり、ノードの遅延を測る目安ではありません。テスト先は問題が起きているWebサイトに変更してもかまいませんが、ログを公開する場合はログイン用トークンを含む完全なURLを残さないでください。

• 127.0.0.1:7890 への接続が拒否された場合は、コアが起動しているか、ポート番号が正しいか、別のプロセスがそのポートを使用していないかを確認します。
• HTTPプロキシトンネルで 200 Connection established が表示された場合、ローカルプロキシはCONNECTリクエストを受け付けています。続いてTLSとHTTPの結果を確認してください。
• ローカル接続は成功した後にタイムアウトする、またはTLSエラーになる場合は、ノードへの接続、接続先サイト、DNS、証明書を確認します。システムプロキシのスイッチだけを調べ続ける必要はありません。

クライアントの「接続」または「ログ」画面も開き、新しいリクエストを送信します。ログレベルは一時的に info に設定し、必要な場合のみ debug を使って、確認後は元に戻します。プロキシを明示したコマンドは成功するのにブラウザーだけ失敗する場合は、通常、ブラウザー側の接続設定に原因があります。

手順2：システムプロキシの設定反映先を確認

Windows 11：手動プロキシとスクリプト設定を確認

「設定」→「ネットワークとインターネット」→「プロキシ」を開き、「手動プロキシ セットアップ」の「プロキシ サーバーを使う」を確認します。この記事の例を使う場合、アドレスは 127.0.0.1、ポートは 7890 です。クライアントでシステムプロキシを有効にしたら、この画面に戻り、実際に値が変わったことを確認してください。クライアントのボタンの色だけで判断しないでください。

続いて、「セットアップ スクリプトを使う」が有効か、プロキシの例外リストに接続先のドメインが含まれていないかを確認します。自動構成スクリプト、組織のポリシー、別のネットワークツールによって、実際の動作が変わることがあります。管理対象のデバイスでは、設定を削除する前に管理者へ相談してください。

netsh winhttp show proxy で確認できるのはWinHTTPのプロキシ設定であり、この設定画面の状態すべてを示すものではありません。一部のサービスはWinHTTPを使いますが、ブラウザーはシステムのプロキシ設定や独自の設定を使う場合があります。表示を一致させるためだけに、全体へ設定をインポートするコマンドを実行しないでください。まず問題のプログラムがどのネットワークAPIを使っているか確認します。

macOS：現在接続中のネットワークサービスを確認

macOS 13以降では、「システム設定」→「ネットワーク」→現在使用中のWi-FiまたはEthernet→「詳細」→「プロキシ」を開きます。Webプロキシ（HTTP）、セキュアWebプロキシ（HTTPS）、自動プロキシ構成を確認してください。Wi-Fiから有線接続に切り替えた場合は、元のWi-Fiではなく、新しい接続に対応するサービスの設定を確認します。

HTTPSサイトへのアクセスにHTTPプロキシを使う場合、通常はCONNECTでトンネルを確立します。ローカルプロキシのアドレスを http://127.0.0.1:7890 と指定しても、Web通信のHTTPS暗号化が失われるわけではなく、ローカルアドレスを https:// に変える必要もありません。プロキシサーバー自体がTLSに対応しているかどうかは、別の機能です。

Linux：デスクトップの設定がすべてのプログラムに適用されるわけではない

GNOMEデスクトップでは、「設定」→「ネットワーク」→「ネットワークプロキシ」から手動または自動モードを確認できます。他のデスクトップ環境では、項目名や場所が異なる場合があります。デスクトップのプロキシ設定が影響するのは、その設定を参照するアプリだけです。すべてのシェル、コンテナ、systemdサービスに環境変数が自動で設定されるわけではありません。Linuxのターミナルで接続できない場合は、次のセクションで環境変数とプログラムの設定を確認してください。

手順3：ブラウザーの拡張機能・例外設定・既存接続を確認

まず同じブラウザーで新しいウィンドウを開き、同じテスト先にアクセスして、Clashの接続画面で新しいリクエストを確認します。既存のHTTP/2またはHTTP/3接続が再利用されることがあるため、スイッチを切り替えてページを再読み込みするだけでは、新しい接続経路が正しく反映されない場合があります。必要に応じてブラウザーを完全に終了し、再起動してください。

1. ChromeとEdge：ブラウザーの「設定」を開き、「プロキシ」を検索して、パソコンのプロキシ設定を開きます。デスクトップ版は通常、システムプロキシを使用しますが、プロキシ拡張機能、起動オプション、組織のポリシーによって設定が上書きされることがあります。
2. プロキシ拡張機能を確認：プロキシを管理する拡張機能を一時的に無効にするか、「システムプロキシ」に切り替えます。拡張機能の固定プロキシ、PACスクリプト、クライアントのシステムプロキシが互いに上書きし合わないようにしてください。
3. Firefox：「設定」→「一般」→「ネットワーク設定」→「設定」を開きます。「システムのプロキシ設定を使用する」を選ぶか、手動プロキシを設定してテストし、「プロキシーなし」を誤って選んでいないことを確認します。
4. プロキシの除外リストを確認：ブラウザーとシステムの「プロキシを使用しない」設定や例外項目を確認します。接続先のドメインが含まれていると、直接接続されることがあります。

Firefoxで手動設定する場合、HTTPプロキシに 127.0.0.1 と実際の混合ポートを入力し、画面の設定でHTTPSにも同じHTTPプロキシを使用します。SOCKS v5を使う場合は、「SOCKS v5を使用するときにDNSもプロキシする」の設定を確認してください。HTTPプロキシとSOCKSのDNS処理を混同しないようにします。

リクエストがClashに届いているのに DIRECT に一致する場合は、ルールモード、マッチしたルール、プロキシグループの選択を確認します。システムプロキシからリクエストが渡されたからといって、すべてのサイトがリモートノード経由で接続されるとは限りません。出口IPの確認で分かるのは、その確認リクエストの経路だけであり、ブラウザーのすべての接続を示すものではありません。

手順4：ターミナルの環境変数とツール固有の設定を確認

システムプロキシを有効にしても、ターミナルが自動でプロキシを使うとは限りません。まず前述のプロキシを明示したコマンドを実行します。成功するのに通常の curl リクエストが失敗する場合は、現在のシェルの環境変数を優先して確認してください。変数名の大文字・小文字の扱いはツールによって異なります。たとえばcurlはセキュリティ上の理由から、HTTPプロキシ変数として大文字の HTTP_PROXY を受け付けません。

PowerShell：現在のセッションだけに設定

# 設定済みのプロキシ変数を確認
Get-ChildItem Env: | Where-Object Name -Match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$'

# 現在のPowerShellと、そこから起動する子プロセスにプロキシを設定
$env:http_proxy = 'http://127.0.0.1:7890'
$env:https_proxy = 'http://127.0.0.1:7890'

# 新しいリクエストで確認
curl.exe -v --connect-timeout 10 --max-time 20 https://example.com/ -o NUL

これらの設定が変更するのは、現在のPowerShellプロセスと、その後に起動する子プロセスだけです。すでに開いているIDEや別のターミナル、システムサービスには反映されません。Windowsでは通常、環境変数名の大文字・小文字は区別されませんが、macOSとLinuxでは区別されることに注意してください。

macOS / Linux：現在のシェルを確認

# プロキシ関連の変数を確認
env | grep -iE '^(http_proxy|https_proxy|all_proxy|no_proxy)='

# 現在のシェルにHTTPプロキシを設定
export http_proxy='http://127.0.0.1:7890'
export https_proxy='http://127.0.0.1:7890'

# 新しいリクエストを送信
curl -v --connect-timeout 10 --max-time 20 https://example.com/ -o /dev/null

https_proxy の値に http:// を指定するのは通常の設定です。HTTPSの接続先へHTTPプロキシ経由でアクセスすることを意味します。NO_PROXY または no_proxy に接続先ドメインが含まれていると、プロキシを経由しない場合があります。値を * にすると、そのツールのすべてのリクエストが直接接続される可能性もあります。用途のあるローカルアドレスの例外は残し、今回の問題に関係する項目だけを変更してください。

環境変数が正しくても、プログラムがプロキシを使わない場合

すべてのコマンドラインプログラムがこれらの環境変数に対応しているわけではありません。たとえばGitでは、専用の設定と設定元を確認できます。

git config --show-origin --get-regexp '.*proxy.*'

出力に古いポートや別のマシンのプロキシが表示された場合は、設定ファイルと適用範囲を記録してから該当項目を変更します。プロジェクト設定、グローバル設定、URLごとの設定が同時に存在することがあります。一か所だけ変更して動作しないと判断しないでください。IDE内蔵ターミナルはIDE起動時の環境を引き継ぎます。システム環境変数を変更した場合は、IDEを完全に終了してから再起動する必要があります。

WSL、Dockerコンテナ、仮想マシン、SSHのリモートセッションには、それぞれ独立したネットワーク境界があります。内部の 127.0.0.1 は通常、その実行環境自身を指し、Clashが動作するホストを指すとは限りません。WSLの挙動はネットワークモードやシステム設定にも左右されます。まずホストへ接続できるアドレスと待ち受け範囲を確認してください。LANからの接続が必要な場合は、ファイアウォールで接続元を制限し、プロキシポートをインターネットに直接公開しないでください。

手順5：SOCKSとログでDNS・ルール・ノードの問題を切り分け

ローカルHTTPプロキシには接続できるのに特定のドメインだけ失敗する場合は、同じ混合ポートでSOCKSもテストできます。次のコマンドでは socks5h を指定し、curlが接続先ドメインをローカルで解決するのではなく、SOCKSプロキシ側に渡して解決します。

# Windows PowerShell
curl.exe -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy socks5h://127.0.0.1:7890 https://example.com/ -o NUL

# macOS / Linux
curl -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy socks5h://127.0.0.1:7890 https://example.com/ -o /dev/null

curlでは、socks5:// と socks5h:// でドメインを解決する場所が異なります。プロキシ側がドメインを受け取った後は、コアのDNS設定とルールに従って処理されるため、SOCKSテストに成功しても、パソコン全体のDNSが正常とは限りません。クライアントのログに記録された接続先ドメイン、一致したルール、プロキシチェーンとあわせて判断してください。

ブラウザーのセキュアDNSは名前解決の経路を変えることがありますが、HTTPプロキシを回避する機能ではありません。「セキュアDNSが有効だからシステムプロキシが効かない」とは判断しないでください。同じドメインで設定変更前後を比較し、実際の接続記録と照らし合わせて、名前解決方法を変更する必要があるか確認します。

手順6：プロキシ非対応アプリの通信を扱う場合にTUNを確認

TUNモードは仮想ネットワークインターフェースとルーティングを使って通信を受け取るため、システムプロキシを参照しないアプリにも対応できます。ただし、ポート設定の誤りを直す代わりにはなりません。まずプロキシを明示したコマンドが正常に動く状態にしてから、TUNを個別にテストしてください。プロキシの出口の問題と仮想ネットワークインターフェースの問題を切り分けやすくなります。

1. 使用中のクライアントとコアがTUNに対応しているか確認してください。mihomo対応クライアントと旧バージョンのClashクライアントでは、利用できる設定が異なる場合があります。ネット上で見つけた設定を、バージョンを問わずそのまま貼り付けないでください。
2. クライアントの説明に従ってサービスをインストールするか、必要な権限を付与してからTUNを有効にします。Windowsクライアントではサービスモードや管理者権限が必要な場合があります。macOSでは許可を求められることがあり、Linuxではネットワーク管理権限が必要になるのが一般的です。
3. 仮想ネットワークインターフェースの作成失敗、権限不足、ルート追加の失敗がログに記録されていないか確認します。画面上でスイッチがオンでも、必要な処理がすべて成功したとは限りません。
4. 切り分け中は通信を受け取る方法を一つだけにします。元の設定を記録してからシステムプロキシを無効にし、新しいリクエストがTUNで処理されるか確認します。テスト後は元の設定に戻してください。
5. 他のVPN、仮想ネットワークインターフェース、ネットワークフィルターツールも動作している場合は、一つずつ停止して比較します。ルートやネットワークインターフェースをいきなり削除しないでください。リモート接続を利用しているマシンでは、デフォルトルートを安易に変更しないでください。

mihomoでは、tun.enable、auto-route、auto-detect-interface、DNSの通信を取り込む関連設定がそれぞれ異なる役割を持ちます。クライアントが起動時に設定を生成または統合することがあるため、サブスクリプションの元ファイルを変更しても最終的な有効値に反映されるとは限りません。実行中の設定やクライアントの上書き設定を確認し、コアを再起動した後にログを確認してください。

TUNもルートの除外、プロセスごとのルール、DNS設定、他のネットワークコンポーネントの影響を受けます。「有効にすればすべての通信が必ずプロキシ経由になる」というわけではありません。リクエストがコアに届いた後、ルールによって直接接続と判定されれば、ローカル回線から接続される場合があります。

設定を元に戻し、順番に動作を確認

確認が終わったら、必要な接続方法だけを残します。一時的に変更した環境変数は元の値に戻してください。次のコマンドは、テスト前に対象の変数が設定されていなかった場合にのみ使用できます。もともと組織のプロキシや開発環境用のプロキシが設定されていた場合は、記録した値に戻し、単純に削除しないでください。

# PowerShell：今回一時的に追加した変数を削除
Remove-Item Env:http_proxy, Env:https_proxy -ErrorAction SilentlyContinue

# macOS / Linux：今回一時的に追加した変数を削除
unset http_proxy https_proxy

• まずローカル接続先を確認：実際の混合ポートを明示してリクエストを送り、コアに届くことを確認します。
• 次にブラウザーを確認：システムプロキシ、拡張機能、Firefox独自の設定、例外リストを確認します。
• ターミナルは個別に確認：現在のセッションの環境変数、プログラム設定、ホストとのネットワーク境界を確認します。
• 最後にルーティングを確認：ルールとプロキシチェーンを確認してから、DNS設定の変更やTUNの有効化を検討します。

問い合わせる際は、OSのバージョン、クライアントとコアのバージョン、実際のポート、プロキシを明示したコマンドの実行結果、同じ時間帯の関連ログを添えてください。共有前に、サブスクリプションURL、ノードの認証情報、APIキー、個人のアクセス履歴を削除します。「Clashのシステムプロキシが効かない」とだけ伝えるよりも、これらの情報があるほうが原因を絞り込めます。

初期設定についてはシステムプロキシの設定ガイドをご覧ください。リクエストがコアに届いていることを確認済みで、それでもタイムアウトする場合は接続タイムアウトの対処法を参照してください。設定を変更する前にバックアップを取り、一度に一つの項目だけを変更すると、原因を特定しやすくなります。