トラブル対処 読了目安 12分

Clashのシステムプロキシが効かないときの対処法：ブラウザーとターミナルを分けて検証

システムプロキシを有効にしても通信がプロキシを経由しない？ブラウザーとターミナルでは仕組みが異なります。ブラウザーはプロキシ設定と拡張機能、ターミナルは環境変数とプロキシポートを確認し、問題の箇所を切り分けます。

まず問題が発生している層を確認する

「システムプロキシが有効」という表示は、クライアントが HTTP と HTTPS のプロキシアドレスをOSの設定に書き込もうとしたことを示すだけで、すべてのプログラムがその設定を読み取るとは限りません。ChromeやEdgeなどのブラウザーは通常システムプロキシに従いますが、Firefoxはシステム設定を使うことも、独自のプロキシ設定を保持することもできます。一方、ターミナルのGit、curl、npm、Python、コンテナーツールはシステムプロキシを迂回し、環境変数や個別の設定ファイルを参照することがよくあります。

トラブル対処では、いきなりノードを変更したり、クライアントを再インストールしたり、サブスクリプションを何度も読み込んだりしないでください。まず経路を4段階に分けます。Clashのコアが動作しているか、リスニングポートが存在するか、対象プログラムが接続をそのポートへ渡しているか、Clashに入った接続がどのルールに一致したかを確認します。層ごとに検証すれば、原因がクライアント、OS、アプリケーション、ルール設定のどこにあるか判断できます。

確認できる結果 優先して確認する項目 よくある原因
ブラウザーもターミナルもプロキシを使えない コア、ポート、設定状態 コアが起動していない、ポートの競合、設定の読み込み失敗
ブラウザーは正常だが、ターミナルは直結する ターミナルの環境変数とツール設定 コマンドラインプログラムがシステムプロキシを読み取らない
ターミナルでプロキシを明示すると正常だが、ブラウザーは直結する システムプロキシとブラウザー設定 システムプロキシが書き込まれていない、拡張機能による上書き、ブラウザーが独自設定を使用
リクエストはログに出るが、Webサイトを開けない ルール、ノード、DNS、証明書のエラー REJECTに一致している、ノードが利用できない、ドメイン解決に異常がある
通常のプログラムは正常だが、ゲームやUWPアプリで問題が起きる TUN、ループバック制限、UDP対応 プログラムがHTTPプロキシを使わない、またはUDP転送が必要

実際のポートを記録し、7890を決め打ちしない

多くの設定では7890をmixed-portに使用しますが、必須の値ではありません。クライアントによってHTTP、SOCKS5、混合ポートの表示が異なり、設定ファイルで上書きされることもあります。クライアントの「設定」→「ポート設定」または「設定」→「Clash設定」を開き、現在リスニングしているアドレスとポートを記録してください。画面に混合ポートとして7890と表示されている場合に限り、後続のコマンドでその値を使います。

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

mixed-portはHTTPとSOCKS5の接続を同時に受け付けます。設定でport: 7890とsocks-port: 7891を個別に指定している場合、テストコマンドもプロトコルに合わせる必要があります。SOCKS5リクエストをHTTP専用ポートへ送ると、「ポート種別が違います」と明確に表示されるのではなく、接続リセットやプロキシハンドシェイク失敗になることがよくあります。

ブラウザー経路：システムプロキシと拡張機能の上書きを確認

手順1：OSのプロキシアドレスを確認する

Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」を開き、「プロキシサーバーを使う」が有効か確認します。アドレスは通常127.0.0.1で、ポートはClashの現在のHTTPまたは混合ポートと一致している必要があります。クライアントではシステムプロキシが有効なのにWindows側が古いポートのままなら、まずクライアントのシステムプロキシを無効にし、もう一度有効にしてください。

macOSでは「システム設定」→「ネットワーク」→現在のネットワークインターフェース→「詳細」→「プロキシ」を開きます。一般的な設定では「Webプロキシ（HTTP）」と「セキュアWebプロキシ（HTTPS）」の両方を選択し、サーバーに127.0.0.1、ポートにクライアントに表示されるHTTPまたはmixedポートを入力します。SOCKSプロキシだけを設定した場合、それを使うかどうかはアプリケーションの実装に左右されます。

システムプロキシにノードサーバーのアドレスを入力してはいけません。OS設定で指定するのは、127.0.0.1:7890のようなローカルClashリスニングアドレスです。ノードのアドレス、認証情報、通信パラメーターはClashの設定で処理されます。リモートノードのポートをシステムプロキシへ直接入力しても、通常は必要なプロトコルのハンドシェイクを完了できません。

手順2：ブラウザー独自のプロキシ設定と拡張機能の競合を切り分ける

ChromeとEdgeは標準でシステムプロキシを読み取りますが、プロキシ切り替え拡張機能がこの経路を上書きすることがあります。まずシークレットウィンドウでテストしてください。拡張機能がシークレットモードで動作する設定なら、拡張機能の管理画面でプロキシ関連の拡張機能を一時的に無効にします。SwitchyOmega系の代替拡張機能、企業ポリシーによるプロキシ、パケットキャプチャーツール、デバッグプロキシを重点的に確認します。複数のツールが同時にプロキシを制御している場合、最後に書き込んだ設定または優先度の高い設定が実際の出口を決めます。

Firefoxでは「設定」→「一般」→「ネットワーク設定」→「設定」を個別に確認します。Clashが書き込んだシステム値に従うには「システムのプロキシ設定を使用する」を選択します。「手動でプロキシを設定する」を選んだ場合は、現在のローカルポートを入力してください。「プロキシなし」では直接接続します。Firefoxの「このネットワークのプロキシ設定を自動検出する」も、システムプロキシに従う設定とは異なります。

手順3：ログでブラウザーのリクエストがClashに入ったか確認する

  1. クライアントの「ログ」ページを開き、ログレベルをinfoに設定します。
  2. ブラウザーで自動更新中のページを閉じ、バックグラウンドリクエストの影響を減らします。
  3. 新しいタブを開き、これまで開いたことのないHTTPSサイトへアクセスします。
  4. ログでそのドメインを検索し、接続元、適用されたルール、最終的なポリシーを確認します。

ログにそのドメインがまったく表示されない場合、問題はブラウザーからローカルポートまでの間にあります。システムプロキシ、ブラウザーのポリシー、拡張機能を引き続き確認してください。ログにMATCH、DOMAIN-SUFFIXなどのルールと、プロキシグループまたはDIRECTが表示されるなら、ブラウザーはすでにリクエストをClashへ渡しています。次にルールの選択とノードの状態を確認します。

ブラウザーに表示されたキャッシュページだけでは、現在プロキシが有効だとは証明できません。開発者ツールの「ネットワーク」パネルで「キャッシュを無効化」をオンにしてから、ハードリロードを実行してください。Clashの「接続」ページも同時に確認できます。新しい接続には、対象ドメイン、ネットワーク種別、アップロード・ダウンロード通信量、適用された経路が表示されます。

ターミナル経路：プロキシを明示してポートを検証する

ターミナルプログラムの挙動をブラウザーの結果から推測することはできません。最も確実なのは、まず1つのコマンドでプロキシを明示する方法です。明示的なプロキシ指定で成功したら、環境変数またはツール固有のパラメーターを設定します。明示指定でも失敗する場合は、ローカルポート、コアの状態、ファイアウォールの確認に戻ります。

curlでHTTPプロキシを直接テストする

Windows PowerShell 5.1では、curlがInvoke-WebRequestのエイリアスになっている場合があるため、curl.exeを明示的に実行します。新しいWindows 10とWindows 11には通常curlが標準搭載されています。mixed-portが7890だと仮定して、次を実行します。

curl.exe -v -x http://127.0.0.1:7890 https://example.com/

macOS、Linux、Git Bash、または独立したcurlをインストール済みの環境では、次を実行します。

curl -v -x http://127.0.0.1:7890 https://example.com/

詳細出力にConnected to 127.0.0.1と、HTTPSの対象へ送信されたCONNECTリクエストが表示されれば、curlはローカルプロキシに接続できています。その後にHTTPステータスコードが返り、Clashのログに対象ドメインが表示されれば、プロキシ経路は成立しています。すぐにConnection refusedが表示される場合、そのポートで待ち受けていないか、ポート番号が間違っています。

SOCKS5を使い、ドメイン解決をClashに任せる

SOCKS5のテストにはsocks5hを使うのがおすすめです。末尾のhはドメイン名の解決をプロキシに任せることを示し、ローカルDNSの結果がテストへ影響するのを防ぎます。ポートにはSOCKSポートまたはmixed-portを指定します。

curl -v --proxy socks5h://127.0.0.1:7890 https://example.com/

socks5://とsocks5h://の主な違いは、ドメイン名を解決する場所です。前者は通常ローカルで名前解決してからIPアドレスをプロキシへ渡します。後者はドメイン名をSOCKSリクエストに含めます。ドメイン汚染、ドメイン名に依存するルーティング、ローカルDNSの不安定さを調べる場合は、まずsocks5hを使ってください。

現在のターミナルセッションに環境変数を設定する

PowerShellでは、現在のウィンドウだけにプロキシを設定できます。ウィンドウを閉じると変数は無効になるため、トラブル対処に適しています。

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
curl.exe -v https://example.com/

macOS、Linux、WSL、Git Bashでは、プログラムによって参照する変数名が完全には一致しないため、大文字と小文字の両方を設定します。

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
curl -v https://example.com/

NO_PROXYとno_proxyも確認してください。対象ドメイン、ドメインサフィックス、またはワイルドカード範囲が除外リストに含まれていると、プログラムは意図的にプロキシを迂回します。次の設定ではローカルアドレスだけを直接接続にします。

export NO_PROXY=localhost,127.0.0.1,::1
export no_proxy=localhost,127.0.0.1,::1

Git、npm、Pythonはそれぞれプロキシを保持することがある

Gitは環境変数を読み取るほか、グローバル設定に古いポートを保持している場合があります。まず現在の設定元を確認してから、変更するか判断します。

git config --global --get http.proxy
git config --global --get https.proxy
git config --show-origin --get-regexp "http\..*proxy"

Gitにローカルプロキシを明示的に設定する場合は、次を使用します。

git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

npmではnpm config get proxyとnpm config get https-proxyで設定を確認できます。PythonのpipはHTTPS_PROXYを読み取ることも、1回限りの引数でテストすることもできます。

python -m pip install --proxy http://127.0.0.1:7890 パッケージ名

ツール設定に残った古いポートは、判断を誤らせやすい要因です。ブラウザーは新しい7890へ切り替わっているのに、Gitは以前の7897へ接続していることがあります。Clashのリスニングポートを変更するたびに、環境変数、Git設定、npm設定、IDEのターミナル、コンテナー環境を再確認してください。

コアとポートが実際に待ち受けているか確認する

Windowsでリスニングプロセスを確認する

PowerShellまたはコマンドプロンプトで次のコマンドを実行し、7890がLISTENING状態か確認します。

netstat -ano | findstr :7890

出力の末尾にプロセスPIDが表示されます。続けてプロセス名を確認できます。

tasklist /FI "PID eq プロセス番号"

そのポートを使用しているのが現在のClashクライアントでなければ、リスニングポートを変更するか、競合しているプロセスを終了します。何も出力されない場合は、クライアントのコアの状態と設定エラーを確認してください。設定の解析に失敗していると、画面は開いたままでも、プロキシポートが期待どおりに作成されないことがあります。

macOSとLinuxでリスニングアドレスを確認する

lsof -nP -iTCP:7890 -sTCP:LISTEN

Linuxでは次のコマンドも使用できます。

ss -lntp | grep 7890

127.0.0.1:7890で待ち受けている場合、アクセスできるのはローカルプログラムだけです。これはデスクトップ利用では一般的な設定です。LAN上の他のデバイスからこのポートへ接続するには、クライアントで「LAN内接続を許可」を有効にし、設定のallow-lanをtrueにして、リスニングアドレスとOSのファイアウォールが対象ネットワークからのアクセスを許可していることを確認します。ローカルブラウザーの問題を調べるためだけに、LAN向けリスニングへ変更しないでください。

ログに接続が表示されたら、次にルールを確認する

Clashのルールは通常、上から順に照合され、最初に一致したルールが適用されます。ドメインはDOMAIN、DOMAIN-SUFFIX、またはルールセットに先に一致することがあります。前のルールに一致しなかった場合だけ、最後のMATCHへ進みます。テストリクエストがREJECTに一致すると接続は明示的に拒否され、DIRECTに一致するとローカルネットワークから直接アクセスします。

グローバルモードに切り替えて正常に戻るなら、通常はポート、システムプロキシ、ノード経路は成立しており、問題はルールまたはポリシーグループに絞られます。ログに表示されたルール名とポリシーグループを記録し、そのグループで利用可能なノードが選択されているか確認してください。ルールの問題を隠すために、グローバルモードを常用しないでください。LANアドレス、ソフトウェア更新、ローカルサービスまで不要にプロキシへ送られる可能性があります。

システムプロキシで解決できないプログラム：TUNが必要か判断する

システムプロキシが主に対象とするのは、HTTPまたはSOCKSプロキシに対応したアプリケーションです。一部のゲーム、コマンドラインプログラム、ストアアプリ、仮想マシン、コンテナー、自前のネットワークスタックを使うソフトウェアはシステム設定を読み取りません。そのため、ブラウザーが完全に正常でも、これらのプログラムは直接接続することがあります。

TUNモードは仮想ネットワークインターフェースを通じてより多くのIPトラフィックを取り込み、mihomoなどの対応コアへ渡します。個別にプロキシを設定できないアプリ、UDPが必要な場面、アプリケーションの接続をまとめて制御したい場合に適しています。TUNは「システムプロキシの強化スイッチ」ではなく、システム権限、ルーティング、DNSのリダイレクト方式、仮想NICの状態に依存します。

TUNを有効にする前に3項目を確認する

有効化後は、クライアントのログにTUNインターフェースの作成成功を示す情報が出るか確認し、対象プログラムの接続がClashに入るかを観察します。Windowsで特定のUWPアプリだけがネットワークに接続できない場合は、アプリのループバック制限も考慮してください。一部のクライアントにはUWP Loopbackの補助機能があります。この問題は、通常のデスクトップブラウザーにおけるシステムプロキシ設定とは別の層にあります。

TUNを有効にした後、システム全体でドメインを解決できなくなった場合は、まずTUNを無効にしてネットワークを復旧し、DNS設定、仮想NIC、他のVPNとの競合を確認します。ノード、ルール、DNS、ルートを同時に変更しないでください。どの変更が原因で状況が変わったのか判断できなくなります。

結果から絞り込む：再現可能なトラブル対処手順

  1. クライアントのコアが動作中で、設定ページに解析エラーがないことを確認します。
  2. クライアント画面から実際のHTTP、SOCKS5、またはmixed-portを読み取り、ポート番号を決め打ちしません。
  3. netstat、lsof、またはssでポートがリスニング中であることを確認します。
  4. 一時的にグローバルモードへ切り替え、利用可能と確認済みのノードを選択します。
  5. ブラウザー経路で、システムプロキシ、Firefox独自の設定、プロキシ拡張機能を確認します。
  6. Clashのログを開き、新しいドメインへアクセスして、リクエストがコアに入るか確認します。
  7. ターミナルでcurl -xを使ってプロキシを明示し、最初から環境変数に依存しません。
  8. 明示的なテストに成功したら、HTTP_PROXY、HTTPS_PROXY、またはツール固有のプロキシを設定します。
  9. ルールモードに戻し、ログから一致したルール、ポリシーグループ、最終的な出口を確認します。
  10. アプリケーションがシステムプロキシに対応していない場合に限り、TUN、UWPループバック、コンテナーネットワークを検討します。

この手順のポイントは、各ステップで1つの変数だけを検証することです。ブラウザーはつながらないが明示的なcurlは成功するなら、システムプロキシとブラウザーを確認します。ブラウザーはつながるがターミナルはつながらないなら、環境変数とツール設定を確認します。どちらもローカルポートへ接続できないなら、コアとリスニングを確認します。リクエストがログに入っているのに結果が異常なら、ルール、ノード、DNSを確認します。「システムプロキシが効かない」をこのように観察可能な結果へ分解すれば、通常はクライアントを再インストールする必要はありません。

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