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

1. 接続状態と実際の通信経路を切り分ける

クライアントに「実行中」「接続済み」と表示されても、通常はコアが起動した、またはシステムのVPNインターフェースが作成されたことを示すだけです。ノードの遅延テストに成功しても、その時点でテスト先に接続できたという意味にとどまります。ブラウザーの通信には、プロキシの入口、ルール判定、プロキシグループの選択、ノードへの接続、ドメイン名の解決が必要です。いずれかの段階で失敗すると、Webページは開けません。

まず現在の設定を保存し、クライアント名、クライアントとコアの名称・バージョンを記録してください。Clashは設定エコシステムで広く使われている名称で、Clash Metaは後にmihomoという名称が使われるようになりました。クライアントによってコアの組み込み方やメニューは異なるため、特定の画面にあるスイッチをすべてのバージョン共通の機能と考えないでください。

まず確認したい3つの基本項目

1. システムプロキシとTUNを一時的にオフにし、普段直接アクセスできるWebサイトを開いてみましょう。それでも接続できない場合は、Wi-Fi、ゲートウェイ、認証ページ、システムのネットワーク設定を先に確認してください。プロキシルールをすぐに変更する必要はありません。
2. 元の設定に戻し、同じURLをブラウザーとコマンドラインの両方でテストします。比較対象をそろえ、異なるWebサイトの接続状況をクライアントの問題と取り違えないようにしましょう。
3. クライアントの「ログ」と「接続」画面を開き、テスト時刻、対象ドメイン、適用ルール、使用したプロキシグループ、エラーの全文を記録します。ログを共有する前に、サブスクリプションURL、パスワード、トークン、ノードの認証情報を伏せてください。

2. システムプロキシとローカルの待ち受けポートを確認する

システムプロキシが適用されるのは、システムのプロキシ設定を参照するアプリです。すべてのプログラムの通信を制御するわけではありません。ブラウザーの拡張機能、Firefox独自のプロキシ設定、ターミナルの環境変数がシステム設定より優先される場合もあります。以下ではHTTPまたはmixedの入口として127.0.0.1:7890を例にします。まず現在の実行設定で実際のポートを確認してください。すべてのクライアントが7890を使うとは限りません。

プラットフォームごとに接続先を確認

• Windows 11：「設定」→「ネットワークとインターネット」→「プロキシ」→「手動プロキシ セットアップ」を開きます。手動プロキシを使う場合は、アドレスとポートがクライアントの設定と一致しているか確認してください。自動構成スクリプトを使う場合はスクリプトのURLを確認し、出所のわからない古いスクリプトを残さないようにします。
• macOS：「システム設定」→「ネットワーク」→現在のネットワークサービス→「詳細」→「プロキシ」を開きます。Webプロキシ、安全なWebプロキシ、自動プロキシ構成を確認してください。Wi-Fiと有線ネットワークを切り替えた後は、現在使っているサービスの設定を確認します。
• Android：Clash系クライアントの多くは、システムのVPNサービスを使って通信を制御します。VPNの許可、アプリごとの振り分け設定、別のVPNが唯一のアクティブなVPN接続を使用していないか確認してください。デスクトップ版の手動プロキシ設定をそのまま適用することはできません。

プロキシを明示して比較する

# Windows PowerShellではcurl.exeを使用。macOS/Linuxではcurlを使用
curl.exe -I --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/
curl.exe -I --connect-timeout 10 --max-time 20 --noproxy "*" https://example.com/

1つ目のコマンドはローカルプロキシを明示し、2つ目は環境変数のプロキシ設定を無視して直接接続を試みます。ドメイン名は説明用なので、確認対象のWebサイトに置き換えてください。1つ目が成功してブラウザーで失敗する場合は、ブラウザーのプロキシ設定元や拡張機能を確認します。Failed to connect to 127.0.0.1と表示されたら、リモートノードではなく、まずローカルの待ち受け状態を確認してください。

HTTPS通信をHTTPプロキシ経由で行う場合、出力に200 Connection establishedと表示されるのは、CONNECTトンネルが確立したことを示すだけです。その後、接続先サイトからのHTTPレスポンスも確認してください。接続先から403や405が返る場合、サーバーの応答は受け取れていますが、ページを正常に閲覧できるとは限りません。HEADリクエストを受け付けないサイトもあるため、-Iを外して再テストしてください。

3. ポート競合と古いプロセスの占有を解消する

画面上でクライアントが開いていても、コアがポートのバインドに成功したとは限りません。2つのクライアントを同時に起動すると、address already in useやbindの失敗がよく起こります。システムプロキシが7890を参照していても、そのポートを占有しているのは古いクライアントや、有効な設定を失ったバックグラウンドサービスかもしれません。

# Windows PowerShell：待ち受けプロセスを確認
Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

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

# Linux：待ち受けプロセスを確認
ss -ltnp 'sport = :7890'

1. 待ち受けプロセスに対応するプログラムを調べ、現在使用中のクライアントか確認します。Windowsではタスクマネージャーの「詳細」タブでPIDを検索できます。
2. 使っていないクライアントとバックグラウンドサービスを正常に終了し、対象のクライアントを再起動します。ポート番号だけを手がかりに、システムのプロセスをむやみに終了しないでください。
3. 7892など別の空きポートに変更する場合は、システムプロキシとテストコマンドも合わせて変更します。変更後、実際に待ち受けているポートを再確認してください。

portは通常HTTPプロキシの入口、socks-portはSOCKSの入口を提供し、mixed-portはHTTPとSOCKSの両方を受け付けます。SOCKS専用ポートにHTTPリクエストを送ると失敗することがあります。external-controllerは制御用インターフェースであり、Webプロキシの入口ではありません。システムプロキシにそのポートを設定しないでください。

4. プロキシグループの選択とルール判定を確認する

サブスクリプションを正常にインポートできても、設定を読み込めたことしかわかりません。ルールが参照するプロキシグループでDIRECT、無効なノード、または別のネストされたプロキシグループが選択されている場合があります。接続の詳細を開き、今回のリクエストに対応するドメインを見つけて、プロキシチェーンの最終的な出口まで確認してください。ホーム画面のノード名だけでは判断できません。

モードを切り替えて原因を絞り込む

1. ルールモードで対象サイトにアクセスし、適用されたルールとポリシーを記録します。通常、ルールは上から順に評価されるため、先にある範囲の広いルールがリクエストを処理してしまうことがあります。
2. 一時的にグローバルモードへ切り替え、GLOBALグループでテスト対象のノードが実際に選択されているか確認します。グローバルモードでもDIRECTが選ばれることがあるため、モード名だけで判断しないでください。
3. Webページを再読み込みして、新しい接続を確認します。グローバルモードでは成功し、ルールモードでは失敗する場合は、ルールの順序、ルールセットの読み込み状況、関連するポリシーグループの選択を確認してください。
4. テスト後はルールモードに戻します。グローバルモードは原因を特定するための手段であり、DNS、無効なノード、ローカルポートの問題を自動で修復するものではありません。

# ルール順序の例：説明用です。サブスクリプション全体を上書きしないでください
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,PROXY

この設定例では、example.comとそのサブドメインへの通信が最初にDIRECTに一致し、最後のルールでそれ以外の通信をPROXYに振り分けます。PROXYは設定内にすでに存在するプロキシまたはプロキシグループである必要があります。対象サイトへのアクセスにプロキシが必要な場合、先にあるDIRECTルールが原因で「ほかのサイトは開くのに特定のサイトだけ開けない」状態になることがあります。

ノードを切り替えたら、テスト接続を新しく確立してください。ブラウザーが接続を再利用し、古い通信経路が使われ続ける場合があります。必要に応じて、該当するアクティブ接続だけを閉じて再試行します。ノードの遅延が表示されても、対象サイトに接続できるとは限りません。また、必要なUDP通信にそのノードが対応していることも保証されません。

5. エラーの種類からDNSと名前解決の経路を確認する

DNS障害では、no such host、lookup failed、名前解決のタイムアウトなどがよく見られます。ただし、i/o timeoutはノードへの接続中や接続先へのアクセス中にも発生するため、ログに記録された対象アドレスと合わせて判断してください。まず、ノードサーバーのドメイン名とWebサイトのドメイン名のどちらで名前解決に失敗しているかを確認します。対処する場所はそれぞれ異なります。

システムDNSとコアのDNSを切り分ける

# システムのデフォルトDNSサーバーを確認
nslookup example.com

# コアが127.0.0.1:1053で実際に待ち受けている場合のみ使用
# digがシステムにインストールされている必要があります
dig @127.0.0.1 -p 1053 example.com A

nslookupが成功しても、別の上流DNSを使っている可能性があるため、コアのDNSが正常とは限りません。失敗しても、プロキシ経由での名前解決が必ず失敗するとは限りません。HTTP CONNECTでドメイン名に接続する場合と、アプリがローカルで名前解決してから接続する場合では、DNSの経路が異なることがあります。

mihomoのDNS設定にあるnameserver、nameserver-policy、proxy-server-nameserverなどの項目は、それぞれ異なる状況に影響します。コアのバージョンごとに対応状況を確認してください。ルールに応じて上流DNSへの接続先を選ぶ設定を有効にしている場合は、「DNSへの接続にノードが必要で、ノードへの接続にはDNSが必要」という循環依存が起きていないかも確認します。別のサブスクリプションにあるDNS設定ブロック全体をそのまま貼り付けないでください。

Fake-IPとブラウザーのセキュアDNS

Fake-IPモードが返す仮想アドレスは、その後のマッピングに使われるもので、Webサイトの実際のIPアドレスではありません。一般的な設定では198.18.0.0/16の範囲が使われます。この範囲のアドレスが表示されても、それだけでDNSが改ざんされているとは限りません。後続の通信が、マッピングを担当する同じコアに届いているか確認してください。実IPアドレスを必要とするアプリで互換性の問題が明確に発生した場合に限り、fake-ip-filterへの個別追加を検討します。

ブラウザーでセキュアDNSが有効になっていると、想定していたシステムの名前解決経路を迂回する場合があります。設定を一時的にオフにして比較し、テスト後は必要な設定に戻してください。DNSを変更した後、Windowsではipconfig /flushdnsを実行してシステムのキャッシュを消去できます。ブラウザーやコアにも個別のキャッシュが残る場合があるため、それぞれ再試行してください。セキュリティ機能を常時無効にすることを一般的な解決策にしないでください。

6. TUNだけで失敗する場合はルーティングと権限を確認する

TUNをオフにして明示的なHTTPプロキシを使うと接続できるのに、TUNをオンにすると失敗する場合は、仮想ネットワークアダプター、システムルート、DNSの制御、ほかのVPNを優先して確認してください。TUNは仮想ネットワークインターフェースとルートを使って通信を取り込みます。対象範囲はルーティングや除外設定に左右されるため、すべてのアプリやプロトコルが自動的に使えるわけではありません。

• 権限：デスクトップクライアントでインターフェースの作成やルートの変更を行うには、通常、管理者権限または補助サービスが必要です。スイッチを何度も押すのではなく、サービスが実行中か確認してください。
• ルーティング：Windowsではroute print、macOSではnetstat -rn、Linuxではip routeを使ってルートを確認します。まず出力を保存し、デフォルトルートを直接削除しないでください。
• インターフェースの選択：有線、Wi-Fi、仮想マシンのネットワークアダプターを同時に接続していると、自動選択される出口が想定と異なることがあります。テスト中は、実際にインターネットへ接続しているインターフェースを1つに絞ってください。
• VPNの競合：企業VPN、ほかのプロキシ、仮想ネットワークツールがルートを書き換えることがあります。許可されている場合は1つずつ終了して比較してください。企業管理下のデバイスでは、管理ポリシーに従ってください。
• プロトコルとMTU：小さなリクエストは成功するのに、大きなページやダウンロードが止まる場合は、UDP、パスMTU、フラグメンテーションの問題を確認してください。根拠がないままstackやMTUの値を変更しないでください。

7. 結果から原因を絞り込み、設定を元に戻す

ここまでの確認結果を、具体的な原因の分岐に整理します。有効なトラブルシューティング記録には、「どの入口から、どの接続先へ、どのモードで試し、どんなエラーが出たか」が記されています。「まだ繋がらない」だけでは十分ではありません。最後の確認には、以下の結果表を活用してください。

修正後はルールモード、元のセキュリティ設定、必要なネットワークインターフェースを復元し、サブスクリプションの更新と普段使うWebサイトを再度テストします。ローカル設定の変更がサブスクリプション更新で上書きされる場合は、クライアントが対応するオーバーライドまたはマージ機能で差分を保存してください。編集画面の元テキストだけでなく、マージ後の実行設定を確認します。

追加のサポートを求める際は、クライアントとコアのバージョン、OSのバージョン、システムプロキシまたはTUNの状態、実際の待ち受けポート、テストコマンド、同じ時間帯の機密情報を伏せたログを共有してください。再現できるリクエストを1つに絞って説明すると、クライアントを再インストールするより原因を特定しやすくなります。