トラブル対処 読了時間：約12分

Clashのシステムプロキシが効かないときの対処法｜ブラウザーとターミナルの設定

Clashのシステムプロキシが効かない原因を、ブラウザーとターミナルに分けて解説。拡張機能やPAC、例外設定の確認方法と、各OSでのプロキシ環境変数の設定方法を紹介します。

まずシステムプロキシ・ルールモード・TUNを区別する

クライアントで「システムプロキシ」を有効にすると、通常はOSのHTTP・HTTPSプロキシの接続先がローカルの待ち受けポートに設定されます。この設定を参照するかどうかはアプリごとに異なります。ブラウザーはシステム設定に従うことがありますが、ターミナルのcurlやGit、パッケージ管理ツールは環境変数や独自設定を使う場合があります。そのため、「Webページは開けるのにターミナルはタイムアウトする」からといって、ノードの障害とは限りません。

Clashまたはmihomoコアの「ルールモード」は、コアに入った接続をルールに従って振り分けます。「グローバルモード」では通常、それらの接続をグローバルプロキシグループに送ります。どちらも、すべてのプロセスを自動的にコアへ通す機能ではありません。TUNは仮想ネットワークインターフェースとルーティングで通信を取り込む別の経路です。ルーティング、DNS、プロセス除外、ルールの影響を受けます。

症状まず確認する項目判断の目安
ブラウザーもターミナルも失敗するコア、待ち受けポート、設定の有効化状態プロキシを明示したcurlでローカルポートに接続できるか
ブラウザーは正常で、ターミナルは失敗する環境変数とツールの設定同じターミナルでプロキシを明示すると成功するか
ターミナルは正常で、ブラウザーは失敗するプロキシ拡張機能、PAC、例外リストブラウザーのリクエストが接続パネルに表示されるか
リクエストはコアに入るが、直接接続される一致したルールとプロキシグループの選択状態接続履歴にDIRECTと表示されるか

基準を確認する：ローカルポートとプロキシ指定リクエスト

クライアントの実際の待ち受けポートを確認する

クライアント設定のポートまたはインバウンド設定を開き、HTTP、SOCKS、Mixedの各ポートと、現在動作しているコアを確認します。メニュー名はクライアントによって異なるため、実際の画面と実行中の設定を確認してください。以下ではMixedポートの例として127.0.0.1:7890を使います。7890がすべてのクライアントで共通のポートというわけではありません。コントローラー用ポートをプロキシポートと混同しないでください。external-controllerが提供するのは管理APIです。

# ポートの意味を説明するための例です。サブスクリプション設定全体を上書きしないでください
mixed-port: 7890
allow-lan: false
mode: rule

MixedポートはHTTPとSOCKSの両方のプロキシ接続を受け付けます。設定がport: 7890のみの場合は、HTTPプロキシとして使用します。socks-port: 7891のみの場合は、対応するSOCKSアドレスを指定してください。ローカルでの利用だけなら、トラブルシューティングのためにLANアクセスを有効にする必要はありません。プロキシの待ち受けポートをインターネットに公開しないでください。

1回のリクエストで「接続経路の問題」と「接続先側の問題」を切り分ける

macOSまたはLinuxのターミナルで、以下のcurlコマンドを実行します。Windows PowerShellではcurlをcurl.exeに置き換え、旧バージョンのPowerShellにある同名エイリアスによる引数の誤解析を防いでください。テスト中はTUNを一時的に無効にし、起動するクライアントを1つに絞って、複数の接続経路が混在する影響を避けます。

curl -I -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/
  • Connection refused：ポートの指定ミス、コアが起動していない、または指定アドレスで待ち受けていない場合によく発生します。
  • ローカルポートには接続できるが、CONNECTに失敗する、または502が返る場合は、クライアントのログ、ノードへの接続状況、適用されたプロキシグループを確認してください。
  • 200 Connection establishedが表示されても、HTTPトンネルが確立したことを示すだけです。続けてTLSハンドシェイクと接続先サイトの応答を確認してください。
  • 接続先サイトからHTTPレスポンスが返れば、この明示的なプロキシリクエストが成功したことを確認できます。ただし、ほかのアプリの設定も正しいとは限りません。

ブラウザーがプロキシを経由しないとき：システム設定、拡張機能、PACの順に確認

システム設定が正しく反映されているか確認する

Windows 11では、「設定」→「ネットワークとインターネット」→「プロキシ」を開きます。クライアントが手動プロキシを使う場合は、ローカルアドレスと実際のポートが設定されていることを確認してください。自動構成スクリプトを使う場合は、スクリプトのアドレスが現在も有効か確認します。PACのアドレスを手動プロキシのサーバー欄に入力しないでください。別の種類の設定です。

macOS 14では、「システム設定」→「ネットワーク」→現在使用中のネットワークサービス→「詳細」→「プロキシ」を開きます。未接続のEthernetではなく、Wi-Fiなど現在使っているネットワークを変更していることを確認してください。HTTPプロキシとHTTPSプロキシには、通常、クライアントのHTTPまたはMixed待ち受けポートを指定します。接続先がHTTPSでも、ローカルのプロキシアドレスをHTTPSにする必要はありません。

Linuxのデスクトップ環境では、プロキシ設定の場所が環境によって異なります。GNOMEでは「設定」→「ネットワーク」→「ネットワークプロキシ」で確認できます。デスクトップのプロキシ設定を、サンドボックスアプリ、バックグラウンドサービス、コマンドラインツールがすべて読み込むとは限りません。後述の手順でターミナルも個別に確認してください。

ブラウザーで使うプロキシ設定元を1つに絞る

  1. Chromeではchrome://extensions/、Edgeではedge://extensions/を開き、プロキシを管理する拡張機能を一時的に無効にします。その後、ブラウザーを完全に終了してから再起動してください。
  2. Firefoxでは「設定」→「一般」→「ネットワーク設定」→「接続設定」を開き、「プロキシーを使用しない」「システムのプロキシー設定を使用する」「手動でプロキシーを設定する」のどれが選択されているか確認します。トラブルシューティング中は、まずシステム設定に合わせてください。
  3. 組織で管理されているブラウザーでは、chrome://policy/またはedge://policy/も確認してください。ポリシーでプロキシが強制されている場合、クライアントでシステム設定を切り替えてもブラウザーの動作が変わらないことがあります。
  4. 同じテスト用URLに再度アクセスし、クライアントの接続パネルで接続先ドメイン、適用ルール、プロキシ経路、通信が表示されるか確認します。

シークレットウィンドウは、プロキシ設定を切り分ける確実な方法ではありません。拡張機能によってはシークレットモードでも動作し、システムプロキシも引き継がれます。必要に応じて一時的なブラウザープロファイルで比較してください。普段使っている設定をいきなり削除しないでください。

PACとプロキシの例外設定を確認する

PACスクリプトは、ドメインごとにプロキシアドレスまたはDIRECTを返します。スクリプトが特定のドメインを直接接続に指定すると、そのリクエストはコアを経由しないため、Clashのルールを変更しても動作は変わりません。まず現在の設定を保存し、手動プロキシを明示的に指定して一時的に比較してください。提供元が不明なPACやプロキシ拡張機能を複数併用しないでください。

システムやブラウザーの例外リストに登録された宛先も、プロキシを経由しません。テスト対象のドメイン、ワイルドカード指定、LANアドレス、「ローカルアドレスにはプロキシを使用しない」といった設定を確認してください。localhostへのアクセスでは、インターネット向けのプロキシが有効かどうかを判断できません。ループバックアドレスには通常、専用のバイパス処理があるためです。

Windowsのターミナル：PowerShellとCMDの設定

PowerShell、CMD、アプリ内蔵ターミナルが同じプロキシ設定を使うとは限りません。以下の環境変数が影響するのは、現在のプロセスと、その後に起動する子プロセスです。起動済みのターミナル、エディター、バックグラウンドタスクには自動で反映されません。まず一時的な設定でテストし、動作を確認してから永続化を検討してください。

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

# 現在のプロキシ関連環境変数を確認
Get-ChildItem Env: | Where-Object Name -Match 'proxy'

# テスト後に今回の設定を解除
Remove-Item Env:http_proxy, Env:https_proxy, Env:no_proxy -ErrorAction SilentlyContinue

CMDの現在のウィンドウ

set "http_proxy=http://127.0.0.1:7890"
set "https_proxy=http://127.0.0.1:7890"
set "no_proxy=localhost,127.0.0.1,::1"
curl.exe -I --connect-timeout 10 --max-time 20 https://example.com/

rem テスト後に設定を解除
set "http_proxy="
set "https_proxy="
set "no_proxy="

https_proxyはHTTPSリクエストで使用するプロキシを指定する変数であり、プロキシへの接続自体にTLSを要求するものではありません。この例ではローカルのHTTPプロキシにCONNECTメソッドでトンネルを確立するため、値はhttp://127.0.0.1:7890です。

macOS・Linux：環境変数、SOCKS、設定の永続化

まず現在のシェルでテストする

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

# 大文字・小文字の両方を確認し、以前の設定の影響を除外
env | grep -i proxy

# 今回の設定を解除
unset http_proxy https_proxy no_proxy

環境変数の大文字・小文字をどう扱うかは、プログラムによって異なります。curlはHTTPプロキシに小文字のhttp_proxyを使うため、大文字のHTTP_PROXYだけを設定して、プロキシが動作しないと判断しないでください。以前の設定としてALL_PROXY、HTTPS_PROXYや大文字・小文字の異なる変数が残っている場合は、値を記録してから競合する項目を解除します。no_proxyのドメイン照合方法もツールごとに異なるため、複雑なリストをそのまま複数のツールに使い回すのは避けてください。

DNSの名前解決をプロキシ側で行う場合は、SOCKSで確認する

# 7890がMixedまたはSOCKSポートであることを確認してから使用
curl -I --connect-timeout 10 --max-time 20 --noproxy "" --proxy socks5h://127.0.0.1:7890 https://example.com/

curlでは、socks5h://を使うと接続先ホスト名がプロキシ側で名前解決されます。socks5://では、既定でローカル側が名前解決します。この違いはローカルDNSの問題を切り分けるのに役立ちますが、すべてのプログラムが同じURL形式に対応しているとは限りません。SOCKS環境変数に対応していないツールでは、そのツールが明示的にサポートするHTTPプロキシ設定を使ってください。

動作を確認できたら、使用中のシェルに応じて必要なexport行を~/.zshrcまたは~/.bashrcに追加し、新しいターミナルで再確認します。ログインシェル、デスクトップから起動したアプリ、systemdサービスでは、環境変数の読み込み方法が異なります。ファイルを1つ変更すればすべてのプロセスに反映されるとは限りません。sudoでコマンドを実行すると、環境変数が引き継がれない場合もあります。

WSL、コンテナ、仮想マシン内の127.0.0.1は、通常それぞれのネットワーク環境を指し、ホストマシンとは限りません。WSLではネットワークモードによってループバックへの接続可否が変わります。接続できない場合は、まずホストのアドレスと到達可能なポートを確認してください。環境をまたいで接続する必要がある場合は、信頼できるネットワークに限って必要な待ち受けを公開し、ファイアウォールを設定してください。すべてのネットワークに公開しないでください。

コマンドが失敗する場合：ツールの設定、ルール、DNSを確認する

Gitなどのツールが環境変数の設定を上書きする場合がある

Gitでは、グローバル設定、リポジトリ設定、URLごとのプロキシ設定によって結果が異なることがあります。まず設定の適用元を確認し、設定を変更したまま戻し忘れないよう、単発のコマンドで上書きしてテストしてください。以下のテストでは公開リポジトリを使うため、コマンドにアカウントやパスワードを含める必要はありません。

git config --show-origin --get-regexp '.*proxy'
git -c http.proxy=http://127.0.0.1:7890 ls-remote https://github.com/git/git.git HEAD

パッケージ管理ツール、IDE、ダウンロードツールにも独自の設定がある場合があります。ブラウザーで成功しても、ブラウザーの接続経路が使えることを確認できただけで、ツールごとの接続テストの代わりにはなりません。ログを共有する際は、サブスクリプションURL、アクセストークン、アカウント情報、認証情報を含むプロキシアドレスを伏せてください。

コアに接続が届いたらルールを確認する

接続パネルに対象のリクエストが表示されている場合は、最終的なプロキシ経路を確認します。DIRECTと表示される場合は、一致したルールと、プロキシグループが現在直接接続を選択していないかを確認してください。具体的なノードが表示される場合は、そのノードから接続先サイトへの到達性を確認します。サブスクリプションのインポートに成功しても、設定が有効になっている、または各プロキシグループで利用可能なノードが選ばれているとは限りません。

一時的にグローバルモードへ切り替え、動作確認済みのノードを1つ選んで比較できます。グローバルモードでは使えるのにルールモードで失敗する場合は、ルールの照合とグループの選択を優先して確認してください。テスト後は元のモードに戻します。グローバルモードで処理できるのもコアに入った接続だけです。ブラウザーがプロキシ設定を読み込んでいない、またはターミナルに接続先が設定されていない問題は解決できません。

エラーがドメイン名の名前解決を示している場合は、まず名前解決を行っている場所を特定します。アプリ、ローカルシステム、HTTPプロキシ、SOCKSプロキシのどこで解決しているかを確認してください。ブラウザーのセキュアDNS設定によって名前解決の経路が変わることはありますが、ブラウザーのプロキシ障害がすべてそれに起因するわけではありません。最初からDNS設定を消去したりFake-IPの範囲を変更したりすると、複数の条件が同時に変わるため避けてください。

TUNを使うケースと、再テストの手順

明示的なプロキシ設定に対応していないアプリでは、TUN機能を備えたmihomoクライアントの利用を検討できます。有効化する前に、クライアントのバージョンとコアの対応状況、必要な権限、既存のVPNルートを確認してください。TUNは管理者権限が必要な場合があり、ほかの仮想ネットワークインターフェース、ルート、DNS制御と競合することもあります。ポートを確認する前に試す、万能な修復手段ではありません。

  1. まずTUNを無効にし、ローカルプロキシを明示したリクエストが成功することを確認します。ノードと待ち受け経路が正常か確認してください。
  2. ブラウザーのシステムプロキシ設定を戻し、ブラウザー単独でテストします。クライアントの接続履歴にドメインと適用ルールが表示されることも確認してください。
  3. 新しいターミナルセッションでプロキシ環境変数をテストし、ツール独自の設定と例外リストも確認します。
  4. プロキシに対応していないアプリが実際にある場合に限り、TUNを有効にします。デフォルトルート、DNS、アプリの接続状況の変化を確認してください。
  5. クライアントを終了した後、ネットワークが元に戻るか確認します。停止したローカルポートが参照されたままの場合は、残っているシステムプロキシ設定を無効にするか、現在のセッションの環境変数を解除してください。

トラブルシューティングの記録には、OSのバージョン、クライアントとコアのバージョン、待ち受けポート、テストコマンド、エラーの全文、接続パネルに表示されたルールの判定結果を残してください。「アプリの接続設定 → ローカルの待ち受け → ルールとプロキシグループ → ノードからの接続 → 接続先サイト」の順に切り分けると、クライアントを何度も再インストールするより原因を特定しやすくなります。基本操作はクイックスタート、各項目の意味はプロトコルリファレンス、よくある質問はヘルプセンターをご覧ください。

クライアントをダウンロード