まず「コアの起動」「システムプロキシ」「アプリの通信」を切り分ける

クライアントに「実行中」と表示されても、通常はプロキシコアが起動していることを示すだけで、ブラウザーがそのプロキシを使っているとは限りません。ノードの遅延テストに成功しても、そのテストで使った経路が利用可能だと分かるだけで、Webページへのリクエストが同じノードを経由した証明にはなりません。原因を調べるときは、ローカルポートが待ち受けているか、アプリがそのポートにリクエストを送っているか、コアが受け取ったリクエストをどう転送しているかの3点に分けて確認します。

ClashおよびClash Meta（現名称：mihomo）のコアは接続を受け付けて転送します。デスクトップクライアントの「システムプロキシ」スイッチは、通常、OSのプロキシ設定を変更するものです。この2つは別の設定です。ChromeやEdgeは一般にシステムプロキシを参照しますが、Firefoxでは個別にプロキシを設定できます。ターミナルのプログラムは環境変数や独自の設定を参照することがよくあります。

  1. クライアント名、コア名、現在のモード、ローカルの待ち受けポートを記録します。
  2. テスト先には、毎回変更せずに済む固定のアドレス（例：https://example.com/）を使います。
  3. クライアントの接続一覧とログを開いてからリクエストを送信し、時刻、ドメイン、ルール、出口のポリシーを照合します。
  4. 一度に変更する項目は1つだけにします。テスト後は一時的な設定を元に戻し、変更前後の結果を記録してください。

手順1：ローカルのプロキシポートが接続を受け付けるか確認する

HTTP、SOCKS、混合ポートの違いを確認する

クライアントの設定または実行中の設定から、port、socks-port、mixed-portを探します。メニュー名はクライアントによって異なるため、実際に適用されている設定を確認してください。以下は各項目の意味を示す例です。既存の設定に3つすべてのポートを追加する必要はありません。サブスクリプション内のノードやルールを上書きしないでください。

# 設定項目の例：実際にコアで有効になっている設定を確認
port: 7890
socks-port: 7891
mixed-port: 7892
allow-lan: false
  • port：HTTPプロキシの入口です。HTTPSサイトへの接続では通常、HTTP CONNECTでトンネルを確立します。
  • socks-port：SOCKSプロキシの入口です。HTTPプロキシのポートとして指定することはできません。
  • mixed-port：同じ入口でHTTPとSOCKSの両方のプロキシ接続を受け付けます。

ローカルでのみ使う場合、アドレスには127.0.0.1を指定するのが基本です。システムプロキシは7890を参照しているのに、コアは7892でしか待ち受けていない、といったポートの不一致はよくあります。ローカル接続を直すために「LANからの接続を許可」を有効にする必要はありません。この設定はローカルポートを起動するものではありません。

待ち受け状態と使用中のプロセスを確認する

WindowsではPowerShellを開き、まずポートをテストしてから待ち受けプロセスを調べます。TCPテストに成功しても、接続を受け付けているプログラムが存在することしか分かりません。待ち受けているプロセスが現在使用しているプロキシコアかどうかも確認してください。

Test-NetConnection 127.0.0.1 -Port 7890
Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess
# 検索したプロセスIDを指定してください。以下の1234は説明用です
Get-Process -Id 1234

macOSでは次のコマンドを使います。Linuxではss -lntpを実行し、該当するポートを探してください。プロセス情報の表示に適切な権限が必要な場合があります。

lsof -nP -iTCP:7890 -sTCP:LISTEN

ログにaddress already in useと表示されたら、まず他のプロキシクライアントを終了してから、現在のコアを再起動します。待ち受けポートを変更した場合は、システムプロキシ、ブラウザーの手動プロキシ、ターミナルの環境変数も合わせて更新してください。用途の分からないプロセスを強制終了したり、同じポートを複数のクライアントで取り合ったりしないでください。

手順2：明示的なプロキシ接続をテストして問題の範囲を絞る

システムプロキシの設定を介さず、curlに使用するローカルポートを明示します。これにより、「アプリがプロキシを使っていない」場合と「プロキシ自体の転送に失敗している」場合を切り分けられます。Windowsではcurl.exeを使い、Windows PowerShell 5.1のcurlエイリアスによる引数の違いを避けます。macOSとLinuxではcurlを使ってください。

# Windows PowerShell：HTTPまたは混合プロキシのポートを明示して使用
curl.exe -v --connect-timeout 5 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

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

# 実際のSOCKSポートが7891の場合に限り、この行を使用
curl -v --connect-timeout 5 --max-time 20 --noproxy "" --proxy socks5h://127.0.0.1:7891 https://example.com/

--noproxy ""は、今回のリクエストでプロキシを迂回するリストを空にし、既存のNO_PROXYによる影響を防ぎます。socks5hでは接続先のホスト名をプロキシ側で名前解決します。socks5では通常、ローカル側で先に名前解決します。結果の違いはDNSの調査に役立つ手掛かりになりますが、一度の差だけで特定のDNSサービスに障害があるとは判断できません。

テスト結果内容と次の手順
127.0.0.1への接続が拒否されるまずアドレス、ポート、コアの実行状態を確認します。すぐにノードを変更する必要はありません。
ローカルポートへの接続後にタイムアウトする該当リクエストのプロキシグループ、ノード、DNS、リモート接続のログを確認します。
明示的なプロキシ接続は成功するが、ブラウザーでは失敗するまずシステムプロキシの設定、ブラウザーのプロキシモード、拡張機能を確認します。
ブラウザーでは成功するが、ターミナルからの通常のリクエストは失敗するまず環境変数、ツール独自の設定、プロセスの起動時刻を確認します。
一部のドメインだけ接続できない適用されたルール、プロキシ除外リスト、接続先サイトの応答、DNSの経路を確認します。

HTTPSのテストで200 Connection establishedと表示される場合、通常はCONNECTトンネルが確立したことを示すだけです。続けてTLS接続とWebページの応答を確認してください。403が返っても、システムプロキシが無効とは限りません。接続先サイトのアクセス制御による可能性があります。単独のステータスコードより、結果全体を確認することが重要です。

手順3：ブラウザーがプロキシを使わない場合は、システム設定と拡張機能を分けて確認する

Windows：クライアントのスイッチだけでなく、現在のシステムプロキシを確認する

  1. Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」→「手動プロキシ設定」の順に開きます。Windows 10では「設定」→「ネットワークとインターネット」→「プロキシ」を開いてください。
  2. プロキシのアドレスが現在のローカル接続先（例：127.0.0.1）になっているか、ポートがコアの設定と一致しているかを確認します。
  3. 「セットアップ スクリプトを使う」が有効か確認します。スクリプトのアドレスはPAC設定です。ルールに応じて一部のドメインを直接接続にする場合があるため、手動プロキシと混同して判断しないでください。
  4. プロキシの例外リストを確認します。接続先ドメインがリストに含まれていると、ブラウザーはプロキシを迂回することがあります。

別のプロキシツールによる自動制御をいったん無効にしてから、現在のクライアントのシステムプロキシスイッチを切り替え、システム設定も連動して変わるか確認します。組織管理下の端末ではポリシーが設定を制御している場合があります。設定が自動的に元に戻るときは管理者に相談し、レジストリを何度も変更しないでください。

netsh winhttp show proxyに表示されるのはWinHTTPのプロキシ設定であり、ChromeやEdgeが使用するシステムプロキシの状態とは異なります。WinHTTPが直接接続になっていても、ブラウザーのプロキシが無効とは限りません。ブラウザーで接続するために、根拠なくインポートやリセットのコマンドを実行する必要もありません。

macOS：現在使用中のネットワークサービスを確認する

macOS 13以降では、「システム設定」→「ネットワーク」→現在接続中のWi-FiまたはEthernet→「詳細」→「プロキシ」の順に開きます。すでに切断されたインターフェースではなく、現在使用中のネットワークサービスを変更しているか確認してください。「Webプロキシ（HTTP）」と「保護されたWebプロキシ（HTTPS）」の両方を確認します。どちらもローカルのHTTPプロキシを指定している場合は、ポートがクライアントの設定と一致している必要があります。

HTTPSサイトにローカルのHTTPプロキシ入口を使うのは正常です。アドレスをhttps://127.0.0.1に変更する必要はありません。一般的なClashのローカルHTTPプロキシでは、クライアントとローカルプロキシ間の接続にTLSは通常使われず、HTTPSの暗号化はトンネル内で行われます。

Firefoxとプロキシ拡張機能：設定元は一つに絞る

Firefoxでは「設定」→「一般」→「ネットワーク設定」→「設定」を開き、「システムのプロキシ設定を利用する」が選択されているか確認します。手動プロキシを使う場合は、アドレス、ポート、「プロキシなし」のリストを直接確認してください。ChromeやEdgeでは、プロキシ切り替え拡張機能の現在のプロファイルと、拡張機能が企業ポリシーで管理されていないかも確認します。

  • プロキシ切り替え拡張機能を一時的に無効にして再テストします。シークレットウィンドウでも、すべての拡張機能が自動的に無効になるとは限りません。
  • ブラウザーを完全に終了してから再起動し、古い接続の再利用によって設定変更が反映されない状況を避けます。
  • テストリクエストを送信しながら、クライアントの接続一覧を確認します。記録がない場合は、プロキシ入口や迂回設定に問題がある可能性があります。ただし、ページキャッシュ、リクエストが送信されていないこと、ログのフィルター設定も確認してください。
  • Linuxデスクトップでは、すべてのアプリがシステムプロキシに従うとは限りません。明示的なプロキシテストに成功したら、アプリが実際にサポートする方法で設定してください。

手順4：ターミナルがプロキシを使わない場合は、環境変数とツールの設定を確認する

システムプロキシは、すべてのプロセスに転送を強制する仕組みではありません。ターミナルのcurl、Git、パッケージマネージャーは、環境変数を参照する場合もあれば、それぞれ独自のプロキシ設定を使う場合もあります。すでに起動しているターミナルやIDEには、後から追加した環境変数が反映されないことがあります。まずは現在のセッション内でテストし、最初からシステム全体の設定を変更しないでください。

macOSとLinux：現在のシェルで設定する

# 既存のプロキシ環境変数を確認する。認証情報を含む出力を公開しないこと
env | grep -iE '^(http|https|all|no)_proxy='

# 現在のターミナルに適用される。ポートは実際の設定に合わせる
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890

# このリクエストでは上記の環境変数が使われる
curl -v --connect-timeout 5 --max-time 20 https://example.com/

# 調査後、今回追加した環境変数を削除する
unset http_proxy https_proxy

https_proxyの値にhttp://を使っても矛盾しません。変数名は接続先URLがHTTPSであることを示し、変数の値はプロキシサーバーへの接続方法を示します。curlにはHTTPプロキシ変数の大文字・小文字に関する仕様があるため、ここでは小文字の形式を使ってください。他のツールで利用できる変数は、それぞれのドキュメントで確認します。

Windows PowerShell：プロセス単位の環境変数を使う

# 現在のプロセスに設定されているプロキシ環境変数を確認
Get-ChildItem Env: | Where-Object Name -Match '^(HTTP|HTTPS|ALL|NO)_PROXY$'

# 現在のPowerShellセッションと、そこから起動する子プロセスに適用
$env:http_proxy = "http://127.0.0.1:7890"
$env:https_proxy = "http://127.0.0.1:7890"
curl.exe -v --connect-timeout 5 --max-time 20 https://example.com/

# 今回一時的に追加した変数だけを削除
Remove-Item Env:http_proxy, Env:https_proxy -ErrorAction SilentlyContinue

変数に以前から値が設定されていた場合は、その値を記録してテスト後に復元し、直接削除しないでください。特にNO_PROXYに接続先ドメインが含まれていないか、値が*になっていないか確認します。ワイルドカードによる除外が有効なツールでは、すべての接続先が直接接続になります。ALL_PROXYを設定している場合は、古いSOCKSポートが残っていないかも確認してください。

Git、WSL、コンテナ：同じ接続先を使うとは限らない

次の2つのコマンドで、Gitのプロキシ値と設定元を確認できます。設定元はシステム、ユーザー、リポジトリのいずれかです。修正するときは該当する階層の設定を変更し、ユーザー設定だけを削除して現在のリポジトリ設定を見落とさないようにしてください。出力にユーザー名、パスワード、内部アドレスが含まれる場合は、共有する前に伏せてください。

git config --show-origin --get-regexp 'http\..*proxy'
git config --show-origin --get-regexp 'remote\..*proxy'

WSL、コンテナ、仮想マシン内の127.0.0.1が、ホストOSを指すとは限りません。WSLではNATとミラーネットワークで動作が異なり、コンテナにも通常は独立したネットワーク環境があります。まず実行環境とホストに到達できるアドレスを確認し、そのうえで待ち受けアドレスやファイアウォールの変更が必要か判断してください。プロキシをすべてのネットワークインターフェースに公開するのは避けてください。GitのSSH形式のリモートアドレスも、HTTPプロキシを設定しただけで同じ経路を使うようにはなりません。

手順5：リクエストがClashに届いている場合は、ルール、DNS、TUNを確認する

接続一覧に記録がある場合：実際に選ばれた出口を確認する

クライアントに接続先ドメインが記録されているなら、調査の焦点を「システムプロキシのスイッチ」から転送経路に移します。ルールモードでは上から順にルールが適用され、DIRECTに一致すると直接接続になります。プロキシグループで、想定したプロキシノードではなく実際にはDIRECTが選択されている場合もあります。スイッチを何度も切り替えるより、接続の詳細にあるルール、ポリシーチェーン、接続先アドレスを確認する方が効果的です。

  1. 接続先アドレスを変えずに、適用されたルールと最終的に選ばれた出口を記録します。
  2. 一時的にグローバルモードへ切り替え、プロキシノードを明示的に選択して、同じアドレスに再度リクエストします。
  3. グローバルモードでのみ成功する場合は、ルールモードに戻り、対象ドメインのルール、ルールセット、フォールバック設定を確認します。
  4. テスト後は元のモードに戻してください。グローバルモードは比較のための手段であり、すべての問題を長期的に解決する設定ではありません。

ログレベルを一時的にdebugに変更し、一度再現したらinfoに戻す方法もあります。connection refusedの場合は、拒否されたのがローカルの入口かリモートサービスかを確認します。i/o timeoutの場合は、DNS、ノードへの接続、接続先への通信のどこでタイムアウトしたかを確認してください。エラーメッセージの末尾だけを切り取って判断しないでください。

DNSとTUN：個別に確認し、一度に両方を変更しない

明示的なHTTPプロキシ、SOCKS、ローカルからの直接接続、ブラウザーのセキュアDNS、TUNによるDNS制御では、名前解決の経路が異なる場合があります。nslookupに成功しても、そのコマンドで使われた経路で名前解決できたと分かるだけで、コアが同じ結果を使っている証明にはなりません。リクエストで名前解決エラーが発生した場合は、コアのログとdns設定を確認し、DNS設定ガイドを参照してください。上流DNSサーバーを一度にすべて変更しないでください。

TUNは仮想ネットワークインターフェースを使って、条件に一致する通信を制御します。明示的なプロキシ設定を参照しないアプリには有効ですが、「システムプロキシの強化版」ではありません。権限、ルーティング、DNS、他のVPNとの互換性にも関わります。システムプロキシとTUNを同時に有効にすると、テスト結果が別の入口を経由している場合があります。

最後に：記録を残し、一時設定を元に戻す

問題を報告するときは、再現に必要な最小限の情報を提示してください。OS、クライアントとコアのバージョン、HTTP/混合ポート、TUNの有効・無効、ブラウザー名、curlで明示的なプロキシ接続をテストした結果、同じ時刻の接続詳細が必要です。バージョンは実際のクライアントで確認し、「最新版」とだけ書かないでください。

  • 「明示的なプロキシ接続は成功するが、ブラウザーでは失敗する」のように、比較結果を記録します。「接続できない」だけでは原因を絞れません。
  • ログから同じリクエストを探せるよう、具体的な時刻と接続先ドメインを記載します。
  • サブスクリプションURL、ノードのパスワード、リクエスト内のCookie、認証ヘッダー、機密性の高いクエリパラメーターは伏せてください。
  • 一時的に変更したモード、ログレベル、ブラウザー拡張機能の状態、環境変数を元に戻します。

確認の順序は変えません。まずポートの待ち受けを確認し、次に明示的なプロキシ接続をテストします。成功したらブラウザーとターミナルを個別に設定します。リクエストがコアに届いたら、ルール、ノード、名前解決を確認します。各手順で結果を確認できるため、最初にクライアントを再インストールする必要はありません。