Clashのシステムプロキシを有効にしても反映されない：ブラウザーとターミナルの切り分け

まず切り分ける：クライアントに届いていないのか、届いた後の通信に失敗しているのか

「システムプロキシ有効」は、クライアントがOSのプロキシ設定を変更しようとしたことを示すだけで、すべてのアプリがその設定を使うとは限りません。ブラウザーは拡張機能がプロキシを制御している場合があり、ターミナルのツールは環境変数しか参照しないことがあります。リクエストがClashに届いていても、ルールによってDIRECTに振り分けられたり、ノードへの接続失敗で通信が完了しなかったりすることもあります。

この記事ではWindows、macOS、Linuxのデスクトップ環境を対象にします。Clashはプロキシコアや関連クライアント群の一般的な呼び名で、Clash Metaは後にmihomoという名称になりました。設定項目の場所はクライアントによって異なり、コアの名称で画面のメニューが決まるわけではありません。AndroidやiOSではVPNによる通信の取り込み方がデスクトップのシステムプロキシとは異なるため、この記事のシステム設定手順をそのまま適用しないでください。

1. クライアントで設定が読み込まれていることを確認します。出站モードはまず「ルール」にし、現在のプロキシグループで選択されているノードを記録してください。
2. クライアントの「接続」画面を開き、「ログ」も確認します。必要に応じて、一時的にログレベルをinfoに設定してください。
3. 対象ドメインを指定して新しいリクエストを送信し、接続時刻、宛先アドレス、適用ルール、出站経路を確認します。
4. 記録がない場合は、まずアプリからの通信経路を確認します。記録がありDIRECT経由ならルールを、記録はあるものの接続がタイムアウトするならノード、DNS、接続先サービスを調べてください。

ローカルの接続先：アドレス、ポート、コアの状態を確認

以下では127.0.0.1:7890を例に説明します。7890はよく使われる設定値ですが、すべてのクライアントで共通の固定ポートではありません。クライアントの「設定」にある「ポート」または「混合ポート」で実際の値を確認し、コマンドのポート番号を置き換えてください。コントローラーポートやダッシュボードのアドレスを、プロキシポートに指定しないよう注意してください。

Windows：待ち受けポートとプロセスを確認

netstat -ano | findstr :7890

出力から、ローカルアドレスが127.0.0.1:7890または該当する待ち受けアドレスで、状態がLISTENINGの行を探します。末尾のPIDを控え、「タスク マネージャー」→「詳細」でプロセスを確認してください。ポートを別のクライアントが使用していると、現在のクライアントは画面上では起動しても、コアがポートのバインドに失敗している場合があります。

macOS、Linux：TCPの待ち受け状態を確認

lsof -nP -iTCP:7890 -sTCP:LISTEN

lsofがインストールされていない場合、Linuxではss -lntpで待ち受け一覧を確認できます。待ち受けがなければ、コアの起動ログ、設定の解析エラー、ポートの競合を先に調べてください。ブラウザーの設定を変更するのはその後です。ローカルでのみ使用する場合は、通常「LAN内からの接続を許可」を有効にする必要はなく、待ち受けアドレスをすべてのネットワークインターフェースに広げる必要もありません。

ブラウザーの確認：システム設定、拡張機能、PAC、例外設定

OSに保存されている実際のプロキシアドレスを確認

• Windows 11：「設定」→「ネットワークとインターネット」→「プロキシ」を開きます。「手動プロキシ セットアップ」のサーバーとポートを確認し、「セットアップ スクリプトを使う」が古いPACアドレスを参照していないかも確認してください。
• macOS 13以降：「システム設定」→「ネットワーク」→現在使っているネットワークサービス→「詳細」→「プロキシ」を開きます。「Webプロキシ（HTTP）」「保護されたWebプロキシ（HTTPS）」「自動プロキシ構成」を確認してください。Wi-Fiと有線ネットワークを切り替えた後は、対応するサービスの設定を改めて確認します。
• GNOMEデスクトップ：通常は「設定」→「ネットワーク」→「ネットワークプロキシ」で確認できます。デスクトップ環境によってシステムプロキシの設定方法は異なり、アプリが同じ設定を参照するとも限りません。

HTTPプロキシのアドレスには通常127.0.0.1を指定し、ポート欄には7890を入力します。HTTPSサイトにはHTTPプロキシのCONNECTトンネルを使って接続するため、プロキシサーバーのアドレスに必ずhttps://を付ける必要があるわけではありません。入力欄にプロトコルの指定が必要かどうかは、OSの画面に従ってください。

Chrome、Edge：拡張機能とポリシーによる上書きを確認

Chromeではアドレスバーにchrome://settings/system、Edgeではedge://settings/systemを入力して、システムプロキシの設定を開きます。続けてchrome://extensionsまたはedge://extensionsで拡張機能を確認し、プロキシ切り替え系の拡張機能を一時的に無効にしてから、ブラウザーを完全に終了して再起動してください。

シークレットウィンドウだけでは十分な切り分けになりません。一部の拡張機能はシークレットモードでも実行でき、システムプロキシや組織のポリシーも引き続き適用されます。管理対象のデバイスではchrome://policyまたはedge://policyも確認してください。組織のポリシーでプロキシが固定されている場合は、設定を繰り返し上書きせず、管理者に問い合わせてください。

Firefox：独自のネットワーク設定を確認

Firefoxで「設定」→「一般」→ページ下部の「ネットワーク設定」→「設定」を開きます。システム設定を使うには「システムのプロキシー設定を利用する」を選択してください。「手動でプロキシーを設定する」を選んでいる場合は、HTTPプロキシ、ポート、HTTPSにも同じプロキシを使うかを確認します。「プロキシーなし」や「このネットワークのプロキシー設定を自動検出する」は、クライアントが設定した手動プロキシを参照する設定ではありません。

PACとバイパスリスト：クライアントに届く前にドメイン別の振り分けが行われることがある

PACスクリプトはURLに応じてDIRECTまたはプロキシアドレスを返します。対象ドメインに対してPACがDIRECTを返すと、リクエストはClashに届かず、クライアントのルールも適用されません。元の設定を記録したうえで、自動スクリプトを一時的に無効にし、手動HTTPプロキシなど接続経路を一つだけ残して、同じ宛先に再度リクエストしてください。

Windowsのプロキシ例外、macOSの「これらのホストとドメインにはプロキシ設定を使用しない」、Firefoxの「プロキシーなし」リストも確認してください。localhost、127.0.0.1、内部ドメインはバイパスされることが多く、ローカルのページに接続できるかどうかでは、外部への通信がプロキシを経由しているか判断できません。テストには新しいリクエストを使い、ブラウザーのキャッシュに惑わされないよう、クライアントに対象ドメインの接続が記録されるかも確認してください。

ターミナルの確認：プロキシを明示してから環境変数を調べる

ターミナルはブラウザーとは異なり、プロセスの起動環境に依存します。curl、Git、パッケージマネージャー、スクリプト実行環境では、それぞれプロキシの参照方法が異なります。デスクトップのシステムプロキシを有効にしても、これらのツールが自動的にプロキシを使うとは限りません。まずは一度のリクエストでローカルの接続先を明示し、環境変数やアプリ側の設定による影響をできるだけ避けます。

curlで最小限の接続テストを行う

macOSまたはLinuxで以下のコマンドを実行します。Windows PowerShellでは同じ引数を使いますが、コマンド名はcurl.exeとしてください。Windows PowerShell 5.1ではcurlが別のコマンドのエイリアスになっているためです。

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

--noproxy ""は今回のリクエストでバイパスリストを空にする指定です。--connect-timeout 10は接続のタイムアウトを、--max-time 20はリクエスト全体のタイムアウトを、それぞれ秒単位で設定します。宛先がHTTPSの場合、ログには通常、まずローカルプロキシへの接続が表示され、その後にCONNECTトンネルの処理が表示されます。200 Connection establishedはトンネルが確立したことを示すだけで、その後のTLS接続やWebリクエストの成功を保証するものではありません。

• Connection refused：まずローカルポート、待ち受けアドレス、コアの稼働状態を確認してください。
• ローカルポートには接続できるものの、CONNECTまたは後続のリクエストがタイムアウトする場合は、クライアントのログと照らし合わせて、プロキシグループ、ノード、接続先サービスを確認してください。
• プロキシを明示すると成功し、通常のcurlでは失敗する：環境変数とツール固有の設定を重点的に確認してください。
• 証明書エラー：システム時刻、証明書の信頼チェーン、管理対象ネットワークを確認してください。証明書検証の無効化を恒久的な対処にしないでください。

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 -v --connect-timeout 10 --max-time 20 https://example.com/

https_proxyはHTTPSの宛先に使うプロキシを指定する変数ですが、値にはhttp://を指定できます。curlはHTTPプロキシの環境変数として小文字のhttp_proxyのみを受け付け、大文字のHTTP_PROXYは受け付けません。他のツールでは大文字・小文字の扱いが異なるため、すべてのプログラムで同じ動作をすると考えないでください。

これらのexportが影響するのは、現在のシェルと、その後に起動した子プロセスだけです。すでに起動しているプログラムの環境は変更されません。テストに成功したら、実際に使っているシェルに合わせて~/.zshrcや~/.bashrcなどの起動ファイルに記述してください。IDE内蔵のターミナルは、IDE起動時の古い環境を引き継いでいる場合があります。関連するプロセスを終了して再起動してください。

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 -v --connect-timeout 10 --max-time 20 https://example.com/

現在のウィンドウを閉じると、ここで設定した値は保持されません。Windowsのデスクトッププロキシ、WinHTTPプロキシ、プロセスの環境変数はそれぞれ別の設定経路です。netsh winhttp show proxyの結果だけでは、ブラウザーやcurlの動作全体は判断できません。対象のプログラムがWinHTTPを使うと確認できた場合に限り、この経路を調べてください。

残っている環境変数とアプリ固有のプロキシ設定を確認

macOS、Linuxではenv | grep -i proxy、PowerShellではGet-ChildItem Env:*proxy*を実行します。古いポートを参照するALL_PROXY、大文字の環境変数、範囲が広すぎるNO_PROXYを重点的に確認してください。curlでは通常、プロトコル別のプロキシ変数がALL_PROXYより優先されます。バイパスリストに一致すると、リクエストが直接接続される場合もあります。

Gitだけが失敗する場合は、git config --show-origin --get-regexp '.*proxy.*'で設定元を確認できます。パッケージマネージャーも独自のプロキシ設定を持つことがあるため、実際に使っているツールごとに確認し、すべてのグローバル設定を一度に変更しないでください。テストが終わったら、Unixシェルでは次のコマンドで、現在のセッションに設定した一般的なプロキシ環境変数を削除できます。

unset http_proxy https_proxy all_proxy no_proxy
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY

リクエストがClashに届いている場合：ルール、DNS、出站経路を確認

ブラウザーとcurlの宛先がどちらもクライアントの接続一覧に表示されているなら、接続経路は確立しています。この段階ではシステムプロキシを切り替えても、通常は解決につながりません。該当する接続の詳細を開き、対象ドメイン、適用ルール、プロキシグループ、最終的に使われたノードを順に確認してください。

1. ルールの判定がDIRECT：意図した動作か確認します。ルールは通常上から順に適用されます。後続のプロキシルールより前にある直接接続ルールが先に適用されることがあるため、ルールセットが正しく読み込まれているかも確認してください。
2. プロキシグループでDIRECTを選択：プロキシ用のルールに一致していても、グループ内でDIRECTが手動選択されていることがあります。グループ名だけでなく、実際に選択されている項目を確認してください。
3. ノードへの接続に失敗：同じグループ内の別のノードに切り替え、同じ宛先を再試行してください。遅延テストに成功しても、テスト先への接続が確認できるだけで、すべてのサイトにアクセスできるとは限りません。
4. DNSエラー：ログを確認し、対象ドメインの名前解決、プロキシサーバーの名前解決、DNSサーバーへの接続のどこで失敗したかを切り分けてください。原因が分からないまま、DNS、ルール、ノードを同時に変更しないでください。

ルールが原因か確認するには、一時的に「グローバル」モードに切り替え、プロキシノードを明示的に選択して一度だけテストします。テスト後は「ルール」に戻してください。グローバルモードで変わるのはコアに届いた後の出站先であり、プロキシを使っていないアプリの通信をクライアントに取り込む機能ではありません。

TUNモードを使うケース：プロキシ設定を参照しないアプリ向け

ブラウザーとプロキシを明示したテストは正常でも、一部のアプリがシステムプロキシや環境変数をまったく参照しない場合は、TUNモードを検討できます。TUNは仮想ネットワークインターフェースとルーティングを使って通信を取り込み、より多くのTCP・UDP通信をまとめて処理したい場合に役立ちます。実際に対象となる範囲はルート、除外設定、コアの設定、プラットフォームの権限によって異なり、有効にすればすべての接続が必ずリモートノードを経由するわけではありません。

• Windows：クライアントの手順に従ってサービスモードをインストールするか、管理者権限を付与してからTUNを有効にします。仮想ネットワークインターフェースとルートが正常に作成されたか確認してください。
• macOS：クライアントの手順に従ってヘルパーサービスをインストールし、必要なネットワーク権限を許可してください。起動に失敗した場合は、まず権限とルートのログを確認します。
• Linux：TUNデバイスが使用可能であることを確認し、クライアントの導入方法に従ってネットワーク管理に必要な権限を付与します。コンテナ環境や制限された環境では、仮想ネットワークインターフェースを作成できない場合があります。

mihomoの一般的なTUN設定には、enable、stack、auto-route、dns-hijackなどの項目があります。ただし、バージョンやクライアントによっては、設定が画面から自動生成されます。現在使っているクライアントのスイッチを優先し、他のプラットフォーム向けの設定全体を既存のサブスクリプションに上書きしないでください。

TUNを切り分けるときは、まず他のVPNや同様にルーティングを制御するクライアントを終了し、DNS、Webページ、ターミナル、LAN内のサービスの順にテストしてください。会社のVPN、仮想マシンのネットワークインターフェース、コンテナネットワークは自動ルーティングと競合することがあります。有効にした後にローカルサービスへ接続できない場合は、除外するネットワーク範囲とルートを確認し、例外設定をすべて削除するような対処は避けてください。

curlやGitなど一部のツールだけでプロキシを使う場合は、明示的な引数や環境変数を使うほうが問題を特定しやすくなります。プロキシ設定に対応していないアプリも対象にしたい場合は、TUNを検討してください。TUNを有効にした直後にネットワークへ接続できなくなったら、まず無効にして接続を復旧させ、権限、DNS、ルートのログを確認します。

再テストのチェックリスト：同じ宛先で3つの経路を確認

対象ドメインを一つに決め、プロキシを明示したcurl、ブラウザー、引数を指定しないターミナルリクエストの順にテストします。毎回、クライアントに接続が届いたか、どのルールに一致したか、最終的にどの出站先が使われたかを記録してください。3つの経路を確認したら、必要なPAC、拡張機能、TUNの設定を戻し、一時的に変更したログレベルも通常の値に戻します。