Clashのシステムプロキシが効かない？ブラウザー・ターミナルの確認ポイント

まずリクエストがClashに届いているか確認

システムプロキシのスイッチは、OSのプロキシ設定を変更しようとしたことを示すだけで、すべてのアプリがClash経由になるとは限りません。ブラウザーは拡張機能がプロキシを制御している場合があり、ターミナルでは通常、個別にプロキシを指定する必要があります。PACが対象ドメインを直接接続に振り分けている可能性もあります。リクエストがコアに届いていても、ルールによって DIRECT が選ばれることがあります。「プロキシが適用されていない」のか「適用後に直接接続されている」のかを切り分けると、ノードを何度も切り替えるより効率的です。

クライアントで現在の設定とローカルの待ち受けポートを確認します。この記事ではHTTPまたは混合プロキシの例として 127.0.0.1:7890 を使います。実際の設定に合わせてください。
クライアントのConnections（接続）画面を開き、新しいリクエストがあるかLogs（ログ）で確認します。必要に応じて、ログレベルを一時的に info に設定してください。
現在時刻を記録し、ブラウザーで確実にネットワークリクエストが発生するページを開いて、対象ドメイン、適用ルール、プロキシチェーンを確認します。
次に、後述するプロキシを明示したコマンドで同じ宛先にアクセスします。コマンドは成功してブラウザーだけ失敗する場合は、ブラウザーとシステムの設定を優先して確認し、すぐにサブスクリプションを変更しないでください。

確認できた状況	まず確認する項目	次に行うこと
プロキシを明示した接続が拒否される	コアが起動していない、ポートの指定ミス、または待ち受けなし	ローカルポートとプロセスを確認する
プロキシを明示すると成功するが、ブラウザーに接続記録がない	拡張機能、個別プロキシ設定、PAC、バイパスリスト	ブラウザーとシステムの設定を確認する
接続記録にDIRECTと表示される	現在のモードとルールの順序	適用ルールとポリシーグループを確認する
プロキシノードは選択されるが接続がタイムアウトする	ノード、リモートDNS解決、接続先サイトへの接続	具体的なエラーを確認し、システムプロキシのスイッチだけを原因と決めつけない

ローカルポートを確認：システムプロキシのアドレスはコアの待ち受けポートに合わせる

クライアント画面に表示されるコントローラーポートは、プロキシポートとは別です。設定項目 external-controller はControl API用で、ブラウザーのHTTPプロキシアドレスには指定できません。通常、port はHTTPプロキシ、socks-port はSOCKSプロキシを提供し、mixed-port はHTTPとSOCKSの両方を受け付けます。

たとえば 7890 や 7891 はよく使われる設定値ですが、固定の標準値ではありません。以下はポートの対応関係を示すためのYAMLの一部です。ノード、サブスクリプション、完全なルールは含まれていないため、このままでは通信できる完全な設定として使えません。

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

Windows：待ち受けとシステム設定を確認

PowerShellで次のコマンドを実行します。1つ目はポートが待ち受け状態かを確認するコマンドです。Windowsの現在のユーザーのプロキシ設定を確認するには、設定画面を手動で開きます。

Get-NetTCPConnection -State Listen -LocalPort 7890
Start-Process "ms-settings:network-proxy"

「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシのアドレスが 127.0.0.1 か、ポートがクライアントの設定と一致しているかを確認します。「セットアップスクリプトを使う」が有効かどうかも記録してください。1つ目のコマンドで何も表示されない場合は、まずクライアントのコアが動作しているか確認します。別のプロセスがそのポートを使用している場合は、プロセス名を確認してください。Clashだと決めつけないでください。

macOSとLinux：既定値を推測せず、まず待ち受けを確認

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

# Linux
ss -lntp 'sport = :7890'

macOSでは「システム設定」→「ネットワーク」→現在のネットワークサービス→「詳細」→「プロキシ」で、HTTP、HTTPS、自動プロキシ設定を確認します。Wi-FiとEthernetは別々のサービスです。ネットワークを切り替えた後は、もう一度確認してください。Linuxのデスクトッププロキシ設定はデスクトップ環境によって異なり、すべてのアプリがデスクトップのプロキシスイッチを参照するとは限りません。

ブラウザーの確認：拡張機能、個別設定、PACを分けて検証

ChromeとEdge：まず拡張機能による制御を確認

Chromeでは通常、「設定」→「システム」→「パソコンのプロキシ設定を開く」からシステムプロキシを確認できます。Edgeでは一般に「設定」→「システムとパフォーマンス」→「システム」にあります。バージョンによってメニュー名が多少異なる場合があります。設定ページで「プロキシ」と検索する方法もあります。

プロキシ切り替え拡張機能の現在のモードを確認します。別のポートが固定されていたり、一部のドメインが直接接続リストに登録されていたりすることがあります。
プロキシを変更する拡張機能をすべて一時的に無効にし、ブラウザーの全プロセスを終了してから再起動してテストします。シークレットウィンドウでも、拡張機能がすべて無効になるとは限りません。シークレットモードでの実行が許可された拡張機能は、そのまま動作する場合があります。
組織の管理下にあるデバイスでは、chrome://policy または edge://policy でプロキシポリシーを確認します。ポリシーによってロックされた設定は、デバイス管理者による変更が必要です。
ブラウザーの起動オプションに --no-proxy-server、--proxy-server、--proxy-pac-url が含まれていないか確認します。これらのオプションによって実際の動作が変わることがあります。

Firefox：別のプロキシ設定を使っていないか確認

「設定」→「一般」→「ネットワーク設定」→「設定」を開きます。「システムのプロキシ設定を使用する」を選んで再度テストします。「手動でプロキシを設定する」を使う場合は、HTTP、HTTPS、SOCKSのアドレスとポートを個別に確認してください。「プロキシーなし」の例外リストも確認します。特に、開発環境用に追加したドメインのサフィックスに注意してください。

PAC：ブラウザーがClashを経由するかを先に決める

PACスクリプトの FindProxyForURL は、URLとホスト名に基づいて経路を返します。DIRECT が返ると、リクエストはローカルHTTPプロキシを経由しません。PROXY 127.0.0.1:7890 が返れば、指定したポートにリクエストが送られます。PROXY 127.0.0.1:7890; DIRECT のように返された場合、プロキシに接続できないと直接接続にフォールバックすることがあります。実際の動作はアプリの実装によって異なります。

PACによる直接接続とClashルールによる直接接続は、発生する段階が異なります。PACはプロキシを使うかどうかを先に決め、Clashの rules はリクエストがコアに届いた後の接続先を決めます。対象を絞り込むには、自動設定スクリプトを一時的に無効にし、正しい手動HTTPプロキシだけを残してテストします。変更前の設定を記録し、テスト後に戻してください。組織から配布されたPACを業務用デバイスで無断で上書きしないでください。

ターミナルの確認：プロキシを明示して比較する

多くのコマンドラインツールはシステムプロキシを参照しません。ブラウザーでアクセスできても、curl が直接接続するからといって、Clashが動作していないとは限りません。まず環境変数による影響を避け、コマンドのオプションでローカルプロキシを明示します。

Windows PowerShellでのテスト

Windows PowerShell 5.1では curl が別のコマンドのエイリアスになっているため、curl.exe を使います。次のコマンドは例示用サイトにアクセスし、ローカルHTTPプロキシを必ず使うよう指定します。また、コマンドのバイパスリストで既存の NO_PROXY 設定を上書きします。

curl.exe -v --connect-timeout 10 --max-time 30 --proxy http://127.0.0.1:7890 --noproxy localhost https://example.com/ --output NUL

ここでの --noproxy localhost はlocalhostだけをプロキシの対象外にします。テスト先の example.com は対象外ではありません。これにより、古いPowerShellの一部バージョンで空文字列の引数を渡す際に起こりうる違いも避けられます。このドメインはリクエスト経路の説明用です。アクセスできるかどうかは、他のサイトが利用可能かを示すものではありません。

macOSとLinuxでのテスト

curl -v --connect-timeout 10 --max-time 30 \
  --proxy http://127.0.0.1:7890 --noproxy "" \
  https://example.com/ --output /dev/null

詳細出力でローカル接続先アドレスとHTTPSトンネルの確立を確認します。CONNECT example.com:443 が表示されれば、curlがHTTPプロキシにトンネルを要求しています。200 Connection established を受け取っても、その後のTLSやWebリクエストの成功が保証されるわけではありません。最終結果とクライアントの接続記録も確認してください。

Connection refused：まずローカルポートとコアの待ち受け状態を確認します。
トンネル確立後にTLSエラーが発生する場合は、システム時刻、証明書の信頼設定、HTTPS通信を検査する別のソフトウェアがないか確認します。証明書検証を無効にする方法で解決しようとしないでください。
クライアントにノード接続のタイムアウトが表示される場合、リクエストはプロキシチェーンに入っています。引き続きノードとリモート接続を確認してください。

環境変数とアプリの設定：変更が反映されるプロセスを確認

プロキシを明示したテストが成功したら、プロキシが必要なターミナルのプロセスに環境変数を設定します。curlではHTTPSの宛先に https_proxy を使えます。変数の値にある http:// は「クライアントからプロキシまで」のプロトコルを表すため、https:// に変更する必要はありません。対応する変数や優先順位はツールによって異なります。

まず現在の値を確認

# PowerShell：現在のプロセスのプロキシ関連環境変数を一覧表示
Get-ChildItem Env: | Where-Object Name -Match '^(http_proxy|https_proxy|all_proxy|no_proxy)$'

# macOS / Linux
env | grep -iE '^(http_proxy|https_proxy|all_proxy|no_proxy)='

古いポート番号や以前のプロキシアドレスに加え、NO_PROXY や no_proxy も確認してください。たとえば、NO_PROXY=* は、この設定に対応するツールですべてのプロキシをバイパスします。ドメインのサフィックスに一致するルールの扱いは、ツールのドキュメントを確認してください。curlではHTTPプロキシ変数に特有のセキュリティ上の扱いがあります。POSIXシェルでは小文字の http_proxy を優先し、大文字の HTTP_PROXY だけを設定しないでください。

現在のターミナルだけに設定し、確認後に永続化する

# PowerShell：現在のプロセスと、そこから起動する子プロセスに適用
$env:http_proxy = "http://127.0.0.1:7890"
$env:https_proxy = "http://127.0.0.1:7890"

# macOS / Linux：現在のシェルと、そこから起動する子プロセスに適用
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890

これらの設定は、起動済みの IDE、バックグラウンドサービス、ほかのターミナルウィンドウには自動で反映されません。環境変数が有効か確認するには、対象のプログラムを起動し直すか、現在のターミナルから直接実行してください。sudo を使うと環境変数が引き継がれないことがあります。また、WSL、コンテナ、リモート SSH セッション内の 127.0.0.1 はホスト側と同じとは限らないため、ネットワークの境界と実際に到達できるアドレスを確認してください。

Gitには独立したプロキシ設定がある場合もあります。次のコマンドで設定元を確認します。リポジトリや組織の設定を上書きしないよう、変更前に内容を確認してください。

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

リクエストがコアに届いた後：Rule、DIRECT、ポリシーグループを確認

Connectionsで対象のリクエストを探し、宛先ドメイン、適用ルール、ルールの内容、プロキシチェーンを確認します。項目名はクライアントによって異なりますが、判断方法は同じです。チェーンが DIRECT なら、そのリクエストは直接接続に選択されています。ポリシーグループと実際のノードが表示される場合は、そのノードに沿って引き続き調べてください。

モードを確認：Rule はルールに従って振り分け、Direct モードは直接接続します。Global はグローバルポリシーを使用します。システムプロキシのスイッチは、これら3つのモードとは別の設定です。
ルールの順序を確認：通常、ルールは上から順に評価されます。先にあるドメイン、IP、ルールセットの項目が一致すると、末尾の MATCH はそのルールを上書きしません。
グループ内の選択を確認：ルールの転送先が「プロキシ」という名前のポリシーグループでも、グループ内で DIRECT が選ばれている場合があります。グループ名だけでは、実際の通信経路は判断できません。
ドメイン情報を確認：アプリによるIPへの直接接続、DNSキャッシュ、接続の取り込み方式の違いによって、コアがルール照合に使える情報が変わることがあります。ドメインルールが適用されないからといって、すぐにルールセットの不具合だと判断しないでください。

必要であれば、一時的にGlobalへ切り替え、利用できることが確認済みのノードを選んで比較します。Globalでは接続できてRuleでは直接接続される場合は、ルールとグループ内の選択を重点的に確認してください。テスト後は元のモードに戻します。ノードやルールを変更しても、既存のTCPやHTTP/2接続は再確立されない場合があります。新しい経路を検証するには、アプリから接続を再度開始してください。

システムプロキシの対象外になる通信は、TUNの利用を検討

システムのHTTPプロキシはすべてのUDP通信を取り込めるわけではなく、独自のネットワークスタックを実装したゲーム、コマンドラインツール、その他のアプリを必ず経由させられるわけでもありません。Clash Meta（mihomo）のTUN機能は、仮想ネットワークインターフェースとルーティングを使って通信を取り込みます。対象範囲はシステムプロキシとは異なりますが、プラットフォームの権限、ルーティング、DNS設定、コアの設定に左右されます。

ローカルポートが確認できていない段階で、TUNの有効化、DNSの変更、Globalへの切り替えを同時に行わないでください。結果が変わっても、どの変更が影響したのか分からなくなります。対象のアプリがプロキシに対応していない場合は、クライアントの説明を参照し、TUNに必要なサービスや管理者権限を確認してください。VPNや他の仮想ネットワークインターフェースとの競合も調べます。ブラウザーのセキュアDNSは名前解決の経路に影響しますが、「ブラウザーがHTTPプロキシを回避している」と単純に同じ意味ではありません。

再テストと記録：同じ宛先で変更前後を比較

クライアント名と実際のバージョン、コアのバージョン、OSのバージョン、HTTPまたは混合プロキシのポートを記録します。「最新版」とだけ書くのは避けてください。
各テストで変更する項目は1つだけにし、テスト用ドメイン、リクエストツール、選択するノードを揃えて、実施時刻を記録します。
ブラウザーでの結果、プロキシを明示したcurlの結果、接続画面に表示された適用ルールと実際のプロキシチェーンをあわせて保存します。
出口IPを確認する場合は、信頼できるサービスを使い、接続記録と照らし合わせてください。単一のページに表示される位置情報は反映が遅れることがあるため、通信経路の証拠にはなりません。
トラブル情報を共有する前に、サブスクリプションURL、アクセストークン、ノードの認証情報、個人のアクセス履歴を削除してください。コマンドの詳細出力も共有前に確認します。

最終的に、問題を具体的な段階まで絞り込みます。ローカルポートが待ち受けていない、アプリがプロキシを使っていない、PACや例外リストが通信を迂回させている、ルールが直接接続を選択している、またはプロキシチェーンへの接続に失敗している、といった状態です。プロキシを明示したテスト、ブラウザーの設定、コアの接続記録という3つの証拠が一致すれば、原因を推測してクライアントを何度も再インストールする必要はありません。基本設定の手順ははじめにを、ルールやDNSの詳細は高度な設定をご覧ください。