Clashに接続済みなのにWebページが開けない原因と対処法｜システムプロキシ・DNS・ルールの確認

クライアントの起動状態とWeb接続を切り分ける

Clashクライアントの「接続済み」は、コアが起動している、設定が読み込まれた、またはモバイル端末でVPNインターフェースが確立したことを示す場合があります。アクセス先のWebサイトから正常な応答があったという意味ではありません。ノードに遅延時間が表示されていても、テスト先に指定されたアドレスへその経路で接続できたことを示すだけで、問題が起きているWebサイトの接続確認にはなりません。

確認用に、直接アクセスできるWebページと実際に開けないWebページをそれぞれ用意します。一度に変更する設定は一つだけにし、ブラウザのエラー、リクエスト時刻、接続ログを記録してください。こうすることで、変更後にたまたま直ったのか、特定の層に問題があるのかを切り分けられます。

まず設定を記録：現在の設定名、動作モード、混合ポート、選択中のプロキシグループ、システムプロキシとTUNの有効状態を控えておきます。
まず基本のネットワークを確認：クライアントが制御しているシステムプロキシとTUNを一時的にオフにし、直接アクセスできるか確認します。ホテル、学校、公共Wi-Fiでは、先にログイン認証が必要な場合があります。
複数の通信制御ツールを同時に使わない：ほかのVPN、プロキシソフト、ブラウザ拡張機能によって通信経路が変わることがあります。一つずつ無効にして確認し、終わったら元の設定に戻してください。
実際に使われているコアを確認：クライアントの「バージョン情報」画面や起動ログで、mihomoが使われているか確認します。メニューやDNS項目、TUN機能はクライアントやコアによって異なります。

第1段階：ブラウザの通信がローカルプロキシに届いているか確認

システムプロキシの設定とローカルの待ち受けを確認

システムプロキシは、プロキシ設定に従うアプリの通信に使われます。すべてのプログラムを自動的に経由させるものではありません。Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」で手動プロキシを確認できます。macOSでは「システム設定」→「ネットワーク」→使用中のネットワークサービス→「詳細」→「プロキシ」を確認してください。項目名はOSのバージョンによって異なる場合があります。

同じPC上のHTTPプロキシには通常、127.0.0.1と実際の混合ポートを指定します。自動プロキシ設定スクリプトを使っている場合は、PACのURLが現在のクライアントから引き続き提供されているか確認してください。ブラウザ独自のプロキシ拡張機能や、Firefoxの個別接続設定がシステム設定を上書きすることもあります。

まずコマンドラインでローカルポートを明示し、システムプロキシの自動検出を介さずにテストします。以下のコマンドは今回のリクエストだけに適用され、システム設定は変更しません。Windowsではcurlが別のコマンドのエイリアスとして扱われる環境があるため、curl.exeを使ってください。

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

# Windows PowerShell
curl.exe -I -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

ここでのexample.comは、コマンド例に使用している実在のドメインです。実際のトラブルシューティングでは、開けないWebサイトでも同じテストを行ってください。-IはHEADリクエストを送信します。403や405が返ってきてもHTTP応答を受け取れたことは示しますが、Webページ全体が正常に読み込まれるとは限りません。

テスト結果	まず確認すること	次の手順
127.0.0.1:7890への接続が拒否される	ポートが待ち受けていない、コアが起動していない、またはポート番号が違う	起動ログと実際の待ち受け設定を確認する
明示的なプロキシ経由では応答があるが、ブラウザでは失敗する	システムプロキシが適用されていない、またはブラウザ独自のプロキシ設定がある	プロキシ拡張機能、PAC、ブラウザの接続設定を確認する
ローカルプロキシには接続できるが、その後タイムアウトする	入口までは接続できているため、名前解決、ルール、または出口に問題がある可能性がある	時刻を手がかりにコアの接続ログを確認する
407応答が返る	プロキシで認証が求められている	ローカルプロキシの認証設定とリクエストの認証情報を確認する

スイッチの状態だけでなく接続一覧で確かめる

クライアントの接続一覧を開き、問題のWebページを更新して、同じドメインまたは接続先IPが記録されるか確認します。通常、システムプロキシ経由のリクエストは接続ログに表示されます。新しい記録がまったくない場合は、まずブラウザからプロキシまでの経路を確認してください。DNSの設定はまだ変更しないでください。TUNが有効な場合、プロキシを明示しないコマンドも制御されることがあります。「プロキシを指定していない」ことは、クライアントを経由していない証拠にはなりません。

第2段階：端末、コア、プロキシ側のDNS名前解決を切り分ける

WebページにERR_NAME_NOT_RESOLVEDと表示される場合、どこでドメイン名を解決しているか確認します。ブラウザがセキュアDNSを使う場合もあれば、OSがルーターに問い合わせる場合や、mihomoが独自の上流DNSを使う場合もあります。プロキシプロトコルによっては、ドメイン名の処理をリモート側に委ねることもあります。それぞれの経路で結果が異なる場合があります。

まずシステムの名前解決を確認し、プロキシ経由のリクエストと比較する

# example.com を実際に問題が起きているドメイン名に置き換える
nslookup example.com

# SOCKS5：接続先ドメイン名をローカルで名前解決する
curl -I -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy socks5://127.0.0.1:7890 https://example.com/

# SOCKS5h：接続先ドメイン名の処理をSOCKSプロキシに任せる
curl -I -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy socks5h://127.0.0.1:7890 https://example.com/

Windowsでは、後半の2つのコマンドもcurl.exeで実行します。混合ポートはHTTPとSOCKSの両方を受け付けます。HTTP専用ポートしか設定されていない場合は、実際のSOCKS待ち受けポートに置き換えてください。socks5hは接続先のドメイン名をローカルのSOCKSプロキシに渡す指定です。その後、コアとリモートのどちらで名前解決されるかは、ルールと出口のプロトコルによって異なります。

ローカルでの名前解決は失敗し、プロキシ経由なら成功する：システムDNSとブラウザのセキュアDNSを優先して確認します。両者で異なるネットワーク経路が使われていないかも調べてください。
どちらのリクエストも失敗する：DNSが原因とは限りません。名前解決のタイムアウト、ルールの判定、出口への接続失敗がコアに記録されていないか確認してください。
システムでの名前解決は成功するが、ブラウザでエラーが出る：ブラウザのセキュアDNSを確認します。システムのDNSで取得した結果が使われていない可能性があります。

fake-ipとDNSハイジャックの注意点

mihomoのfake-ipモードでは、クライアントのDNSがマッピング用アドレスを返すのは通常の動作です。一般的なデフォルト範囲は198.18.0.1/16です。このアドレスだけを根拠に、DNSが改ざんされたと判断しないでください。重要なのは、その後の接続も同じコアに処理され、コア側にドメイン名との対応が保持されているかどうかです。

システムがfake-ipを取得していても、TUNや関連するルートが無効になっていると、アプリからそのアドレスにアクセスできない場合があります。まず一貫した通信経路に戻してから、キャッシュの削除を検討してください。DNSを変更した後、Windowsではipconfig /flushdnsを実行します。macOSでは次の2つのコマンドを実行し、既存の接続を切断してから再テストしてください。

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

第3段階：ルールの判定とプロキシグループの選択を確認

通信がコアに入り、ドメイン名も解決できていても、ルールによって誤った出口に送られることがあります。Clash形式のルールは通常、上から順に評価され、最初に一致したルールが適用されます。末尾のMATCHは、それより前のルールに一致しない場合のフォールバックです。プロキシグループ名を見るだけでは、リクエストが実際にどのノードを通ったかは分かりません。

現在のモードがグローバルモードではなく、ルールモードになっていることを確認します。グローバルモードではグローバルプロキシの選択が使われ、短時間の比較には役立ちますが、それだけで故障原因を判断するのは避けてください。
接続の詳細で問題のドメインを探し、一致したルールの種類と内容、プロキシの選択経路を記録します。
ルールの接続先がDIRECT、REJECT、またはプロキシグループのどれかを確認します。プロキシグループの場合は詳細を開き、最終的に選択されている実際のノードを確認してください。
そのWebサイトの既存の接続を切断してからページを更新します。通常、確立済みの接続はプロキシの選択を切り替えても、すぐに新しい出口へ移行しません。

以下はルールの順序を示す最小限の例で、そのまま実行できる完全な設定ではありません。特定のホストを拒否し、それ以外のリクエストは直接接続する例です。実際の設定では、実在するドメイン名や使用中のプロキシグループを指定し、必要な通信の振り分け方に合わせてください。

rules:
  - DOMAIN,blocked.example.com,REJECT
  - MATCH,DIRECT

MATCH,DIRECTを先頭に置くと、後続のドメインルールはこれらのリクエストに適用されません。ルールセットも順序と読み込み状況を確認してください。サブスクリプションの更新に成功したことは、設定を取得できたことを示すだけで、すべてのリモートルールセットのダウンロード成功を意味しません。

一時的にグローバルモードへ切り替えて原因を絞り込む

一時的にグローバルモードへ切り替え、ノードを明示的に選択して同じWebページにアクセスします。ルールモードでは失敗しグローバルモードでは成功する場合、接続の詳細に戻り、ルールの判定結果の違いを確認してください。どちらのモードでも失敗する場合は、出口を調べます。確認後は元のモードに戻し、ほかのアプリにまで影響を広げないようにしてください。グローバルモードで成功しても名前解決の経路が変わった可能性があるため、ログもあわせて確認します。

第4段階：出口ノードと接続先サイトを確認

ノードの遅延テストは通常、設定されたテストURLへの接続を確認します。成功しても、すべてのWebサイト、ポート、UDP通信が使えるとは限りません。ブラウザでのアクセスにはメインサイトのほか、ログイン用や画像用など複数のドメインへのリクエストが含まれることがあります。一つのリソースが失敗しただけでも、画面が真っ白になったり読み込みが終わらなくなったりします。

2つのノードを比較：問題のドメイン、プロキシの入口、動作モードは同じに保ち、最終ノードだけを切り替えます。切り替え後、そのドメインの既存接続を切断してから再試行してください。
サブスクリプションの状態を確認：プロバイダーの画面で有効期限、通信量、ノードの状態を確認します。更新後、実行中の設定が新しい内容に切り替わっているかも確認してください。
システム時刻を確認：時刻のずれはTLS証明書の検証に影響し、時刻に依存する認証にも支障をきたす場合があります。まずシステムの時刻を自動設定にし、エラーが解消するか確認してください。
プロトコルの互換性を確認：未対応のプロキシ形式、暗号方式、設定項目に関するエラーが出たら、使用中のコアが対応しているか確認してください。クライアントでサブスクリプションをインポートできても、コアがすべてのノードを正常に起動できたとは限りません。

ログのconnection refusedは、接続先から拒否されたか、ポートが待ち受けていない可能性を示します。i/o timeoutは処理がタイムアウトしたことを示すだけで、DNS、回線、リモート側のどれが原因かは特定できません。x509関連のエラーは、証明書のドメイン名、有効期間、システム時刻を照らし合わせて確認してください。問題を隠すためにTLS証明書の検証を無効にしないでください。

特定のWebサイトだけで403、地域制限、認証画面が表示され、ほかのページは正常に開ける場合、HTTP応答を受け取る段階までは進んでいます。サイト側の制限や出口の条件を確認してください。この段階でローカルの混合ポートを何度も変更しても、通常は解決しません。

TUNモードとブラウザだけで起きる問題の追加確認

システムプロキシでは接続できるが、TUNを有効にすると失敗する

TUNは仮想ネットワークインターフェースを使って通信を制御するため、権限、ルーティング、DNSが関係します。プロキシを明示したテストは成功し、TUNを有効にしたときだけ通信できなくなる場合は、サブスクリプションを再インポートするのではなく、これらの項目を優先して確認してください。インターフェースの作成失敗、権限不足、ルート設定の失敗、DNSリクエストのタイムアウトがログにないか調べます。

mihomoの設定では、tun.auto-route、tun.auto-detect-interface、tun.dns-hijackは、それぞれ自動ルート設定、出口インターフェースの検出、DNSハイジャックに関係します。具体的な動作はプラットフォームやクライアントの実装によって異なります。Wi-Fiの切り替え、有線LANの抜き差し、別のVPNへの接続後は、以前の出口インターフェースやルートが使えなくなっている場合があります。ログを保存してからTUNを再起動し、同じリクエストで結果を比較してください。

コマンドラインでは接続できるが、ブラウザだけ開けない

ブラウザのプロキシ拡張機能を一時的に無効にします。Firefoxでは「設定」→「一般」→「ネットワーク設定」を開き、独自のプロキシが指定されていないか確認してください。
ブラウザのセキュアDNSを確認します。比較のために短時間だけ無効にし、確認後は元の設定に戻してください。コアのDNS設定を同時に変更しないでください。
開発者ツールの「ネットワーク」パネルを開き、失敗しているのがメインのドキュメントか、スクリプト、画像、ログインAPIのいずれかを確認します。
ログにUDPやQUICの経路が示されている場合は、まず通常のHTTPSリクエストをコマンドラインから実行して比較します。HTTPリクエストが成功しても、ノードがUDPに対応しているとは限りません。

Androidでは、クライアントのアプリ別プロキシ設定が有効か、対象のブラウザが除外リストに入っていないかも確認します。システムの「プライベートDNS」によって、想定とは異なる名前解決経路が使われる場合もあります。モバイル端末のVPNアイコンはインターフェースが存在することを示すだけなので、実際のリクエストとクライアントのログで確認してください。

設定を元に戻し、再現可能な確認記録を残す

確認が終わったら、一時的に変更したグローバルモード、ブラウザ設定、ログレベルを元に戻してください。クライアントの開発者やプロバイダーに問い合わせる際は、「接続済みなのにネットに繋がらない」というスクリーンショットだけでなく、再現できる手順を伝えると役立ちます。

OS、クライアント、コアの実際のバージョンと、システムプロキシおよびTUNの有効状態を記録します。
影響範囲を明記します。すべてのWebサイトか、特定のサイトか、特定のブラウザか、TUNモードだけかを整理してください。
HTTPプロキシを明示したテスト結果、DNSの比較結果、ルール判定、最終的な出口ノードの種類を添えます。
同じリクエストの前後に記録された関連ログを添付します。共有する前に、サブスクリプションURL、認証情報、コントロールインターフェースのキー、個人のアクセス履歴を隠してください。

設定項目を確認する場合は、サイト内の上級設定をご覧ください。インストールや使い方に関するよくある質問は、ヘルプセンターから検索できます。