システムプロキシ・アプリごとのプロキシ・ルールによる振り分けを区別する

システムプロキシを有効にしても、OSにプロキシ設定が登録されるだけで、すべてのプロセスがそれを使うわけではありません。ブラウザーはシステム設定に従う場合もあれば、拡張機能や個別設定で上書きされる場合もあります。コマンドラインのプログラムでは、通常、環境変数や専用オプションの設定が必要です。接続がClashのコアに到達した後も、現在のモードやルール、ポリシーグループによって最終的な接続先が決まります。

そのため、「出口のIPアドレスが変わらない」ことだけでは、システムプロキシが機能していないとは判断できません。接続がコアに到達したうえで DIRECT に振り分けられている可能性も、アプリがプロキシを完全に迂回している可能性もあります。切り分けでは、アプリの設定とクライアントの接続ログをあわせて確認しましょう。Webページが開くかどうかだけで判断しないでください。

これらの項目に対応するClashまたはmihomoコアでは、次の設定例により、HTTPとSOCKSのプロキシをローカルでのみ受け付けます。既存の設定に統合して使うもので、ノードやルールは含まれていません。完全なサブスクリプション設定の代わりにはなりません。

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

手順1：コアの待ち受け状態とプロキシを明示したリクエストを確認する

まずはシステムプロキシの設定を介さず、コマンドで接続先を明示します。明示的なプロキシ指定でも失敗する場合は、ブラウザーの設定を変える前に、待ち受けポート、コアの稼働状態、ノードへの接続を確認してください。

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

Windows PowerShellでは、次のコマンドを実行します。出力の OwningProcess はプロセスIDです。タスクマネージャーの「詳細」タブで照合し、Clash以外のソフトがポートを使用しているケースと取り違えないようにしましょう。

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

macOSでは lsof、Linuxでは ss を使えます。何も表示されない場合は、実際のポートが異なっていないか、設定が正常に読み込まれているかを確認してください。

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

# Linux
ss -lntp 'sport = :7890'

curlでHTTPプロキシを明示する

Windowsでは curl.exe を使います。PowerShell環境によっては同名のエイリアスが使われることがあるためです。macOSとLinuxでは、コマンド名を curl に置き換えてください。--noproxy "" は、既存のプロキシ除外リストが今回のテストに影響するのを防ぎます。

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

まず 127.0.0.1:7890 に接続できるか、次にHTTPSのCONNECTトンネルが確立されるかを確認し、最後に接続先サイトの応答を見ます。例のドメインは接続テスト用です。実際の問題を調べるときは、問題が起きているURLを使ってください。

結果優先して確認する項目
ローカルの7890番ポートへの接続が拒否されるコアが起動しているか、ポートが一致しているか、待ち受けアドレスに接続できるか。
ローカルのプロキシには接続できるが、接続先がタイムアウトするクライアントログに記録された接続先、ルール、ポリシーグループ、ノードの出口。
リクエストは成功するが、ブラウザーでは失敗するブラウザーのプロキシ設定元、拡張機能、除外リスト、既存の接続。
オプションを指定すれば成功するが、通常のターミナルコマンドは失敗する環境変数が設定されているか、プログラムが対応しているか、ツール独自の設定に上書きされていないか。

CONNECTの成功から確認できるのは、プロキシがトンネル要求を受け付けたことまでです。特定のリモートノードを経由したことまでは証明できません。最終的な経路は、クライアントの接続詳細にあるルールと経路をあわせて確認してください。

手順2：ブラウザーのプロキシ設定元を順に確認する

まずOSで実際に使われているアドレスを確認する

Windows 11では、「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシのアドレスとポートを確認します。macOSでは、「システム設定」→「ネットワーク」→現在使用中のネットワークサービス→「詳細」→「プロキシ」の順に開きます。OSのバージョンによって表示名が多少異なる場合があります。切断中のWi-Fiやネットワークアダプターではなく、現在使っているネットワークサービスを確認してください。

次に拡張機能とブラウザー独自の設定を確認する

通常のデスクトップ環境では、ChromeやEdgeはシステムプロキシを参照するのが一般的です。ただし、プロキシ切り替え拡張機能、起動オプション、企業ポリシーによって設定が上書きされることがあります。まずプロキシ関連の拡張機能を一時停止し、ブラウザーを完全に終了してから起動し直し、同じURLでテストしてください。拡張機能はシークレットモードでの実行が許可されている場合があるため、シークレットウィンドウでも必ず無効になるとは限りません。

Firefoxでは、「設定」→「一般」→「ネットワーク設定」→「設定」を開き、プロキシの設定元を確認します。OSの設定を使う場合は「システムのプロキシ設定を利用する」を選択します。「手動でプロキシを設定する」を選んでいる場合は、アドレス、ポート、「プロキシなし」のリストを個別に確認してください。

会社の管理対象デバイスでは、ブラウザーが管理対象になっていないかも確認します。Chromeの chrome://policy とEdgeの edge://policy で、ポリシーが適用されているか確認できます。管理ポリシーによる制限がある場合は、設定を何度も上書きせず、管理者に確認してください。

除外リストと既存の接続を確認する

ブラウザーやOSでは、ローカルアドレス、社内ドメイン、指定したネットワーク範囲をプロキシから除外している場合があります。localhost、ルーターの管理画面、社内ネットワークのアドレスでは、インターネット向けのプロキシが機能するか判断できません。設定を変更しても、既存の長時間接続が再利用されることがあります。ページを何度も再読み込みするより、該当するタブを閉じてブラウザーを完全に終了し、起動し直してからテストしましょう。

手順3：ターミナルにhttp_proxyとHTTPS_PROXYを個別に設定する

クライアントでシステムプロキシを有効にしても、ターミナルのすべてのコマンドに環境変数が自動設定されるわけではありません。まず現在のセッションだけで一時的に設定し、動作を確認してから永続化を検討してください。HTTPプロキシの入口を使う場合、接続先がHTTPSのWebサイトでも、プロキシのURLは通常 http://127.0.0.1:7890 とします。変数名にHTTPSが含まれているからといって、https:// に変更しないでください。

macOS・Linux：現在のシェルで一時的に設定する

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

curl --connect-timeout 10 --max-time 30 -v https://example.com/

# テストが終わったら今回の設定を解除する
unset http_proxy https_proxy no_proxy

curlがHTTPプロキシ用の環境変数として認識するのは小文字の http_proxy だけです。他のプログラムでは大文字・小文字の扱いが異なる場合があります。大文字の変数、ALL_PROXY、ツール独自の設定も同時に存在する場合はあわせて確認しましょう。片方の変数を削除しても、別の設定が影響している可能性があります。

Windows PowerShell：現在のプロセスの環境変数

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

curl.exe --connect-timeout 10 --max-time 30 -v https://example.com/

# テストが終わったら今回の設定を解除する
Remove-Item Env:HTTP_PROXY, Env:HTTPS_PROXY, Env:NO_PROXY

これらの設定は、現在のPowerShellと、そこから起動した子プロセスにのみ適用されます。すでに起動しているIDE、ターミナル、バックグラウンドサービスの環境変数は変更されません。元の変数値がある場合は先に記録し、テスト後に元へ戻してください。安易に削除しないようにしましょう。システム画面から環境変数を永続的に変更した場合は、通常、新しい値を反映するために関連アプリの再起動が必要です。

手順4：Git、WSL、ツール独自のプロキシ設定を確認する

curlでは成功するのに特定のツールで失敗する場合、すぐにノードが使えないと判断する必要はありません。Git、パッケージマネージャー、ランタイムには独自のプロキシ設定がある場合や、環境変数を異なるネットワークライブラリで処理する場合があります。例としてGitでは、まず設定済みの項目とその設定元をすべて確認します。

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

設定はシステム、ユーザー、現在のリポジトリのいずれかから読み込まれている可能性があります。古い設定だと確認できた場合は、該当するスコープで修正してください。すべての階層の設定をまとめて消去しないでください。1回限りのコマンドでプロキシを指定する場合は、次のように実行します。

git -c http.proxy=http://127.0.0.1:7890 ls-remote https://github.com/git/git.git HEAD

手順5：リクエストがコアに届いたら、ルールと出口を確認する

クライアントの接続一覧または実行ログで、接続先のドメイン名とテスト時刻を手がかりに今回のリクエストを探します。接続先アドレス、適用されたルール、選択されたポリシーグループ、実際の経路を記録してください。クライアントによって画面の名称は異なりますが、これらの情報は「有効」の表示よりも通信経路の判断に役立ちます。

  1. DIRECT と表示される場合は、直接接続のルールに一致していないか、ポリシーグループで直接接続が選択されていないか確認してください。
  2. 想定したポリシーグループに入っているのにタイムアウトする場合は、ノード、サーバー、ローカルからノードまでの接続を確認してください。
  3. 該当する記録がまったくない場合は、まずログレベルとフィルター条件を確認し、リクエストが実際に送信されているかを確かめてから、アプリ側の接続設定に戻ってください。

一時的に log-level: debug にすると、手がかりを増やせる場合があります。再現テスト後は info に戻してください。ログにはドメイン名、内部ネットワークのアドレス、サブスクリプション関連の情報が含まれることがあります。他者に共有する前に伏せ字などで秘匿してください。プロキシを「修復」するためにTLS証明書の検証を無効にしないでください。証明書エラーは、証明書チェーン、システム時刻、ネットワークによる遮断を個別に確認しましょう。

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

アプリがプロキシ設定に対応していない場合や、より多くの通信を取り込みたい場合にTUNを検討してください。システムプロキシはアプリがプロキシを利用する仕組みですが、TUNは仮想ネットワークインターフェースとルーティングを使って通信を取り込みます。Clash Metaから発展したmihomoは関連機能に対応していますが、利用できるかどうかはクライアントへの組み込み、システム権限、実行環境によって異なります。Clashという名前のすべてのクライアントが同じ実装とは限りません。

mihomo環境での次の例は、設定項目の関係を示すもので、すべてのデバイスに適用できる汎用設定ではありません。クライアントによっては画面上の選択に応じてこれらの項目を生成します。画面の設定と手書きの内容が互いに上書きしないよう、最終的に有効になっている設定を優先して確認してください。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

結果をもとに絞り込み、複数の設定を同時に変更しない

最短の確認手順は、待ち受けポートを確認 → プロキシを明示してテスト → ブラウザーの設定元を確認 → ターミナルの環境変数を確認 → クライアントのルールと経路を確認、です。通常のプロキシで接続できないアプリがある場合に限り、次の段階としてTUNを検討してください。

テストのたびに、OSとクライアント名、実際の待ち受けポート、実行したコマンド全文、同時刻の接続ログの4点を記録します。プロキシを明示すれば成功してブラウザーでは失敗する場合は、ブラウザーを調べます。ターミナルでオプションを付ければ成功し、付けないと失敗する場合は、環境変数とツールの設定を調べます。「システムプロキシが効かない」という問題を検証可能な単位に分ければ、クライアントを何度も再インストールせずに原因を絞り込めます。

設定項目の意味はClashの設定項目で確認できます。設定の初回インポートやプロキシモードの選択は、入門ガイドを順番に進めてください。