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

Clashは接続済みなのにWebサイトが開けないときの対処法｜8段階の確認手順

サブスクリプションの期限やノード、システムプロキシ、ルールモード、DNS、ポートの順に確認し、Clashでインターネットに接続できない原因を特定します。

「接続済み」と表示されても、クライアントのスイッチがオンになった、またはコアが起動したことを示すだけで、ブラウザーの通信がノードを経由できているとは限りません。原因を調べる際は、パソコン自体がインターネットに接続できるか、通信がClashに届いているか、その先で利用可能な出口に接続できているかを分けて確認しましょう。ノード変更、DNS設定の変更、クライアントの再インストールを一度に行うと、どの操作が有効だったのか判断しにくくなります。

まず現在の設定をバックアップし、クライアント名、コアのバージョン、混合ポート、元のプロキシモードを記録します。以下の例では 127.0.0.1:7890 を使用していますが、実際にはクライアントに表示されているポートを確認してください。各手順の後、同じURLで再テストします。

手順1：プロキシをオフにして、通常のネット接続を確認する

まずクライアントの「システムプロキシ」と「TUNモード」をオフにし、後で戻せるようクライアントの画面は開いたままにします。ほかのVPN、プロキシ拡張機能、通信高速化ツールを使っている場合は、通信制御が競合しないよう一時停止してください。その状態で、普段プロキシなしで開けるWebサイトにアクセスし、Wi-Fiや回線、ログイン認証に問題がないか確認します。

  1. Wi-Fiに接続済みと表示されるだけでなく、有効なローカルIPアドレスとデフォルトゲートウェイを取得できているか確認します。
  2. ホテルや空港などの公衆Wi-Fiでは、必要なWeb認証を先に完了します。証明書に異常があるページでは、アカウント情報を入力しないでください。
  3. 同じWi-Fiに接続したスマートフォンでモバイルデータ通信をオフにしてテストします。必要に応じて、パソコンをスマートフォンのテザリングに接続して比較してください。

プロキシをオフにしても通常のWebサイトが開けない場合は、まずネットワーク自体の問題を解決します。スマートフォンのテザリングに切り替えて直るなら、元のネットワークの認証、DNS、アクセス制限を確認しましょう。すべての問題をサブスクリプションやノードのせいにしたり、特定のWebサイトが開けないだけで回線全体が切断されたと判断したりしないでください。

手順2：サブスクリプションの有効期限と有効な設定を確認する

クライアントの「サブスクリプション」または「プロファイル」画面を開き、選択中のプロファイル名、最終更新日時、更新結果を確認します。メニュー名はクライアントによって異なりますが、ダウンロード済みの設定が一覧にあるだけでなく、実際に有効になっていることが重要です。サブスクリプションの更新に成功しても、プランの通信量が残っているとは限りません。

  • プランを確認：サブスクリプション提供元のアカウントページで、有効期限、残りの通信量、デバイス数の制限を確認します。通信量が表示されないからといって、無制限と判断しないでください。
  • 手動で一度更新：HTTP 401、403、404、タイムアウトなどが発生するか確認します。401や403は認証またはアクセス制限、404はURLの無効化が原因の可能性があります。提供元の案内も確認してください。
  • 読み込み結果を確認：更新後、ノード数やグループが表示されているか確認します。ログにYAMLの解析エラーがある場合は、まず設定を修正してください。古い設定を新しい設定としてテストしないようにしましょう。

サブスクリプションURLにはアクセス認証情報が含まれていることが多いため、公開の掲示板に貼ったり、スクリーンショットに写したりしないでください。更新に失敗しても、既存の設定を正常に読み込めるなら、まずはそのノードで切り分けを続けられます。サブスクリプションの取得と実際のプロキシ接続で、同じネットワーク経路が使われるとは限りません。

手順3：遅延の数値だけで判断せず、ノードをテストする

「プロキシ」画面を開き、現在のグループで実際に選択されているノードを確認します。グループ名に「自動選択」と表示されていても、最終的にどの出口が使われているか確認してください。クライアントの遅延テストを実行し、別のノードに切り替えて同じWebサイトにアクセスします。

遅延テストに成功しても、Webサイトが開けるとは限らない

遅延テストでは通常、設定されたテスト先にアクセスします。その時点でテスト先に到達できたことしか確認できません。ノードによってはテストに成功しても特定のWebサイトにアクセスできない場合があり、逆にテスト先へのアクセスが制限されているためにタイムアウトと表示されることもあります。遅延の数値だけで総合的な利用可否を判断しないでください。

  1. アクセス先のURLを一つ決め、ノードA、ノードBの順にテストします。ほかの設定は変えないでください。
  2. ログに接続タイムアウト、認証失敗、TLSハンドシェイク失敗、接続リセットが記録されていないか確認します。
  3. 特定のノードだけ失敗する場合は、まずそのノードを変更します。すべてのノードで失敗する場合は、ローカルのプロキシ接続先と設定を続けて確認してください。

ノードを変更して直った場合は、まず利用可能なノードを維持し、DNSはすぐに変更しないでください。認証エラーではサブスクリプションやノードのパラメーターを確認します。TLSエラーはシステム時刻、サーバー証明書、通信経路が原因の可能性もあります。証明書検証を無効にする方法を、一般的な解決策として使わないでください。

手順4：システムプロキシが実際に有効か確認する

ノードを利用するには、ブラウザーの通信がまずローカルのプロキシポートに届く必要があります。Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシのアドレスとポートを確認します。macOSでは「システム設定」→「ネットワーク」→使用中のネットワークの「詳細」→「プロキシ」を開き、HTTPおよびHTTPSプロキシを確認してください。クライアントでシステムプロキシを有効にした後は、OSに実際に反映された設定を確認します。

ブラウザーの拡張機能がシステム設定を上書きする場合があります。また、Firefoxではプロキシ方式を個別に設定できます。Firefoxでは「設定」→「一般」→「ネットワーク設定」→「接続設定」を開き、「システムのプロキシ設定を利用する」を選択して、プロキシを変更する拡張機能を一時的に無効にして確認します。

明示的なプロキシ指定で切り分ける

以下のコマンドでは、ブラウザーがシステムプロキシを使っているかどうかに左右されず、curlからローカルのHTTPプロキシへの接続を明示します。Windowsでは curl.exe、macOSとLinuxではコマンド名を curl に変更してください。接続先のWebサイトはテスト用で、必ずアクセスできるとは限りません。

curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com
  • 接続先からHTTPレスポンスが返る：今回の明示的なプロキシ接続で、接続先まで到達できています。403が返った場合も、ローカル接続の失敗とは区別してください。
  • 200 Connection establishedのみ表示される：プロキシのトンネルが確立しただけの可能性があります。その後、接続先からレスポンスが届いているか確認してください。
  • 127.0.0.1に接続できないと表示される：まずポートとコアの起動状態を確認し、手順7に進んでください。

コマンドでは成功するのにブラウザーで失敗する場合は、ブラウザーのプロキシ設定、拡張機能、キャッシュされた接続を確認します。設定全体を書き直す必要はありません。

手順5：グローバルモードとルールモードを比較する

「グローバル」モードに切り替え、グローバル用のポリシーでテスト済みのノードを明示的に選択して、同じURLを開きます。グローバルモードでは開けるのにルールモードでは失敗する場合、ノードが無効だと判断する前に、ルールのマッチ、グループの選択、または直接接続の経路を確認してください。テスト後は元のルールモードに戻します。

接続ログで実際の通信先を確認する

「接続」画面を開いてWebページを再読み込みし、対象ドメインの接続を探します。マッチしたルール、ポリシーの経路、最終的な接続先を確認してください。ルールに DIRECT が適用されると直接接続し、REJECT が適用されると通信が拒否されることがあります。ルールは通常、上から順に評価されるため、前方の広い範囲に適用されるルールによって、後方の詳細なルールが使われない場合があります。

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,PROXY

以下はルールの順序を示すだけの例です。example.com とそのサブドメインは直接接続し、それ以外の通信は PROXY に渡します。完全な設定ではなく、PROXY という名前のノードまたはポリシーグループが定義されている場合にのみ使用できます。このままサブスクリプション設定に上書きしないでください。サブスクリプションの更新で手動変更が上書きされる場合もあるため、クライアントのオーバーライド機能を使うのがおすすめです。

手順6：DNSの名前解決失敗とプロキシ接続失敗を区別する

ブラウザーに「サーバーが見つかりません」と表示される、ログに no such host が記録される、または名前解決がタイムアウトする場合は、DNSを調べる価値があります。ノードのサーバーへの接続失敗がログに明記されている場合は、ノードサーバーのホスト名が解決できるかも確認してください。アクセス先のDNSだけに注目しないようにしましょう。

  • まずローカルの名前解決を確認：ターミナルで nslookup example.com を実行し、タイムアウトの有無と使用されたDNSサーバーを確認します。これはその問い合わせ経路の結果であり、mihomo内部のDNSを測定した結果ではありません。
  • 次にコアのログを確認：ノードのホスト名と接続先のドメインのどちらで名前解決に失敗しているかを確認し、DNSの上流サーバーに到達できるか調べます。
  • ブラウザーのセキュアDNSを確認：ブラウザー内蔵のDoHが別の名前解決経路を使っている場合があります。一時的にオフにして比較テストし、結果を記録したうえで設定を判断してください。

fake-ipモードでは、クライアントがアプリに 198.18.0.0/16 の範囲から割り当てたアドレスを返す場合があります。このアドレスプールを採用した設定では、これだけで名前解決が壊れているとは限りません。該当する通信がコアに届いているか、正しい接続先ドメインに復元できているかも確認してください。

DNSの上流サーバーを一度にすべて変更したり、fake-ipを有効にすれば必ず直ると考えたりしないでください。DoHのアドレス自体にも到達できる必要があります。誤ったブートストラップDNSやプロキシへの依存によって、ループが発生することもあります。一度に変更するのは一項目だけにし、元に戻せるよう設定を保存してください。

Windowsでは、設定を修正した後に ipconfig /flushdns を実行してシステムのDNSキャッシュを消去し、ブラウザーを再起動してテストできます。キャッシュを消去できるのは古いレコードだけで、到達できない上流サーバーは修復できません。

手順7：7890番ポートとコアの起動ログを確認する

mixed-port では、同じ待ち受けポートでHTTPとSOCKS5のプロキシ要求を受け付けられます。7890はよく使われる例で、すべてのクライアントに共通する固定値ではありません。コアが起動していない場合、画面上のスイッチがオンでも実際の待ち受けサービスの代わりにはなりません。

ポートを使用しているプロセスを確認する

# Windows：コマンドプロンプトで実行
netstat -ano | findstr :7890

# macOS：TCPを待ち受けているプロセスを確認
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux：TCPの待ち受け状態を確認
ss -ltnp 'sport = :7890'

Windowsの出力から、ローカルポートが7890で、状態が LISTENING の行を探します。最後の列に表示されたPIDを、タスクマネージャーの「詳細」タブにあるプロセスと照合してください。リモートポートや確立済みの接続が表示されても、ローカルのプロキシが待ち受けているとは限りません。Linuxでは、他のユーザーのプロセス情報を確認する際に追加の権限が必要な場合があります。

  • ポートが待ち受けていない：ログで設定の解析エラー、起動失敗、権限に関するメッセージを確認します。
  • ほかのプログラムが使用中：プロセスを確認して競合するプログラムを終了するか、クライアントの混合ポートを未使用の番号（例：7891）に変更します。
  • ポートを変更した後：システムプロキシを再度有効にし、ブラウザーの手動設定とテストコマンドも更新します。古いポートに接続し続けないようにしてください。

正体のわからないシステムプロセスを安易に終了したり、ローカル接続のために「LAN内からの接続を許可」を有効にしたりしないでください。ブラウザーから 127.0.0.1 に接続するのに allow-lan は不要です。LANからの接続を許可すると、アクセス可能な範囲が広がります。

手順8：TUN、ほかのVPN、セキュリティソフトを切り分ける

明示的なプロキシ接続テストは成功するのに、TUNを有効にするとアクセスできない場合は、仮想ネットワークアダプター、ルーティング、DNSの制御を確認します。TUNはより多くのアプリの通信を取り込む機能であり、システムプロキシの不具合を補うために必ず有効にするものではありません。Clashの派生版によって機能が異なるため、現在のクライアントで使われているmihomoコアと画面上の設定項目に沿って確認してください。

  1. 基準となる状態を確認：TUNをオフにし、システムプロキシだけを有効にして、ブラウザーが使えるか確認します。
  2. TUNだけでテスト：システムプロキシをオフにしてからTUNを有効にします。クライアントの案内に従ってサービスをインストールするか必要な権限を付与し、コアのログでネットワークアダプターやルーティングのエラーを確認してください。
  3. 競合する通信制御を一時停止：ほかのVPN、ゲーム用通信高速化ツール、ルートを変更するアプリを一時的に切断します。会社の端末では、先に管理者へ相談してください。
  4. セキュリティソフトの記録を確認：具体的なプログラムのブロックやネットワーク遮断の記録を探し、信頼できるクライアントに必要なルールだけを設定します。ファイアウォールを長時間オフにしないでください。

システムプロキシは正常でTUNだけに問題がある場合は、システムプロキシを使いながら、権限、ルートの競合、DNSの乗っ取り設定を確認できます。特定のアプリだけが失敗する場合は、そのアプリがシステムプロキシに従うか、UDPを使用しているか、選択中のノードが該当する通信に対応しているかを確認してください。パソコン全体がオフラインだと判断する必要はありません。

復旧しない場合：再現できる情報をまとめる

問い合わせの際は、OSのバージョン、クライアントとコアのバージョン、障害の発生時刻、実際の待ち受けポートに加えて、「直接接続」「明示的なプロキシ接続」「ルールモード」「グローバルモード」「TUN」それぞれのテスト結果を伝えてください。ログは失敗の直前と直後の関連行だけを抜き出し、サブスクリプションURL、アクセストークン、ノードの認証情報、個人のネットワーク情報は伏せてください。

8段階の確認で目指すのは、問題の範囲を絞り込むことです。直接接続が失敗するならネットワークを確認し、明示的なプロキシ接続が失敗するならポートとノードを調べます。グローバルモードでは成功してルールモードで失敗するなら振り分けを確認し、TUNだけ失敗するなら通信の取り込み経路を調べてください。復旧したらルールモードに戻し、一時的なデバッグ設定を解除して、普段使うWebサイトやアプリが正常に接続できるか確認します。

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