システムプロキシが効かないときの確認方法

まず確認：プロキシ設定、アプリの接続先、通信の出口

Clash クライアントに「システムプロキシが有効」と表示されても、通常はローカルプロキシのアドレスを OS の設定に反映しようとしたことを示すだけです。すべてのアプリが mihomo に接続されたことや、すべてのリクエストがリモートノードを経由することを意味しません。ブラウザーはシステム設定を参照する場合もあれば、拡張機能がプロキシ設定を引き継ぐ場合もあります。一方、ターミナルの curl、Git、パッケージ管理ツールは、それぞれ独自の環境変数や設定ファイルを使うことがあります。

リクエストは、アプリからローカルの待ち受けポートへの接続、mihomo によるルールとポリシーの選択、選択された出口から接続先への通信という3段階を通ります。確認するときは、テストする URL とポートを固定し、クライアントの「接続」画面またはログを見てください。ノード変更、DNS 設定変更、TUN の有効化を同時に行うと、どの変更が効いたのか判断できなくなります。

手順1：mihomo がローカルポートを待ち受けているか確認

mixed-port、port、socks-port の違い

mihomo の設定では、mixed-port は同じポートで HTTP と SOCKS のプロキシリクエストを受け付けます。port は HTTP プロキシの入口、socks-port は SOCKS の入口です。SOCKS 専用ポートに HTTP リクエストを送ると、プロトコルエラーや接続切断が起きることがあります。また、GUI クライアントがサブスクリプション内のポート設定を上書きする場合もあるため、実行中の設定を確認するのが確実です。

# mihomo のローカル接続設定例。サブスクリプション設定全体をそのまま置き換えないこと
mixed-port: 7890
allow-lan: false
mode: rule

同じ PC 上のブラウザーやターミナルを使う場合、allow-lan を有効にする必要はありません。これは LAN からの接続を制御する設定であり、ローカルアプリにシステムプロキシを使わせるものではありません。ローカル接続の確認には、IPv4 のループバックアドレス 127.0.0.1 を明示してください。localhost が ::1 に解決される一方で、mihomo が IPv4 だけで待ち受けている場合に起きる混乱を避けられます。

待ち受け状態を確認してから、プロキシを明示してリクエストを送る

# Windows PowerShell：7890 の待ち受け状態を確認
Get-NetTCPConnection -LocalPort 7890 -State Listen

# Linux：TCP の待ち受け状態を確認
ss -lntp 'sport = :7890'

# macOS：TCP の待ち受け状態とプロセスを確認
lsof -nP -iTCP:7890 -sTCP:LISTEN

使用している OS に合ったコマンドを1つ実行してください。待ち受けが確認できない場合は、クライアントの mihomo が起動しているか、設定の読み込みに失敗していないか、ポートがほかのプロセスに使われていないかを確認します。待ち受けがあっても、使用中のプロセスを確認してください。7890 を別のソフトが使用している可能性もあります。

# macOS / Linux
curl -q -v --noproxy "" --proxy http://127.0.0.1:7890 \
  --connect-timeout 7 --max-time 20 -I https://example.com/

# Windows PowerShell：curl.exe を明示して実行
curl.exe -q -v --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 7 --max-time 20 -I https://example.com/

-q を最初の引数に指定すると、既定の curl 設定ファイルを読み込みません。空の引数を渡せるシェルでは、--noproxy "" でプロキシを使わないホストの一覧を空にできます。--proxy は接続先のプロキシを明示します。古い Windows PowerShell では空文字列の引き渡し方に違いがあるため、プロキシが迂回される場合は、現在のセッションから一時的に NO_PROXY を削除して再試行してください。

Connected to 127.0.0.1 と表示されれば、ローカルプロキシの入口に接続できたことが分かります。HTTPS リクエストで続けて 200 Connection established と表示されれば、HTTP CONNECT トンネルが確立されています。その後に表示される接続先の応答と、mihomo の接続記録も確認してください。ここでは example.com をテストしています。この接続が成功しても、ほかのすべてのサイトに接続できるとは限りません。

手順2：ブラウザーのシステム設定と拡張機能を個別に確認

Chrome・Edge：まず拡張機能による設定の上書きを確認

1. Chrome では chrome://extensions/、Edge では edge://extensions/ を開き、プロキシ、PAC、ネットワーク切り替えを管理する拡張機能を一時的にすべて無効にします。
2. Chrome では「設定」→「システム」→「パソコンのプロキシ設定を開く」に進みます。Edge では「設定」→「システムとパフォーマンス」→「システム」からプロキシ設定を開きます。バージョンによって表示名や項目の分類が異なる場合があります。
3. システムのプロキシ設定で、アドレス、ポート、プロキシを使用しないアドレスの一覧を確認します。PAC を使用している場合は、現在有効なのが PAC か手動プロキシかも確認してください。設定画面のスイッチだけで実際の通信経路を判断しないでください。
4. ブラウザーを完全に終了してから再起動し、テストする URL にアクセスしながら、クライアントの接続記録を確認します。

Windows 11 では「設定」→「ネットワークとインターネット」→「プロキシ」から確認できます。macOS では「システム設定」→「ネットワーク」→現在のネットワークサービス→「詳細」→「プロキシ」に進みます。手動 HTTP プロキシと保護された Web プロキシ（HTTPS）は別の項目になっている場合があります。HTTPS サイトをテストするときは、対応する設定も確認してください。

設定画面に「拡張機能または組織によって管理されています」と表示される場合は、まず管理元を確認してください。企業ポリシーやブラウザーの起動オプションが通常の設定を上書きすることがあります。Clash のシステムプロキシを何度も切り替えても、この上書きは解消されません。シークレットウィンドウも確実な切り分け方法ではありません。シークレットモードでの実行を許可された拡張機能があるためです。

Firefox：独自のプロキシ設定を確認

デスクトップ版 Firefox では「設定」→「一般」→ページ下部の「ネットワーク設定」→「接続設定」に進みます。「システムのプロキシ設定を使用する」を選ぶと OS のプロキシ設定を使います。「手動でプロキシを設定する」または「自動プロキシ設定 URL」を選んでいる場合は、ブラウザー独自の設定が使われます。

• 手動 HTTP プロキシ：アドレスに 127.0.0.1、ポートに実際の HTTP ポートまたは混合ポートを指定し、HTTPS プロキシの項目も確認してください。
• 手動 SOCKS：SOCKS v5 を選び、SOCKS ポートまたは混合ポートを指定します。接続先のドメイン名をプロキシ側で解決する場合は、SOCKS v5 の DNS プロキシ設定を確認してください。
• 「プロキシを使用しないアドレス」一覧：テストするドメインやそのサブドメインが含まれていないか確認します。プロキシの迂回設定をクライアントの不具合と誤認しないようにしてください。

手順3：ターミナルに現在のセッション用プロキシ変数を設定

ターミナル自体がプロキシ経由で通信するわけではなく、通信を開始するのはターミナル内で実行するプログラムです。多くのコマンドラインツールは、デスクトップのシステムプロキシを自動では参照しません。プロキシを明示したテストは成功するのに通常のコマンドが失敗する場合は、すぐにノードを変えるのではなく、ツールが対応する環境変数を設定してください。

macOS・Linux：まず export で一時設定

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 7 --max-time 20 -I https://example.com/

https_proxy という変数名は、HTTPS の接続先に使うことを示すもので、変数の値を https:// にする必要はありません。Clash の一般的なローカル HTTP プロキシは HTTP CONNECT で HTTPS 通信を中継するため、ここでは http://127.0.0.1:7890 と指定します。安易に https:// に変えると、ツールがローカルプロキシとの TLS 接続を試み、待ち受け側が対応していない場合に失敗します。

これらの変数は、現在のシェルと、そこから起動する子プロセスにだけ適用されます。動作を確認してから、使用しているシェルに合わせて ~/.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 7 --max-time 20 -I https://example.com/

Windows PowerShell 5.1 では、curl が Invoke-WebRequest のエイリアスになっている場合があります。curl.exe を使えば curl を明示的に実行でき、2つのツールの引数やプロキシの動作を混同せずに済みます。セッション環境変数は、すでに起動しているプログラムには反映されません。現在の環境が引き継がれるのは、新しく起動したプロセスです。

SOCKS を使う場合は、DNS の解決場所を明示

curl -q -v --noproxy "" --proxy socks5h://127.0.0.1:7890 \
  --connect-timeout 7 --max-time 20 -I https://example.com/

curl では、通常 socks5:// は接続先のドメイン名をローカルで解決し、socks5h:// はドメイン名の解決を SOCKS プロキシに任せます。この違いは DNS の問題を切り分けるのに役立ちますが、ほかのツールが同じ URL 形式に対応しているとは限りません。ALL_PROXY を設定する前にツールのドキュメントを確認してください。すべてのプログラムで有効とは限りません。

手順4：NO_PROXY とツール独自の設定を確認

環境変数が正しいのに直接接続される場合、プロキシを迂回する一覧やツール独自の設定が原因として考えられます。NO_PROXY と no_proxy は、プロキシを経由しないホストを指定する変数です。大文字・小文字、ドメインのサフィックス、CIDR 表記への対応はツールによって異なります。特に * が設定されていないか確認してください。多くのツールでは、すべての接続先をプロキシから迂回する指定になります。

# macOS / Linux：プロキシ環境変数をローカルで確認
env | grep -i proxy

# Windows PowerShell
Get-ChildItem Env: | Where-Object Name -Match 'proxy'

# システム、グローバル、現在のリポジトリの Git 設定を確認
git config --show-origin --get-regexp '.*proxy.*'

Git の http.proxy や URL ごとのプロキシ設定、パッケージ管理ツール独自のプロキシ設定によって、同じターミナルから実行したコマンドでも通信経路が異なる場合があります。Git が古い 127.0.0.1:7891 を参照し、現在のクライアントが 7890 でしか待ち受けていないと、curl は成功するのに Git は失敗することがあります。

• Git：--show-origin で設定ファイルと適用範囲を確認し、誤りを特定した項目だけを修正します。リポジトリ単位の設定がグローバル設定より優先される場合があります。
• npm：npm config get proxy と npm config get https-proxy で独自のプロキシ設定を確認し、プロジェクト内の .npmrc も調べます。
• WSL とコンテナ：その中の 127.0.0.1 は、それぞれのネットワーク環境を指すのが一般的です。Windows やホストマシンと同じだと決めつけないでください。WSL のネットワークモードやコンテナのネットワーク設定によって、接続経路は変わります。

仮想マシンやコンテナからホストのプロキシに接続する必要がある場合は、ホスト側の到達可能なアドレス、クライアントの待ち受け範囲、ファイアウォールルールを確認してください。必要なローカルネットワークだけに公開し、調査のためにプロキシポートをインターネットへ開放しないでください。

手順5：接続できる場合は、ルール、DNS、TUN を確認

接続記録はあるのに、想定したノードが使われない

まずクライアントの接続詳細でテスト対象のドメインを探し、適用されたルールとポリシーの経路を確認します。ルールモードで DIRECT と表示される場合、ルールに従って直接接続を選んだことを示します。アプリが mihomo を迂回したという意味ではありません。プロキシグループで DIRECT が選択されている場合や、接続先に DIRECT ルールが適用されている場合、システムプロキシを有効にするだけでは結果は変わりません。

元の設定を記録してから、短時間だけグローバルモードに切り替え、接続可能と分かっているプロキシ出口を明示的に選んで同じ URL を再テストできます。グローバルモードでは成功し、ルールモードでは失敗する場合は、ルールの優先順位、ドメインの一致条件、プロキシグループの選択を確認し、テスト後に元のモードへ戻してください。グローバルモードでのテスト結果を、そのまま常用設定の推奨にしないでください。

エラーが発生した段階から原因を絞り込む

TUN モードが必要になるケース

TUN は仮想ネットワークインターフェースとルーティングを使い、対象の通信を取り込みます。プロキシを設定できず、システムプロキシも参照しないプログラムに適しています。ポートの誤設定や接続できないノードを直す代わりにはなりません。また、TUN を有効にしても、すべての接続がリモートノードを経由するとは限らず、最終的な出口はルールによって決まります。

curl に環境変数が設定されていないだけなら、まず変数を修正するほうが簡単に確認できます。TUN が本当に必要な場合は、クライアントの案内に従ってサービスをインストールするか管理者権限を付与し、ルーティングと DNS を確認してください。ほかの VPN との競合にも注意が必要です。システムプロキシと TUN の違いを調べるときは、通信を取り込む入口を一度に1つだけ変更し、2つの経路が同時に有効になって原因が分からなくなるのを防ぎます。

設定を戻して最終確認

最終確認では、ブラウザー、プロキシを明示した curl、通常の curl の3つをテストし、同じ接続先の接続記録を確認します。ブラウザーは成功するのに通常の curl が失敗する場合は、引き続きターミナルの設定を調べます。プロキシを明示した curl も失敗する場合は、待ち受け状態と mihomo のログに戻って確認してください。クライアントのスイッチの色やノードの遅延だけで解決と判断しないでください。

1. 使用したポート、プロキシの入口の種類、有効になった設定の適用元を記録します。例：「混合ポート 7890、PowerShell の現在のセッション環境変数」。
2. 一時的に無効にした必要な拡張機能を1つずつ有効にして再テストします。問題が再発した時点で、競合している拡張機能を特定できます。
3. 調査中に追加したグローバルモード、範囲の広い迂回設定、重複したプロキシ変数を削除し、次回起動時に異なる結果になるのを防ぎます。

# macOS / Linux：今回一時的に設定した変数だけを削除
unset http_proxy https_proxy all_proxy no_proxy

# Windows PowerShell：今回のセッションで一時設定した項目を削除
Remove-Item Env:http_proxy, Env:https_proxy, Env:all_proxy, Env:no_proxy -ErrorAction SilentlyContinue

削除コマンドでは、起動ファイルやツールの設定に保存された値は元に戻りません。設定ファイルに書き込んだ場合は、そのファイルも編集してください。クライアントを終了した後、システムプロキシ設定が元に戻っているか確認します。終了したクライアントのローカルポートをシステムが参照し続けないようにしてください。