まず「接続済み」が示す範囲を確認

Clashクライアントが起動中で、ノードに遅延時間が表示され、システムにVPN接続済みと表示されていても、ブラウザーから目的のWebサイトまでの通信がすべて正常とは限りません。起動中の表示は通常、コアプロセスが開始したことを示すだけです。ノードの遅延テストは設定されたテスト先に接続するもので、AndroidのVPNアイコンも主にローカルのVPNサービスが確立したことを示します。Webページの表示には、アプリのプロキシ設定、ローカルの待ち受けポート、ルールによる振り分け、ノードからの通信、接続先サイトのすべてが関わります。どこか一つでも問題があれば、ページが読み込み中のままになることがあります。

ここではClash互換クライアントを対象に説明します。Clash Meta（現mihomo）コアでも、同じ順番で確認できます。クライアントによって設定名や既定のポートは異なります。例に挙げる 7890 は確認用のローカル混合ポートで、使用中の端末の実際の値とは限りません。

  1. 現在の設定名、選択中のノード、プロキシモード、HTTPまたは混合ポート、システムプロキシとTUNの有効・無効を記録します。
  2. ほかのプロキシクライアントやVPNをいったん停止します。デスクトップではまずTUNを無効にし、システムプロキシだけで確認すると、ルーティングやDNSの影響を切り分けやすくなります。
  3. 通常は直接接続できるサイトと、現在のプロキシ経由で接続するサイトをそれぞれ開き、ブラウザーに表示されたエラーコードを記録します。
  4. 変更は一度に一つだけ行い、同じURLにアクセスします。改善した設定はそのままにし、効果がなければ元に戻します。ポート、DNS、ルールを同時に変更しないでください。

手順1：サブスクリプションの期限と設定の読み込みを確認

更新に成功しても、ノードが使えるとは限らない

クライアントのサブスクリプションまたは設定画面で、一覧のうち最近更新された項目だけでなく、現在有効になっている設定を確認します。更新成功はサブスクリプションの内容をダウンロードできたことを示しますが、アカウントに利用可能な通信量が残っていることや、ノードサーバーに接続できることを保証するものではありません。反対に、更新に失敗してもクライアントがキャッシュ済みの設定を使い続けることがあり、一覧にはノードが表示されたままの場合があります。

  • アカウントを確認：サブスクリプション提供元のアカウントページで、有効期限、残りの通信量、デバイス制限を確認します。クライアントに表示されたキャッシュ情報だけで判断しないでください。
  • 応答を確認：ログにHTTP 401または403が記録されている場合は、認証情報、アカウントの状態、提供元のアクセス制限を確認します。404の場合は、URLが無効になっていないか、コピー漏れがないか確認します。ステータスコードだけでは原因を特定できません。
  • 形式を確認：YAMLの解析エラーが出る場合は、ログインページやエラーページをダウンロードしたか、現在のクライアントが対応していない形式のClash設定を取得した可能性があります。
  • コアを確認：設定に現在のコアが対応していないプロトコルや項目が含まれている場合は、提供元が対応を明示しているサブスクリプション形式を選ぶか、互換性のあるコアを使用します。何度もインポートし直しても解決しません。

ノードを固定して自動選択の影響を切り分ける

現在のプロキシグループでノードを一つ手動選択し、リクエストが実際にそのグループを経由していることを確認します。ノードA、次にノードBの順に、毎回同じサイトへアクセスして試します。遅延テストに成功してもWebページが開かない場合、テスト先には接続できても目的のサイトには接続できない、または目的のサイトへの通信が別のプロキシグループに振り分けられている可能性があります。遅延時間だけで判断せず、接続ログで実際の経路も確認してください。

すべてのノードで失敗し、直接接続できるサイトは正常な場合は、サブスクリプションのアカウント、ノードのホスト名の名前解決、ノードのポートへの接続を優先して確認します。サブスクリプションURLを見知らぬオンライン変換・診断サイトに入力しないでください。URLには認証情報が含まれることが多いため、スクリーンショットを共有するときもトークンやQRコードを隠してください。

手順2：混合ポートの待ち受け状態を確認し、ポート競合を解消

システムプロキシが 127.0.0.1:7890 を指定しているのに、コアが実際には 7897 で待ち受けていれば、ブラウザーはその経路で接続できません。古いクライアントがポートを使用中で、新しいクライアントの画面は起動していても、バインドに失敗してコアがプロキシを提供できていないケースもあります。現在の実行設定で mixed-port またはHTTP用の port を確認し、ログに address already in use がないか調べます。

Windows PowerShellで次のコマンドを実行し、例としてポート 7890 を確認します。実際のポートが異なる場合は、コマンド内の数字を置き換えてください。

Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

待ち受け結果が表示されない場合は、コアが起動しているか、設定の読み込みに失敗していないかを確認します。プロセスIDが見つかった場合は、次のコマンドでどのプロセスか調べます。正体の分からないプロセスを終了したり、ローカルプロキシを直すために待ち受けアドレスを全ネットワークインターフェースに変更したりしないでください。

Get-Process -Id (Get-NetTCPConnection -State Listen -LocalPort 7890).OwningProcess

ブラウザーを介さずプロキシの入口を直接テスト

Windows標準の curl.exe で、ローカルHTTPプロキシを明示して指定します。macOSまたはLinuxでは、同じオプションを使って curl を実行できます。以下のURLはHTTPSリクエストが完了するかを確認するためのもので、ノードの速度測定には使えません。

curl.exe --noproxy "" -x http://127.0.0.1:7890 -I --connect-timeout 10 --max-time 20 https://example.com/
テスト結果まず確認すること次の手順
直ちにローカルポートへ接続できないと表示される待ち受けアドレスまたはポートの誤り、コアが未起動待ち受けプロセスと実行設定を再確認
ローカル接続後にタイムアウトするノードへの接続、ルール、名前解決のいずれかに問題同じ時刻のコアログを確認
接続先サイトからHTTPレスポンスヘッダーを受信指定した宛先への明示的なプロキシ経路は利用可能ブラウザーとシステムプロキシの設定を確認
プロキシ認証エラーを受信ローカルの入口で認証が設定されている認証設定とクライアントの対応状況を確認

HTTPSリクエストで 200 Connection established だけが表示されても、接続先のページが正常に返されたとは限りません。続くTLSハンドシェイクと接続先からの応答も確認してください。接続先から 403 や 429 が返っても、プロキシが切断されたとは限りません。サイトのアクセス制限やリクエスト頻度の制限が原因の場合があります。

手順3：システムプロキシとブラウザーの設定を確認

明示的なプロキシテストが成功してもブラウザーで開けない場合は、ブラウザーが同じ入口を実際に使っているか確認します。システムプロキシは端末全体の通信を透過的に中継する仕組みではありません。アプリがシステムプロキシを無視したり、拡張機能、PACスクリプト、独自のプロキシ設定で上書きしたりすることがあります。

  • Windows 11：「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシのアドレスとポート、セットアップスクリプトの有効・無効を確認します。クライアントのシステムプロキシ切り替えを使う場合は、通知領域の表示だけでなく、こちらの設定内容も確認してください。
  • macOS：「システム設定」→「ネットワーク」→使用中のネットワークサービス→「詳細」→「プロキシ」を開きます。HTTP、HTTPS、自動プロキシ設定が現在の設定と一致しているか確認し、無効になったPAC URLが残っている場合は解除します。
  • Firefox：「設定」→「一般」→「ネットワーク設定」→「接続設定」を開き、システムのプロキシ設定を使用しているか、別のプロキシが手動で指定されていないか確認します。
  • Android：通常はクライアントのVPNサービスで通信を中継するため、デスクトップと同じシステムプロキシの手順では確認できません。アプリ別プロキシの一覧を確認し、ブラウザーが対象外になっていないか、ほかのVPNが接続を奪っていないか調べます。

ブラウザーのプロキシ拡張機能を一時的に無効にして再試行し、ブラウザーを完全に終了してから再起動して、古い接続が再利用される影響を減らします。Windowsで netsh winhttp show proxy を実行して確認できるのはWinHTTPプロキシです。すべてのブラウザーが使うシステムプロキシの状態を示すわけではないため、これだけを根拠に判断しないでください。

手順4：ルールの一致結果と実際の出力先を確認

クライアントをルールモードに切り替え、「接続」またはリクエスト一覧に相当する画面を開いてから、開けないサイトに再アクセスします。対象ドメイン、一致したルール、選択されたプロキシグループ、最終的なノードを記録してください。Clashのルールは通常、上から順に評価されます。先にある範囲の広いルールが一致すると、後ろのドメイン指定ルールが適用されないことがあります。

  1. 対象のリクエストが接続一覧に表示されていることを確認します。記録がなければ、アプリがプロキシを使っていない、接続が再利用されている、またはほかのネットワークツールが通信を処理している可能性があります。
  2. 最終的な出力先が DIRECT の場合は、そのサイトを直接接続する設定でよいか確認し、ログイン、画像、APIなどのドメインがルールから漏れていないか調べます。
  3. 最終的な出力先が REJECT の場合は、ブロックルールが誤って通信を遮断していないか確認します。すべてのルールを削除しないでください。
  4. プロキシグループを経由している場合は、グループ内の選択内容を展開し、利用できないノードや DIRECT が選ばれていないか確認します。
  5. 一時的にグローバルモードへ切り替え、テスト済みのノードを明示的に選択して同じURLにアクセスします。比較が終わったらルールモードに戻してください。

グローバルモードでは開けるのにルールモードでは開けない場合は、2回のリクエストで実際の出力先がどう異なるかを確認します。「グローバルなら使える」ことを恒久的な解決策とみなさないでください。グローバルモードは多くの接続の出口を変更するため、ローカルサービス、職場のネットワーク、アカウントへのログインに影響することがあります。どちらのモードでも失敗する場合は、ノードと名前解決を確認し、ドメインルールを何度も追加する必要はありません。

カスタムルールは、クライアントが対応する上書きまたはマージ機能で保存してください。サブスクリプションが生成したファイルを直接編集すると、次回の更新で変更が上書きされる場合があります。まず必要最小限のルールを残し、ページ表示に必要なAPIドメインも確認します。関係のない通信まで変わる広範なサフィックスルールは避けてください。

手順5：DNS汚染、名前解決の失敗、Fake-IPの正常な動作を見分ける

ブラウザーで名前解決エラーが表示されても、DNS汚染とは限りません。上流DNSのタイムアウト、暗号化DNSサーバーへの接続不可、ノードのホスト名を解決できない、ブラウザーのセキュアDNSとクライアントの名前解決経路が異なる、といった原因でも似た症状が起きます。まず、ログで失敗しているのが接続先サイトのドメインか、プロキシノード自体のドメインかを確認してください。

まずDNSクエリの経路を確認

Windowsでは次のコマンドで、システムの既定DNSによる名前解決結果を確認できます。この結果はその時点でのシステムの問い合わせを示すだけで、ブラウザー、Clash内蔵DNS、リモートプロキシでの名前解決結果を示すものではありません。

nslookup example.com
ipconfig /flushdns

2つ目のコマンドはWindows DNSクライアントのキャッシュを消去しますが、ブラウザーやコアのDNSキャッシュは消去しません。DNS設定を変更した後は、クライアントの機能に応じて設定を再読み込みするかコアを再起動し、ブラウザーの接続も張り直してください。2台のDNSサーバーが異なるIPアドレスを返しても、それだけでDNS汚染とは判断できません。CDNの振り分けで結果が異なることもあります。

Fake-IPが仮想アドレスを返しても、名前解決の誤りとは限らない

Fake-IPモードでは、クライアントが設定に応じて 198.18.0.0/16 の範囲内の仮想アドレスを返すことがあります。このアドレスはドメインと接続の対応付けに使うもので、接続先サイトの実サーバーアドレスではありません。このアドレスが表示されただけで障害と判断せず、対象の接続が正しく処理されているか、コアに対応するマッピングが残っているかを確認してください。

  • 特定のアプリだけで問題が起きる場合は、独自のDNSを使用していないか、古いFake-IPアドレスをキャッシュしていないか、プロキシを経由せずに接続していないかを確認します。
  • ログに上流DNSのタイムアウトが記録されている場合は、nameserver に指定したサーバーに現在のネットワークから接続できるか確認します。出所の分からないDNSアドレスを一度に多数追加しないでください。
  • ノードにホスト名が設定されている場合、「ノードに接続するにはDNSが必要だが、DNSに接続するにはノードが必要」という循環が起きていないか確認します。mihomoでは設定に応じて proxy-server-nameserver でノードのホスト名を解決するDNSサーバーを指定できます。旧バージョンのコアとの互換性は個別に確認してください。
  • ブラウザーのセキュアDNSが有効な場合は、一時的に無効にして比較します。確認後は必要に応じて元に戻し、どの名前解決経路で結果に差が出たか記録してください。

nameserver または fallback を変更する前に、元の設定を保存してください。fallback が有効かどうか、また結果がどのように選択に使われるかは、コアやフィルター設定によって異なります。「最初のDNSが失敗したときだけ次のDNSを使う」という単純な仕組みではありません。名前解決に問題がある場合は、ログと使用中のコアのドキュメントを確認して設定を変更し、出所不明のサンプルにDNS設定全体を置き換えないでください。

手順6：TUNを有効にしたときだけ失敗する場合は、ルーティングとDNSの処理を確認

TUNを無効にして明示的なプロキシを使うと正常で、TUNを有効にすると失敗する場合は、問題を仮想ネットワークアダプター、権限、ルーティング、DNSの処理、ほかのVPNとの競合に絞り込めます。TUNがどの通信を処理するかは、ルート、除外設定、プラットフォームの実装によって異なります。「TUNを有効にすれば、すべてのアプリが必ずプロキシを通る」という意味ではありません。

  1. クライアントに、使用中のプラットフォームで必要なサービス権限またはネットワーク権限が付与されているか確認します。起動ログにデバイス作成やルート追加の失敗がないかも確認してください。
  2. ほかのVPN、通信最適化ツール、重複して起動しているClashクライアントを停止します。業務用端末のセキュリティソフトや企業VPNは、管理ルールに従ってから操作してください。
  3. カスタムルートの除外設定やアプリごとの迂回設定を確認し、問題のアプリや接続先アドレスが除外されていないか調べます。
  4. dns-hijack の設定が現在のコアに合っているか確認します。従来のDNSポートを対象にした処理では、アプリ独自のHTTPS DNSリクエストを復号できません。
  5. 単純で経路を把握しやすい構成に戻してから再テストします。障害発生中にシステムプロキシ、複数のVPN、複雑なルート上書きを同時に有効にしないでください。

軽いページは開けるのに、サイズの大きなページやダウンロードだけ止まる場合は、ノードやサイト側の要因を除外したうえで、MTUや経路の問題を検討します。MTUの変更を最初に試さないでください。まず現在の値を保存し、一度に一つだけ変更して同じリクエストを比較します。改善しなければ元に戻します。

調査結果を整理：必要最小限の情報で原因を絞り込む

ここまでの確認で、設定が無効、ローカルポートが待ち受けていない、アプリがシステムプロキシを迂回している、ルールが誤判定している、ノードや名前解決の経路に問題がある、といった原因を切り分けられるはずです。解決せずサポートを求める場合は、「接続済みなのに開けない」というスクリーンショットだけでなく、次の情報を共有すると状況を判断しやすくなります。

  • OS、クライアント名と正確なバージョン、コア名とバージョン。クライアントの「バージョン情報」画面または起動ログで確認できます。
  • 実際の待ち受けポート、システムプロキシとTUNの状態、特定のブラウザーだけで問題が起きるかどうか。
  • 同じURLを明示的なプロキシ、ルールモード、グローバルモードで試した結果と、テストした時刻。
  • 失敗したリクエストに一致したルール、プロキシグループ、関連するログのエラー。アカウント情報、サブスクリプショントークン、機密性の高いアドレスは隠してください。

最後に、一時的に変更したプロキシモード、ブラウザーのセキュアDNS、ログレベルを元に戻し、効果を確認できた変更だけを残します。クライアントを再インストールする場合は、ローカルの上書き設定やルールを先にバックアップしてください。再インストールしても、サブスクリプションの期限切れ、ノードの停止、Webサイト側のアクセス拒否は解決しません。