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

Clash接続中なのにWebサイトが開けない原因と対処法｜ポート・ルールの確認

Clashは接続済みなのにブラウザーで開けない場合は、システムプロキシ、ポート競合、モード、ルール、DNSの順に確認しましょう。

まず切り分ける：コアの起動、ノードの速度測定、Webサイトへの接続

Clashクライアントに「接続済み」と表示されたり、サービスが実行中になったりしても、確認できるのは動作の一部が開始していることだけです。ブラウザーのリクエストは、アプリのプロキシ設定、ローカルの待ち受けポート、ルール選択、ノード接続、接続先サイトを経由します。ノードの速度測定でミリ秒単位の値が表示されても、その時点で測定先に接続できたことを示すだけで、すべてのサイトやプロトコルが使えるとは限りません。

この記事では、デスクトップクライアントとmihomoコアの一般的な組み合わせを前提に説明します。設定項目の名称はクライアントによって異なるため、画面に表示された待ち受けポートと有効な設定を基準に確認してください。まずクライアント名、バージョン、コアのバージョン、使用中の設定名、問題が起きた時刻を記録しましょう。最初からクライアントの再インストール、サブスクリプションの変更、DNSの変更を同時に行うのは避けてください。

再現性のある3つの確認項目

  • 影響範囲：すべてのサイトで失敗するのか、特定のドメインだけか。ブラウザーだけの問題か、ターミナルやほかのアプリでも失敗するのかを確認します。
  • 通信の入口：システムプロキシ、ブラウザーのプロキシ拡張機能、TUNモードのどれを使っているか、別のVPNも起動していないかを確認します。
  • 発生時の記録：ページを再読み込みし、クライアントの「接続」一覧で対象ドメインを探します。「ログ」では同じ時刻のエラーを確認します。

ステップ1：ブラウザーがシステムプロキシを使っているか確認する

Clash Verge Revの一般的な画面を例に、「設定」→「システムプロキシ」でスイッチを確認し、OS側でも実際のプロキシアドレスを確認します。クライアントでノードを選択しただけでは、すべてのアプリがそのノードを使うわけではありません。また、システムプロキシはOSの設定に従わないアプリの通信を制御できません。

  1. クライアント画面で実際の「混合ポート」を確認します。たとえば画面に7897と表示されている場合、ローカルのプロキシアドレスは127.0.0.1:7897です。ほかのクライアントでは7890などの場合もあるため、既定値をそのまま使わないでください。
  2. Windows 11では、「設定」→「ネットワークとインターネット」→「プロキシ」を開き、「プロキシサーバーを使う」のアドレスとポートを確認します。自動構成スクリプトが同時に設定されていると、実際の通信経路に影響することがあります。
  3. macOSでは、「システム設定」→「ネットワーク」→接続中のネットワーク→「詳細」→「プロキシ」を開き、Webプロキシと保護されたWebプロキシが想定したアドレスを指しているか確認します。
  4. Firefoxでは、「設定」→「一般」→「ネットワーク設定」→「設定」を開き、システムプロキシを使う設定か、手動プロキシの内容を確認します。ほかのブラウザーでも、プロキシ拡張機能がシステム設定を上書きする場合があります。

切り分けの際は、まずブラウザーのプロキシ拡張機能を一時的に無効にし、通信の入口を1つに絞ってください。HTTP混合ポートをSOCKS専用ポートに設定したり、コントローラーポートを通信の入口に使ったりしないでください。external-controllerは管理用インターフェースであり、Webリクエストのプロキシには使いません。

ブラウザー設定を介さず、プロキシを指定してリクエストする

混合ポートが実際に7897の場合、Windows PowerShellで次のコマンドを実行します。PowerShell環境によっては同名のエイリアスが引数の解析に影響するため、ここではcurl.exeを使います。macOSとLinuxではコマンド名をcurlに置き換えてください。

curl.exe --noproxy "" --proxy http://127.0.0.1:7897 --connect-timeout 10 --max-time 20 -I https://example.com/

次にテスト用URLを、実際に開けないサイトのURLに置き換えます。プロキシを明示したリクエストは成功するのにブラウザーでは失敗する場合、まずブラウザー拡張機能、システムプロキシ、キャッシュされた接続、ブラウザー独自のセキュアDNSを確認してください。すぐにノードを変更する必要はありません。403や405が返る場合はHTTPレスポンスを受信できていますが、サイトがアクセスやHEADリクエストを制限している可能性があります。-Iを外して比較し、プロキシに接続できていないと即断しないでください。

ステップ2：混合ポートの待ち受けとポート競合を確認する

プロキシを明示したリクエストですぐに127.0.0.1へ接続できないと表示される場合は、まずローカルの待ち受けを確認します。この時点ではリクエストがまだノードに届いていないため、通常、リモートサーバーを切り替えても解決しません。WindowsではPowerShellで次を実行します。

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

結果に表示されたプロセスIDをGet-Process -Id 1234に入力し、そのポートを使用中のプロセスが現在のコアか確認します。ここでの1234はコマンド形式の例なので、実際の検索結果に置き換えてください。macOSでは次のコマンドで待ち受けプロセスを確認できます。

lsof -nP -iTCP:7897 -sTCP:LISTEN
確認結果よくある原因次の手順
待ち受けが見つからないコアが起動していない、設定の読み込みに失敗した、またはポートの指定が誤っている起動ログと実際の混合ポートを確認する
別のプロキシがポートを使用中古いクライアントやバックグラウンドサービスがまだ動作している該当プログラムを正常に終了し、通信の入口を1つにする
IPv6のループバックアドレスだけで待ち受けている待ち受けアドレスとリクエストの接続先が一致していない有効な設定とクライアントの待ち受け設定を確認する
待ち受けは正常だがリクエストがタイムアウトするリクエストがコアに入った後の経路に問題があるモード、プロキシグループ、ログを引き続き確認する

ポートを変更する場合は、未使用のポートを選びます。たとえば7897から17897に変更し、コアに設定を再読み込みさせます。その後、システムプロキシ、ブラウザー拡張機能、ターミナルのHTTP_PROXY、HTTPS_PROXY、ALL_PROXYもあわせて確認してください。クライアントだけ変更して古い接続先を残すと、誤ったポートへの接続が続きます。

ステップ3：ルールモードとグローバルモードを比較する

ローカルの接続口が正常なことを確認したら、クライアントの「プロキシ」画面でモードを確認します。ルールモードではルールに応じて使用するポリシーが決まり、グローバルモードではグローバルポリシーの選択が使われます。直接接続モードではプロキシノードを経由しません。これらは通信の振り分け方であり、システムプロキシやTUNモードの有効・無効とは別の設定です。

  1. ルールモードで対象サイトにアクセスし、接続の詳細に表示されるルール、プロキシグループ、最終ノード、エラー情報を記録します。
  2. 短時間だけグローバルモードに切り替え、グローバルポリシーで利用可能なノードを明示的に選びます。グローバルポリシーがDIRECTまたはREJECTのままでは、比較になりません。
  3. 同じサイトに再度アクセスします。グローバルモードでは使えてルールモードでは使えない場合は、ルールとその適用先のプロキシグループを重点的に確認します。
  4. テスト後は元のルールモードに戻し、一時的な診断設定をそのまま使い続けないようにします。

どちらのモードでも失敗する場合は、ログにノード接続のタイムアウト、認証失敗、TLSハンドシェイク失敗、証明書エラーがないか確認します。別のノードでも比較できますが、対象URLとテスト方法は変えないでください。ノードの速度測定が成功して実際のサイトには接続できない場合、出口側の制限、接続先サイトの制限、ノードのプロトコル設定が原因の可能性があります。遅延値だけを根拠にノードの問題を否定することはできません。

ステップ4：ルールの順序、プロキシグループ、最終的な出口を確認する

mihomoのルールは通常、上から順に照合され、最初に一致したルールのポリシーが実行されます。ドメインに先に一致したルールが直接接続や拒否へ振り分けると、後ろにある正しいルールは適用されません。設定に対象ドメインが含まれているか検索するだけでなく、「接続」の詳細に表示される実際の適用結果を基準に確認してください。

設定を変更する前に接続の詳細を確認する

  • DIRECTに一致：想定どおりの直接接続か、範囲の広すぎるドメインサフィックスルールやIPルールが先に一致していないかを確認します。
  • REJECTに一致：ブロックルールや外部ルールセットを確認し、サイトの表示に必要なリソースのドメインも拒否されていないかを確認します。
  • プロキシグループに一致：グループ内の選択先をさらに確認します。グループ名が「プロキシ」でも、最終的にリモートノードが使われるとは限りません。直接接続や別のグループが選ばれている場合もあります。
  • MATCHに到達：フォールバックポリシーを確認します。通常、前のルールでリクエストがカバーされていないことを示します。

次の例はルールの順序を示すもので、サブスクリプションの代わりに使える完全な設定ではありません。参照しているPROXYは、現在の設定に対応するノード名またはプロキシグループ名が必要です。

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,LAN,DIRECT
  - MATCH,PROXY

実際のサイトでは、ログイン、静的リソース、APIの各ドメインに同時にリクエストすることがよくあります。トップページのHTML取得は成功しても表示が読み込み中のままなら、APIのドメインが別のルールに一致している可能性があります。ブラウザーの開発者ツールで「ネットワーク」パネルを開いて失敗したリクエストのドメインを特定し、クライアントの接続一覧で該当する記録を探してください。

サブスクリプションの更新によって、直接編集した内容が上書きされることがあります。ルールを継続的に調整する場合は、クライアントのオーバーライド、マージ、拡張設定機能を使い、変更が有効な設定に反映されていることを確認してください。サブスクリプションに含まれるノードやプロキシグループを、Web上のサンプルで丸ごと置き換えないでください。

ステップ5：システムDNSとmihomoのDNSを分けて確認する

DNSの問題は、ドメイン名の名前解決がタイムアウトする、失敗する、または接続に使えない結果が返るといった形で現れます。まず、システムのリゾルバー、ブラウザーのセキュアDNS、コアのDNS、リモートプロキシサーバーのどこが名前解決しているかを確認します。それぞれ同じ経路を通るとは限らないため、nslookupを一度実行しただけでは、プロキシ経路全体が正常とは判断できません。

通信の入口ごとに名前解決結果を比べる

  1. nslookup example.comを実行し、システムが使用しているDNSサーバーと応答を記録します。次に、実際に問題が起きるドメインでも同じテストを行います。
  2. クライアントのログで対象ドメインを検索し、コアのDNSクエリが失敗しているのか、名前解決後にノードへの接続が失敗しているのかを確認します。
  3. ブラウザーだけで問題が起きる場合は、現在の設定を記録してから、ブラウザーの「セキュアDNS」を一時的に変更して比較します。テスト後は設定を元に戻すか、有効だと確認できた設定を維持してください。
  4. 設定で暗号化DNSを使っている場合は、DNSサーバー自体に接続できるか確認します。現在のネットワークから到達できないアドレスをDNSサーバーに指定すると、新たなタイムアウトが発生するだけです。

SOCKSでテストする場合は、socks5://とsocks5h://の違いも確認しましょう。curlでは後者を使うと、プロキシ側で接続先ドメインが名前解決されます。現在のポートがSOCKSに対応している場合は、次のリクエストを比較できます。

curl.exe --noproxy "" --proxy socks5h://127.0.0.1:7897 --connect-timeout 10 --max-time 20 -I https://example.com/

リモートで名前解決する方法では成功し、ローカルでの名前解決では失敗する場合は、まずローカルDNSの経路を確認してください。ただし、どちらの方法で成功したかだけで原因を断定せず、接続ログもあわせて確認します。

Windowsでは、関連設定を修正した後にipconfig /flushdnsを実行してシステムのDNSキャッシュを消去し、ブラウザーを終了して再起動できます。キャッシュの消去は最後の処理であり、誤ったDNS上流、ルーティング、DNS書き換えの設定を直す代わりにはなりません。

ステップ6：TUN、ルーティング、ほかのVPNを個別に確認する

プロキシを明示したHTTPリクエストではアクセスできるのに、TUNを有効にすると失敗する場合は、仮想ネットワークアダプター、ルーティング、DNSを引き継ぐ経路に問題がある可能性が高いです。TUNは仮想ネットワークインターフェースを通じて通信を取り込み、アプリがシステムHTTPプロキシに従う必要はありません。ただし、サービスの権限不足、ルートの競合、別のVPNによるネットワーク設定の変更などで、通信が誤った経路を通ることがあります。

  • クライアントの「設定」でサービスモードや関連サービスが正常か確認し、「TUNモード」のスイッチも確認します。サービス権限が必要なクライアントでは、画面の案内に従ってインストールしてください。
  • ネットワークポリシーで許可されている場合は、TUNを一時的に無効にしてシステムプロキシだけを有効にし、同じブラウザーとURLでテストします。
  • TUNでのみ失敗する場合は、有効な設定のtun.auto-route、tun.dns-hijackなどを確認し、ほかのVPNや仮想ネットワークアダプターとルートが競合していないか調べます。
  • 一部のHTTPSページだけ読み込みが止まる場合は、ログやパケットキャプチャも使ってMTU、IPv6ルートなどを確認してください。任意のMTU値を汎用的な解決策として設定するのは避けましょう。

会社の端末や管理対象ネットワークでは、指定されたVPN、証明書、DNSポリシーが必要な場合があります。その場合は管理者に互換性のある方法を確認し、ネットワーク管理を回避するためにセキュリティ機能を無効化しないでください。個人端末でも、まず重複して動作しているプロキシプログラムを停止してから、残存サービスの削除を検討します。

調査結果の記録と設定の復元確認

ひと通り確認したら、次の結果から続けて調べるべき箇所を絞り込みます。「接続できない」とだけ記録するより、具体的なエラーを残すほうが役立ちます。再起動やサブスクリプション更新後に問題が再現するか確認する際にも使えます。

テスト結果優先して確認する項目記録しておく情報
ローカルプロキシポートへの接続が拒否される待ち受けポートとコアの起動待ち受けプロセス、起動時のエラー
プロキシを明示したリクエストは成功、ブラウザーは失敗システムプロキシとブラウザーの設定システムプロキシの値、拡張機能の状態
グローバルモードは成功、ルールモードは失敗ルールの順序とプロキシグループの選択適用ルール、最終ノード
システムプロキシは成功、TUNは失敗サービスの権限、ルーティング、DNSの引き継ぎTUNのログ、ほかのVPNの状態
特定のWebサイトだけ開けないリソースドメイン、出口制限、サイトの状態失敗したドメイン、HTTPステータス、発生時刻

問い合わせの際は、クライアントとコアのバージョン、OSのバージョン、実際の混合ポート、プロキシモード、TUNの状態、再現手順、同じ時間帯のエラーログをお知らせください。スクリーンショットや設定を共有する前に、サブスクリプションURL、認証情報、コントローラーのAPIキー、個人の閲覧履歴を削除してください。

通常の利用に戻す前に、一時的に有効にしたグローバルモードを元のモードに戻し、ブラウザーやターミナルに古いポート設定が残っていないことを確認します。そのうえで、もともと開けなかったサイトのほか、ログイン、画像、APIリクエストも確認してください。基本設定はClash設定ガイドを参照してください。エラーの種類ごとに調べる場合は、トラブル対処ページをご覧ください。

Clash をダウンロード インストーラーとシステム要件