1. カーネルの起動とWebサイトへの接続を切り分ける

クライアントに正常と表示されていても、通常わかるのはカーネルが起動している、またはシステムプロキシが有効になっていることだけです。ノードの遅延テストに成功しても、その時点でテスト用の通信が完了したことを示すにすぎません。ブラウザーで別のドメインにアクセスすると、異なるルールやポリシーグループ、DNS経路が使われることがあります。「接続済み」と表示されたからといって、すぐにWebサイト側の問題と判断したり、ポート・DNS・ルールを一度に変更したりしないでください。

トラブルシューティングを始める前に、クライアント名、カーネルの種類、現在の設定名、動作モード、ローカルの待ち受けポートを記録しておきましょう。ClashとClash Meta（現名称：mihomo）では設定できる項目が完全には同じではなく、GUIのメニューもクライアントによって異なります。以下では「システムプロキシ」「接続」「ログ」などの機能名を使って説明し、OSのメニューは具体的な場所を示します。

  1. 現在使う設定が選択されていることを確認してください。サブスクリプションのダウンロードが完了しただけでは不十分です。
  2. 表示されたエラーを記録します。例：ERR_PROXY_CONNECTION_FAILED、ERR_NAME_NOT_RESOLVED、接続タイムアウト。
  3. アクセスに失敗するURLを1つ選び、毎回同じものをテストに使いましょう。設定を変えるたびに再接続して結果を記録します。
  4. 複数のプログラムが同時にプロキシ設定を変更しないよう、ほかのプロキシクライアント、ブラウザーのプロキシ拡張機能、通信高速化ツールを一時終了します。

2. プロキシを無効にして、通常のネットワーク接続を確認する

まずクライアントのシステムプロキシとTUNを無効にし、OSに手動プロキシ設定が残っていないか確認します。Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」を開きます。macOSでは「システム設定」→「ネットワーク」→現在のネットワーク接続→「詳細」→「プロキシ」を開きます。PAC自動構成スクリプトを使用している場合は、手動プロキシと混同しないよう、スクリプトのURLも記録してください。

次に、現在のネットワークから通常アクセスできるはずのWebサイトを開き、Wi-Fiのログイン認証が必要か確認します。ホテル、大学、公共施設などのネットワークで認証が済んでいない場合、クライアントを起動してもローカルの接続制限は回避できません。ターミナルで次のコマンドを実行し、HTTPSで直接接続できるか確認できます。

curl -I --noproxy "*" --connect-timeout 10 https://example.com/

Windowsでは、古いWindows PowerShellがcurlを別のコマンドとして解釈するのを避けるため、curl.exeを使うのがおすすめです。このコマンドで確認できるのは指定したサイトだけです。失敗してもネットワーク全体が停止しているとは限らないため、別のローカルでアクセス可能なサイトやスマートフォンのテザリングでも確認してください。すべてのプロキシを無効にしてもルーターの管理画面や普段直接アクセスするサイトを開けない場合は、ネットワーク接続、認証、OSのネットワーク設定を優先して確認しましょう。

3. システムプロキシのアドレスと待ち受けポートを確認する

ポートを確認してからシステムプロキシを有効にする

クライアントの設定でHTTPポートまたは混合ポートを確認し、OSのプロキシアドレスと照合します。たとえば設定がmixed-port: 7890で待ち受けている場合、同じPCの手動プロキシには127.0.0.1:7890を指定できます。7890は例であり、すべてのクライアントで共通の既定値ではありません。画面に7897と表示されている場合は、コマンドとシステム設定の両方に実際の値を指定してください。

HTTPプロキシ用のポートと、SOCKS専用ポートは自由に置き換えられません。システム設定が停止中のポートを指していると、ブラウザーにプロキシ接続エラーが表示されることがあります。システムプロキシ設定を経由せず、HTTPプロキシを明示してテストできます。

curl -I --proxy http://127.0.0.1:7890 --connect-timeout 10 https://example.com/
  • 明示的なプロキシ接続は成功し、ブラウザーでは失敗する：システムプロキシが別のプログラムに変更されていないか、ブラウザー拡張機能が設定を上書きしていないか、ブラウザー独自のプロキシ設定を使っていないか確認します。
  • 127.0.0.1にすぐ接続できないと表示される：まずカーネルが起動しているか、ポートが待ち受けているかを確認します。この段階ではリモートノードを変更する必要はありません。
  • 200 Connection establishedの後に失敗する：HTTPプロキシがトンネル要求を受け付けたことを示すだけで、その後のTLSハンドシェイクやWebページの応答が成功したとは限りません。
  • 407が返される：ローカルプロキシに認証が設定されていないか確認してください。認証エラーをノードのタイムアウトと混同しないようにします。

ポートを使用しているのが現在のクライアントか確認する

Windowsのターミナルで次のコマンドを実行し、待ち受け状態とプロセスIDを確認します。macOSでは2つ目のコマンドで待ち受けプロセスを確認できます。

netstat -ano | findstr ":7890"
lsof -nP -iTCP:7890 -sTCP:LISTEN

Windowsでは、出力に表示されるローカルアドレスとLISTENINGの状態を確認し、「タスク マネージャー」→「詳細」からPIDに対応するプロセスを調べます。ポート番号が出力にあるだけで、正常に待ち受けていると判断しないでください。古いクライアントがポートを使用している場合は、古いプログラムを通常の手順で終了するか、現在のクライアントに空きポートを設定し、システムプロキシも同じ値に変更します。自分のPCだけで使う場合、通常は「LANに接続されている場合に使用する」を有効にする必要はありません。

4. 接続履歴からルールとポリシーグループを確認する

ルールモードのままクライアントの「接続」または「ログ」を開き、問題のWebページを再読み込みします。対象ドメイン、適用されたルール、ポリシーグループ、最終的な通信先を記録してください。既存の長時間接続はノード切り替え後も以前の経路を使うことがあるため、該当する接続を閉じるか、ブラウザーを再起動してからテストします。記録が見つからない場合は、ログで対象の通信が除外されていないか確認してください。それでも記録がなければ、プロキシの入口を確認し直します。

確認できた状況まず確認する項目次に行うこと
対象の接続にREJECTが適用されているドメインルール、ルールセット、広告ブロックルール該当するルールを特定し、ログイン・認証・静的ファイルのドメインを誤ってブロックしていないか確認する
対象の接続がDIRECT経由になっている現在のネットワークからそのサイトへ直接接続できるか適用されたドメインルールと最後のフォールバックルールを確認する
プロキシグループ経由でもタイムアウトするグループ内で実際に選択されているノードと、ネストされたポリシーグループ利用可能な別の出口に切り替え、同じURLでもう一度試す
一部のリソースだけ読み込めない画像・スクリプト・APIそれぞれの通信経路ページのメインドメインだけでなく、読み込みに失敗したドメインを確認する

Clashのルールは上から順に評価され、最初に一致したルールが適用されます。広すぎるDOMAIN-SUFFIXルールが前にあると、後続の詳細なルールが適用されないことがあります。ルールに原因があると思われる場合は、一時的にグローバルモードへ切り替え、利用可能なノードを明示的に選択して比較します。同じURLがグローバルモードでは開き、ルールモードでは開かない場合は、グローバルモードを使い続けて設定の問題を覆い隠すのではなく、出口と適用ルールの記録を重点的に確認してください。

5. OSのDNSとカーネルのDNSの問題を切り分ける

ブラウザーにドメイン名の解決エラーが表示されても、OSのDNSだけが原因とは限りません。OSのリゾルバー、ブラウザーのセキュアDNS、カーネルのDNS、リモートノードが名前解決に関与することがあり、実際の経路はプロキシ方式と設定によって異なります。まず次のコマンドを実行し、OSのリゾルバーが対象ドメインに返す応答を確認してください。

nslookup example.com

nslookupが成功しても、その時点でOS側の問い合わせが応答を受け取ったことを示すだけで、カーネルが使う上流DNSが正常だとは限りません。反対にOS側の問い合わせが失敗しても、プロキシ経由でドメインを解決する通信まで失敗するとは限りません。HTTPSサイトにHTTPプロキシ経由でアクセスする場合、通常はクライアントから対象ドメインが見えます。SOCKSのテストではsocks5://とsocks5h://でドメインを解決する場所が異なるため、結果を比較するときはこの違いを考慮してください。

実際の名前解決経路に沿って確認する

  1. ログでDNS、resolve、timeoutを検索し、エラーが発生したドメインと上流アドレスを確認します。最後のタイムアウトだけを見て判断しないでください。
  2. DoHまたはDoTを有効にしている場合は、上流アドレスに到達できるか確認します。上流をドメイン名で指定している場合は、上流の名前解決に循環依存が発生していないかも確認してください。
  3. 比較のため、ブラウザーの「セキュアDNS」を一時的に無効にしてテストし、終了後に元の設定へ戻します。ブラウザー独自の暗号化DNS接続は、OSのリゾルバーとは異なる経路を使うことがあります。
  4. fake-ipを使用している場合、198.18.0.0/15の範囲にあるマッピングアドレスが表示されても、それだけで名前解決エラーとは限りません。その後の接続がカーネルに正しく取り込まれ、ドメイン名へ復元されているか確認してください。

WindowsでDNSを変更した後は、ipconfig /flushdnsを実行してOSのキャッシュを消去できます。クライアントのカーネルやブラウザーのキャッシュは、それぞれ別に消去が必要な場合があります。WebサイトのIPアドレスへ直接アクセスして、通常の接続テストの代わりにしないでください。HTTPSサイトでは証明書の検証、SNI、仮想ホストの選択にドメイン名が使われるため、IPアドレスへの直接アクセスに失敗してもDNSが原因とは限りません。

6. TUNはシステムプロキシの確認後に調べる

明示的なプロキシ接続とブラウザーのシステムプロキシがどちらも正常で、TUNを有効にしたときだけ通信できなくなる場合は、仮想ネットワークアダプター、ルーティング、DNSの取り込みを重点的に確認します。TUNは仮想ネットワークアダプターにルーティングされたIP通信を取り込む機能で、すべてのアプリやネットワーク環境で自動的に正しい設定になるわけではありません。権限不足、ドライバーの異常、ほかのVPNが設定したルートによって、通信が誤ったインターフェースを通ることがあります。

  • 権限とサービス：クライアントが要求するサービスモードや管理者権限での許可が完了しているか確認し、カーネルのログでTUNの起動成功が明示されているか確認します。
  • ルートの競合：ほかのVPNを一時的に切断し、Windowsではroute print、macOSではnetstat -rnを使って、有効化前後のルートを比較します。
  • DNSの取り込み：設定のdns-hijackが実際のDNS経路と一致しているか確認します。通常の53番ポートを取り込めば、ブラウザーのDoHも取り込めるとは限りません。
  • IPv6の経路：ドメインからAレコードとAAAAレコードの両方が返される場合は、IPv4とIPv6それぞれのルートと取り込み状況を確認します。IPv4のテストに成功しただけで、すべての通信が正常だと判断しないでください。

Webページは開けるものの、大きな画像の読み込みやダウンロードが止まりやすい場合は、パケットロス、MTU、プロトコルの違いを確認できます。ただし、これらはプロキシの入口、ルール、DNSに問題がないと確認できた後に調べる項目です。根拠なくMTUを変更すると、確認すべき条件が増え、元の問題を再現しにくくなることがあります。

7. 特定のサイトだけ開けない場合は、上流接続とブラウザーを確認する

複数のブラウザーで同じサイトにアクセスできず、ほかのサイトは正常な場合は、別のノードから同じサイトへ接続し、サブスクリプションの状態、ノードのプロトコル設定、システム時刻を確認します。システム時刻がずれているとTLS証明書の検証に失敗することがあります。サブスクリプションを更新できても、設定の取得に成功したことを示すだけで、すべてのノードが利用可能とは限りません。

問題が1つのブラウザーだけで発生する場合は、拡張機能を有効にしていない新しいプロファイルで比較し、独自のプロキシ設定、セキュアDNS、キャッシュ、サイトの権限を確認します。シークレットウィンドウでも、シークレットモードでの実行が許可された拡張機能が有効な場合があります。シークレットモードで試しただけで、すべての拡張機能を除外できたとは限りません。証明書エラーが発生した場合は、エラーコードと証明書の発行者を記録してください。提供元不明のルート証明書をインストールして警告を消そうとしないでください。

ノードの遅延が小さくても、Webページの表示が遅い場合は、対象サイトまでの距離、パケットロス、帯域幅、サーバー側の速度制限が関係している可能性があります。1回の遅延テストだけでは、実際のWebページへのリクエストを確認できません。同じURL、同じネットワーク、同じ時間帯で比較し、テスト対象を変えたことによる差を設定変更の結果と取り違えないようにしてください。

8. 結果をまとめ、普段の設定に戻す

トラブルシューティングが終わったらルールモードに戻し、改善につながらなかった一時的な変更を元に戻します。システムプロキシのポートがクライアントと一致していることを確認し、必要に応じてTUNを有効にしてください。クライアントを終了した後にインターネットへ接続できなくなった場合は、ネットワーク全体をすぐにリセットするのではなく、停止したローカルプロキシをシステムが引き続き参照していないか確認します。

サポートを依頼するときは、「接続済みなのに開けない」とだけ伝えるより、再現に必要な情報を添えると役立ちます。以下の項目をまとめ、サブスクリプションURL、アクセストークン、ノードのパスワード、個人のIPアドレスなどの機密情報は伏せてください。

  • OS、クライアント、カーネルの正確なバージョンと、システムプロキシまたはTUNのどちらを使用しているか。
  • アクセスに失敗する対象のドメインとブラウザーのエラーコード。ログイン用トークンを含むURL全体は公開しないでください。
  • ローカルの待ち受けポート、プロキシを明示したテスト結果、プロキシを使わない接続が正常かどうか。
  • 同じリクエストに適用されたルール、ポリシーグループ、最終的な通信先、発生時刻に対応するエラーログ。
  • ノードの切り替え、TUNの無効化、ネットワークの変更によって、どの結果が変わったか。

確認する順序は、ローカルネットワーク → プロキシの入口 → 待ち受けポート → ルールと出口 → DNS → TUNと上流接続です。一度に変更する項目は1つにし、同じリクエストで検証しましょう。そうすることで、「正常そうに見える」状態を、原因を説明できる接続結果へと切り分けられます。