Clashのシステムプロキシが有効なのに接続できない原因｜ブラウザー・ターミナル別の確認方法

まずプロキシの接続先を確認し、次にアプリの設定を調べる

まずは現在の設定を変えず、プロキシを明示したリクエストを1つ送ってローカルポートへの接続を確認します。システムプロキシを有効にすると、クライアントはプロキシのアドレスをOSの設定に反映しようとします。ただし、これだけではコアがポートを待ち受けていることも、すべてのアプリがその設定を参照していることも確認できません。ブラウザー、コマンドラインツール、仮想NICでは通信経路が異なります。まとめて調べると、正常な直接接続ルールをプロキシの不具合と誤認するおそれがあります。

まず3つの基本項目を確認

クライアントのコアが起動し、現在の設定が有効になっていることを確認します。サブスクリプションを読み込んだだけで、対象の設定に切り替えていない場合、ルールが読み込まれているとは限りません。
現在のHTTPまたはmixedポート、動作モード、選択中のプロキシグループとノードを記録します。調査中は通信経路が重ならないよう、TUNをいったん無効にしてください。
クライアントの「接続」と「ログ」を開き、同じ宛先にリクエストを送ります。スイッチの色だけでなく、宛先ドメイン、適用されたルール、最終的なポリシーを確認してください。

メニュー名はクライアントによって異なります。設定ファイルの port はHTTPプロキシの接続先、socks-port はSOCKSの接続先、mixed-port はHTTPとSOCKSの両方を受け付けます。クライアントが値を上書きする場合もあるため、サブスクリプションの原文だけでなく、最終的な実行設定を確認してください。ローカルでのみ使用する場合、調査のために「LAN内接続を許可」を有効にする必要はありません。

curlでプロキシを明示し、ポートの問題とルールによる直接接続を切り分ける

Windows PowerShellでは curl.exe を使ってください。Windows PowerShell 5.1では、curl が Invoke-WebRequest のエイリアスとして実行されるためです。macOSとLinuxでは curl をそのまま使えます。以下の example.com はリクエスト経路の確認用であり、地域制限の解除やノード速度の測定には使えません。

Windows：HTTPプロキシを明示して接続

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 の影響を防ぎます。詳細出力では、まず 127.0.0.1:7890 への接続が表示され、その後HTTPSの宛先に CONNECT example.com:443 が送られます。トンネルが確立すればリクエストはローカルプロキシに届いていますが、最終的にプロキシノード経由か DIRECT かは、クライアントの接続履歴もあわせて確認してください。

確認できた結果	考えられる原因	次に確認すること
ローカル接続が拒否される	ポートが待ち受けていない、または指定が間違っている	コアの状態、実際のポート番号、ポートの使用状況を確認する
トンネル確立後にリクエストがタイムアウトする	プロキシの入口には接続できるが、その先の経路に問題がある	選択中のノード、宛先への接続可否、コアのログを確認する
クライアントの接続履歴に DIRECT と表示される	通信はコアに届いているが、ルールによって直接接続になっている	適用されたドメインルールとプロキシグループを確認する
プロキシを明示したリクエストは成功するが、ブラウザーでは失敗する	ブラウザーのプロキシ設定が異なる可能性がある	拡張機能、PAC、ブラウザー独自の設定を確認する

Windowsでは Get-NetTCPConnection -LocalPort 7890 -State Listen を実行すると、待ち受け状態とプロセスを確認できます。Linuxでは ss -ltnp 'sport = :7890'、macOSでは lsof -nP -iTCP:7890 -sTCP:LISTEN を実行してください。別のプログラムがポートを使用している場合は、サブスクリプションを何度も更新するのではなく、先に競合を解消します。

ブラウザーを個別に確認：拡張機能、システムプロキシ、PAC

プロキシを明示したテストが成功したら、次にブラウザーを確認します。ChromeとEdgeは通常システムプロキシを参照しますが、拡張機能、起動オプション、組織のポリシーによって設定が上書きされることがあります。Firefoxには独自の接続設定もあります。ブラウザーでページを開けても、プロキシを使っているとは限りません。キャッシュされたページやルールによる直接接続を成功と誤認することがあります。

まずOSに反映された設定を確認

Windows 11：「設定」→「ネットワークとインターネット」→「プロキシ」を開き、「手動プロキシセットアップ」のアドレスとポートを確認します。ローカルのHTTP接続先を使う場合、アドレスは 127.0.0.1、ポートはクライアントと同じ値にします。
macOS 13以降：「システム設定」→「ネットワーク」→現在の接続→「詳細」→「プロキシ」を開きます。Webプロキシ、安全なWebプロキシ、自動プロキシ構成をそれぞれ確認し、実際に使用中のネットワークサービスを変更していることを確かめてください。
Firefox：「設定」→「一般」→「ネットワーク設定」→「設定」を開き、「システムのプロキシー設定を利用する」が選択されているか確認します。手動でプロキシを設定している場合は、アドレス、ポート、プロキシを使用しないアドレスの一覧を記録してください。

Windowsの netsh winhttp show proxy で確認できるのはWinHTTPの設定であり、ブラウザーが使用するユーザー向けプロキシ設定を直接示すものではありません。ここに直接接続と表示されても、クライアントがシステムプロキシを設定していないとは限りません。ブラウザーの問題を解決するために、まず端末全体のWinHTTP設定を変更するのは避けてください。

プロキシを制御する拡張機能を一時的に無効にする

Chromeの chrome://extensions/ またはEdgeの edge://extensions/ を開き、プロキシを制御できる拡張機能を一時的に無効にしてから、ブラウザーを完全に終了して再起動します。シークレットウィンドウでもプロキシ設定の参照元が分離されるとは限らず、すべての拡張機能が無効になる保証もありません。組織管理の端末では、chrome://policy/ または edge://policy/ も確認してください。ポリシーで管理されている設定は、管理者に確認します。

PACがDIRECTを返すと、ローカルのコアにはリクエストが届かない

PACはブラウザー側でプロキシの接続先を選ぶスクリプトで、Clashのコア内のルールとは別の層で動作します。PACが DIRECT を返すと、ブラウザーは直接接続します。PROXY 127.0.0.1:7890 を返した場合に、リクエストがローカルのHTTP接続先へ送られます。PACに PROXY 127.0.0.1:7890; DIRECT と書かれていると、プロキシに接続できないときに直接接続へフォールバックする場合もあります。

調査中は自動構成スクリプトを一時的に無効にし、手動プロキシ設定だけにしてブラウザーを再起動したうえで、同じ宛先に再度リクエストを送ると切り分けやすくなります。元に戻せるよう、以前のPACアドレスを記録してください。2種類の設定を同時に有効にして、優先順位を推測するのは避けましょう。ブラウザーからのリクエストがクライアントにまったく記録されず、curlを明示したリクエストだけ記録される場合は、ルールセットではなくブラウザーの除外リストやPACを優先して確認します。

ターミナルを個別に確認：環境変数とツールの設定

ターミナルのアプリがシステムプロキシを参照するとは限りません。curl、Git、パッケージ管理ツールにはそれぞれ設定元があり、システムプロキシを有効にしても直接接続することはよくあります。まず現在のターミナルの環境変数を確認し、次に各ツール固有の設定を調べてください。すでに起動しているプロセスには、後から変更した環境変数が通常自動で反映されません。

macOS / Linux：1つのコマンドだけにプロキシを設定

env | grep -iE '^(http_proxy|https_proxy|all_proxy|no_proxy)='

https_proxy=http://127.0.0.1:7890 http_proxy=http://127.0.0.1:7890 \
curl -v --noproxy "" --max-time 20 https://example.com/ -o /dev/null

ここで https_proxy の値が http:// で始まるのは、まずローカルのHTTPプロキシに接続し、CONNECTでHTTPSサイトへのトンネルを作るためです。接続先のURLがHTTPSだからといって、ローカルプロキシのアドレスを https://127.0.0.1:7890 に変更しないでください。通常のHTTPプロキシポートは、TLS接続のプロキシ入口ではありません。

curlがHTTPプロキシの環境変数として参照するのは、小文字の http_proxy です。ほかの変数で大文字・小文字が区別されるかは、ツールによって異なります。NO_PROXY または no_proxy に宛先のドメイン、アドレス範囲、* が含まれていると、リクエストがプロキシを使わない場合があります。必要なローカル向け除外設定は残し、項目ごとに確認してください。除外ルールをすべて恒久的に消すのは避けましょう。

PowerShell：現在のセッションにプロキシ変数を設定

Get-ChildItem Env: | Where-Object Name -Match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$'

$env:HTTP_PROXY = 'http://127.0.0.1:7890'
$env:HTTPS_PROXY = 'http://127.0.0.1:7890'
curl.exe -v --noproxy "" --max-time 20 https://example.com/ -o NUL

上記の設定は、現在のPowerShellと、そこから起動する子プロセスにだけ適用されます。すでに起動しているIDE、ターミナルのタブ、バックグラウンドタスクの環境は更新されません。テストを取り消す場合、これらの変数がもともと設定されていなければ、以下のコマンドで削除できます。以前から値が設定されていた場合は、記録した元の値に戻してください。

Remove-Item Env:HTTP_PROXY, Env:HTTPS_PROXY -ErrorAction SilentlyContinue

Gitが接続できない場合は、Git独自のプロキシ設定を確認

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

このコマンドでは、リポジトリ、ユーザー、またはシステム単位の設定にあるプロキシ関連項目を確認できます。特定のURL向けの設定が別にある場合もあります。一致する項目がなければコマンドが0以外の終了ステータスを返すことがありますが、Gitの故障を意味するわけではありません。HTTPSリポジトリとSSHリポジトリでは通信方式が異なるため、http.proxy を設定してもSSH接続の問題は直接解決できません。npmやpipなども個別に確認が必要です。curlが成功しても、すべての開発ツールがプロキシを使っているとは限りません。

ルールとDNSを確認：コアに届いてもノード経由とは限らない

ブラウザーやターミナルのリクエストが接続一覧に表示されたら、「入口」の問題から「ルーティング」の問題へ切り替えて調べます。ルールモードではルールが順番に評価され、該当するポリシーまたはプロキシグループに振り分けられます。DIRECT に一致した場合、直接接続のメンバーが選ばれた場合、またはプロセスルールが先に一致した場合は、出口がローカルネットワークのままになることがあります。

直前にテストした宛先を見つけ、一致したルール、ポリシーの経路、選択中のノードを記録します。プロキシグループ名だけを確認して終わらせないでください。
動作モードが直接接続モードになっていないことを確認します。ルールモードではルールの順序、特に先に記述されているドメイン、プロセス、アドレスのルールを確認してください。
必要であれば一時的にグローバルモードに切り替え、グローバルポリシーで利用可能なプロキシノードが選択されているか確認します。同じリクエストを再試行したら元のモードに戻してください。グローバルモードでのテストはルールの影響を切り分けるためのもので、恒久的な解決策ではありません。
リクエストがコアに届いた後、名前解決エラーが発生する場合は、DNSの設定とログを確認してください。ノード、DNS、ルールセットを一度に変更しないでください。

ブラウザーのセキュアDNS設定は名前解決の経路に影響することがありますが、それだけで「HTTPプロキシを通らない」とは判断できません。HTTP CONNECTでは、ブラウザーが宛先ドメインをプロキシに渡すことができます。TUNではDNSの引き継ぎやドメインとIPアドレスの対応付けも関係します。DNS設定だけで経路を推測せず、接続履歴を確認してください。Fake-IPの設定を変更した後は、接続を張り直す必要がある場合もあります。既存の長時間接続では変更後の状態を判断できません。

TUNを使う場面：プロキシ設定を参照しないアプリへの対応

プロキシを明示したテスト、ブラウザーのシステムプロキシ、ターミナルの環境変数がすべて正常なのに、プロキシ設定を参照しない一部のアプリだけが直接接続する場合は、TUNの利用を検討します。TUNは仮想NICとルーティングによって対象範囲の通信を取り込み、システムプロキシとは別の仕組みで動作します。ノードの接続不可、サブスクリプションの誤り、ルールによる直接接続を解決するものではありません。

権限、ルーティング、DNSの3点を確認

権限とサービス：クライアントの案内に従って必要なサービスをインストールまたは起動し、仮想NICが正しく作成されたことを確認します。Windows、macOS、Linuxでは権限の仕組みが異なるため、同じ手順を当てはめないでください。
ルーティング：現在の実行設定にある tun.enable、auto-route などの項目とログを確認します。TUN用のNICが存在しても、すべての宛先やプロトコルがそこを通るとは限りません。
DNSと競合：別のVPN、仮想マシンのネットワーク、企業向けセキュリティソフトが同時にルートやDNSを書き換えていないか確認します。一度に無効にするのは1つだけにし、元に戻す方法も記録してください。通常の業務ネットワークに影響を与えないよう注意しましょう。

デスクトップクライアントは、TUNの設定の一部を代わりに管理できます。一方、mihomoコアのみを導入する場合は、必要な権限と実行設定を自分で確認してください。LAN内の端末に接続できない、DNSがタイムアウトする、TUNの起動後にすべて通信できなくなる場合は、まずTUNを無効にして、確認済みのシステムプロキシ経由の通信に戻してからルーティングとDNSを調べます。あらゆる問題を「管理者として実行すれば解決する」と考えないでください。

テスト結果から原因を絞り、再インストールを繰り返さない

効果的な調査記録には、ローカルのプロキシ接続先に接続できるか、宛先へのリクエストがコアに表示されるか、どのポリシーが適用されたか、どのアプリで失敗するかの4点を含めます。同じ宛先に対してcurlでの明示接続、ブラウザー、アプリをそれぞれテストすると、サイト、キャッシュ、ノードの状態による影響を減らせます。

curlでプロキシを明示しても失敗：まずポート、コアの稼働状態、その先のノードへの接続を直します。
curlは成功するがブラウザーの接続履歴に記録されない：拡張機能、PAC、ブラウザーのプロキシ設定元を優先して確認します。
ブラウザーでは成功するがターミナルでは失敗：現在のプロセスの環境変数、除外リスト、ツール固有の設定を確認します。
すべてのリクエストが記録されるのに、出口が直接接続のまま：ルールとポリシーの選択を確認します。システムプロキシの設定を変更し続ける必要はありません。
特定のアプリだけが直接接続する：アプリのプロキシ対応を確認し、個別に設定するかTUNを有効にするか判断します。

ほかの人に調査を依頼する場合は、OSとクライアント、コアのバージョン、実際の待ち受けポート、機密情報を伏せたエラーログを共有してください。サブスクリプションのURL、アクセストークン、ノードのパスワード、個人用の宛先ドメインは削除します。原因を特定できない場合はトラブル対処ガイドも確認してください。プロキシ設定を復元したら、使い方ガイドを参考に日常の設定を整えましょう。