Clashの画面に「接続済み」と表示され、ノードの横に遅延時間が出ていたり、ログが流れ続けていたりしても、ブラウザーの通信が正常にプロキシを経由しているとは限りません。クライアントが完了しているのは、設定の読み込み、遅延測定、コアの起動だけの場合があります。実際にWebページへアクセスするには、アプリ、システムプロキシまたはTUN、Clashの受信ポート、ルール判定、ポリシーグループ、プロキシノード、DNS、対象サイトまでの一連の経路を通る必要があります。どこか一つでも途切れると、表面上は「接続正常なのにWebページが開けない」状態になります。

「インターネットに接続できない」箇所を切り分ける

最初に行うのは、さらに多くのノードへ切り替えることではなく、障害の範囲を確認することです。普段使うWebサイトだけでなく、ローカルネットワークのアドレス、通常のドメイン、IPアドレスへの直接接続も試してください。1つのサイトだけ失敗する場合は、対象サイトの制限、ルール判定、ノードの出口が原因かもしれません。すべてのドメインに接続できない一方でIPアドレスにはアクセスできる場合は、まずDNSを確認します。ブラウザーは使えるのに、ターミナル、ゲーム、ストアが使えない場合は、アプリがシステムプロキシに従っていない可能性が高く、アプリ側でプロキシを設定するかTUNを使用します。

  1. ローカルネットワークを確認：Clashを完全に終了するかシステムプロキシを無効にし、直接接続でWebサイトが正常に開くか確認します。基礎ネットワーク自体が切断されているなら、プロキシを調整しても意味がありません。
  2. アプリごとに比較：ブラウザー、コマンドライン、システムプロキシを参照しないアプリをそれぞれテストします。結果の違いから、問題がアプリのプロキシ設定にあるのか、全体の転送層にあるのかを判断できます。
  3. 接続ログを確認：Webページへアクセスしながら、ログに対象ドメイン、適用されたルール、最終的なポリシーが表示されるか確認します。新しい記録がまったくない場合、通信がClashに入っていない可能性が高いです。
  4. タイムアウトと名前解決エラーを区別：「サーバーのアドレスが見つかりません」はDNS障害に近く、「接続が拒否されました」はローカルポートの誤りでよく見られます。長時間タイムアウトする場合は、ポリシー、ノード、ルーティングを引き続き確認します。

ログは一連のトラブル解決で最も直接的な証拠です。正常なリクエストでは通常、対象ドメインまたはIP、ルールの種類、ポリシーグループ、実際に使用したノードを確認できます。ログに DIRECT と表示される場合、ルールに従って直接接続されています。プロキシノードが表示された後にタイムアウトする場合は、通信がコアに到達しているため、確認すべき点はノードの可用性、ポリシーグループ、リモートネットワークであり、システムプロキシのスイッチではありません。

サブスクリプション、設定ファイル、ポリシー選択を確認する

サブスクリプションの更新が成功しても、クライアントが内容を取得できたことを示すだけで、現在有効な設定が更新後のものだとは限りません。一部のクライアントでは複数のローカル設定を保存でき、更新と切り替えは別々の操作です。まず設定画面を開き、現在の設定名、更新日時、有効状態を確認します。更新後にクライアントから再読み込みを求められた場合は、読み込みを完了してからテストしてください。

設定をコアが完全に読み込めるか確認する

設定ファイルにはポート、DNS、ルール、ポリシーグループ、ノードの定義が含まれます。YAMLのインデントエラー、存在しないノードを参照するポリシーグループ、ルールプロバイダーのダウンロード失敗は、読み込み失敗や一部機能の異常を引き起こします。まずコアの起動ログを確認し、サブスクリプション画面の「更新完了」だけで判断しないでください。ログに解析エラーがある場合は、正常に起動できた最後の設定へ戻し、カスタマイズした内容を少しずつ復元します。

リモートルールセットを使用している場合は、ルールファイルがダウンロード済みかも確認します。設定の初回読み込み、ネットワーク環境の変化、ルールプロバイダーのアドレスに一時的に接続できないことなどにより、ポリシーグループは存在していても必要なルールデータがまだ準備できていない場合があります。このときは設定を再読み込みし、ルールのダウンロード記録を確認します。出所の不明な設定に大量のオーバーライドを直接追加しないでください。サブスクリプションの問題とローカル変更が混在し、原因の切り分けが難しくなります。

プロキシモードとポリシーグループを確認する

一般的なモードには、ルールモード、グローバルモード、ダイレクトモードがあります。ルールモードは設定内のルールを上から順に照合し、グローバルモードは通常、指定したグローバルポリシーへリクエストを渡します。ダイレクトモードではプロキシを迂回します。クライアントがダイレクトモードのままだと、ノードの遅延が測定できても、Webページの通信はノードを経由しません。

  • ルールモード：日常利用に適しています。対象リクエストが最終的にどのルールに一致し、そのルールがどのポリシーグループを指しているか確認します。
  • グローバルモード：ルールに問題があるか短時間で判断するのに適しています。グローバルモードではアクセスできるのにルールモードではできない場合は、ルールの順序、ポリシーグループの参照、フォールバックルールを重点的に確認します。
  • ダイレクトモード：一時的にプロキシを迂回するために使用します。トラブル解決後は必要なモードに戻してください。

ポリシーグループの名前が同じでも、グループ内の選択が正しいとは限りません。手動選択のグループが、すでに利用できないノードを選んだままになっていることもあります。自動測定グループも、現在のネットワークに適さない測定結果を使う場合があります。ポリシーグループを開き、最近利用できることを確認したノードを明示的に選んでから、実際のWebページへアクセスしてください。遅延テストは、その時点で測定先から応答があったことを示すだけで、実際のTCP、TLS、対象サイトへのアクセスを保証するものではありません。

システムプロキシ、待ち受けアドレス、ポート競合を確認する

TUNを使用しない場合、ブラウザーや多くのデスクトップソフトはシステムプロキシを通じてリクエストをClashへ送ります。クライアントの「システムプロキシ」スイッチは、コアが実際に待ち受けているHTTP、SOCKS、混合ポートと一致していなければなりません。コアの再起動失敗、ポートの使用中、システム設定に古いポートが残っていることにより、プロキシを有効にしていてもすべてのリクエストが本機で拒否される場合があります。

リクエストがコアに入っているか確認する

ログ画面を開いたままWebページを更新します。ログに新しいリクエストが一つも表示されない場合は、システムプロキシが有効か、プロキシサーバーが本機のアドレスになっているか、ポートが現在の設定と一致しているかを順に確認します。一般的な本機アドレスは 127.0.0.1 ですが、具体的なポートはクライアントに現在表示されている値、または設定ファイルの mixed-port、port、socks-port を使用してください。他のデバイスのポートをそのまま使わないでください。

コマンドラインでHTTPプロキシを明示的に指定してテストできます。以下のポートは例なので、実行前にクライアントが実際に待ち受けているポートへ置き換えてください。

curl.exe -I -x http://127.0.0.1:7890 https://example.com/

明示的なプロキシ経由のリクエストは成功するのにブラウザーだけ失敗する場合、コア、ノード、基本的な外向き経路はおおむね正常です。原因は、システムプロキシが反映されていない、ブラウザーが個別のプロキシを設定している、拡張機能がネットワーク設定を変更している、アプリがシステムプロキシを参照していない、といった点にある可能性が高いです。コマンドが 127.0.0.1 への接続不能を直接示す場合は、コアが動作しているか、ポートが待ち受け状態かを確認します。リクエストがログに入った後でリモート側がタイムアウトする場合は、ポリシーとノードの確認に戻ります。

ポートの使用中と二重起動を確認する

同じデバイスで2つのプロキシクライアントを同時に実行している、または古いClashプロセスが終了していない場合、同じポートを奪い合うことがあります。新しいクライアントの画面が開いていても、コアが正常に待ち受けているとは限りません。起動ログに address already in use、bind、待ち受け失敗などの情報がないか確認し、重複プロセスを終了してからコアを起動します。ポートを変更して競合を避けることもできますが、システムプロキシも新しいポートへ合わせて更新してください。

LAN共有の設定と本機での利用は別のものです。本機からだけアクセスする場合は、127.0.0.1 で待ち受ければ通常は十分です。他のデバイスから接続する必要がある場合だけLANアクセスを許可し、システムファイアウォールも設定してください。本機のブラウザーを直すためだけに、むやみにLAN待ち受けを開放しないでください。

システムプロキシの残留設定を処理する

クライアントが異常終了すると、OSに古いポートを指すプロキシ設定が残り、Clashを終了してもブラウザーにアクセスできないことがあります。クライアントを再起動し、まず「システムプロキシ」を無効にします。OSのプロキシ設定画面で手動プロキシが消えていることを確認してから、必要に応じて再度有効にしてください。企業ネットワーク、自動構成スクリプト、ブラウザーのポリシーが手動設定を上書きすることもあるため、システムのネットワーク設定で最終的に有効な値を確認します。

DNSの失敗：ドメインは開けなくてもネットワークが切断されたとは限らない

DNSはドメイン名をアドレスへ変換します。ClashまたはmihomoはDNSを引き受け、ルール、Fake IP、実アドレスの結果に基づいて後続の接続を決められます。DNS設定が機能していないと、ノードの遅延が測定でき、プロキシポートも正常なのに、ブラウザーではドメイン解決エラーが続くことがあります。そのため、DNSはリクエストがコアに入っていることを確認した後、個別に調べます。

症状から名前解決の問題を判断する

  • ドメインへのアクセスに失敗する一方、既存の接続やIPアドレスを直接使用する一部のサービスは動作する。
  • ログにDNSタイムアウト、上流サーバーへの接続不能、名前解決ループ、クエリ拒否が表示される。
  • ネットワークを切り替えた後に突然使えなくなる。特に社内ネットワーク、学校ネットワーク、公共Wi-Fi、自宅ネットワークを切り替えた場合に起こりやすい。
  • TUNまたはClashのDNSを無効にすると復旧する。DNSの取り込み経路に関係する障害だと判断できる。

システムコマンドを使うと、OSが現在ドメインを解決できるか判断できます。

nslookup example.com

nslookup の結果だけで、ClashのDNSが完全に正常だとは証明できません。アプリによってはブラウザー内蔵のセキュアDNSを使用し、TUNが通常のDNSリクエストを横取りすることもあります。クライアントのDNSログとブラウザー設定を併せて確認してください。ブラウザーで独自の暗号化DNSが有効になっていると、システムの名前解決経路を迂回したり、ルールの想定と一致しなかったりする場合があります。トラブル解決時は一時的にシステムDNSへ戻し、問題の範囲を確認してから最終的な構成を決めます。

Fake IPとredir-hostを理解する

対応するClash Meta（mihomo）設定では、fake-ip モードがドメインに予約アドレスを返し、接続時にドメインを復元します。これにより、ルール判定と透過プロキシの一貫性を高められます。予約アドレスが表示されても、必ずしも異常ではありません。実際の問題は、DNS通信が正しく取り込まれていない、Fake IPのマッピングが失われている、一部のLANや特殊なアプリと互換性がない、といった場合に起こります。

redir-host は実際に解決されたアドレスを返し、異なる経路との互換性がありますが、すべての環境でより信頼できるとは限りません。Fake IPが表示されたというだけでモードを切り替えないでください。プリンター、LAN機器、ゲームプラットフォーム、特定のアプリだけが失敗する場合は、fake-ip-filter で対象ドメインを除外する必要があるか確認し、LAN内のドメインが適切なネームサーバーで解決されているか確認します。

DNSの上流サーバーとループ依存を確認する

DNSの上流サーバーは、現在のネットワーク環境から到達できなければなりません。上流サーバー自体がプロキシを必要とし、そのプロキシ接続にも先にノードのドメイン解決が必要だと、依存ループが発生することがあります。設定のデフォルトネームサーバーには、起動時に直接到達できるDNSサービスを選んでください。サブスクリプションのノードがドメイン名を使用している場合、この確認は特に重要です。

DNSを変更した後は設定を再読み込みし、OSまたはブラウザーのキャッシュを消去してから再テストします。出所の不明な上流アドレスを一度に複数追加しないでください。数を増やしてもルーティングエラーは直らず、かえってタイムアウトの原因を特定しにくくなります。各フィールドの詳しい意味と設定の関係は使用ガイドを参照してください。

TUNモードを有効にしてもアクセスできない

TUNは仮想ネットワークインターフェースを通じて、より多くの通信を取り込みます。システムプロキシに従わないアプリに適しています。一方で、仮想NIC、ルーティングテーブル、DNSの横取り、システム権限、ファイアウォールが関係するため、通常のシステムプロキシより障害点が増えます。スイッチをオンにしただけで仮想インターフェースの作成に成功したとは限らず、コアのログとシステムのネットワークインターフェース状態で確認する必要があります。

権限とドライバーの状態を確認する

Windowsで仮想インターフェースを作成・変更するには、通常十分なシステム権限が必要です。macOSではネットワーク拡張の承認や管理者パスワードの入力を求められることがあります。LinuxではTUNデバイスと適切なネットワーク管理権限が必要です。インターフェースの作成失敗、ルート設定失敗、権限不足がログに出ている場合は、ノードを切り替え続けるのではなく、まず権限の問題を解決します。

システムのスリープ、アップデート、ネットワークアダプターの変更後は、古い仮想インターフェースやルートが正しく解放されないことがあります。まずTUNを無効にし、ルートが復旧するまで待ってから再度有効にします。それでも失敗する場合は、クライアントを完全に終了してシステムを再起動したほうが、スイッチを何度も切り替えるより残留状態を解消しやすいことがあります。再起動後は、まずシステムプロキシだけを有効にしてコアとノードを確認し、その後TUNを有効にすると、障害が透過的な取り込みによるものか判断できます。

ルート、除外設定、ループバックを確認する

TUNでは、Clash自身の接続が再びTUNへ送られて通信ループにならないようにする必要があります。対応の進んだクライアントは通常、コアプロセスと必要なルートを自動処理しますが、カスタムルート、サードパーティ製ファイアウォール、VPN、仮想マシンソフト、その他のネットワークフィルターが結果を変えることがあります。トラブル解決時は別のVPNやプロキシツールを一時停止し、ネットワークを取り込むプログラムを1つだけ残します。

TUNを有効にするとインターネットは復旧するのにLAN機器へアクセスできない場合は、プライベートネットワークのセグメントが必要に応じて直接接続されているか、自動ルートと厳密ルートの設定が現在のシステムに合っているかを確認します。反対に、LANは正常なのにインターネットがすべてタイムアウトする場合は、デフォルトルートが正しく書き込まれているか、Wi-Fiと有線ネットワークの切り替えに応じて外向きインターフェースが変わっているかを確認します。すべてのプライベートアドレスを一律にプロキシへ送ると、ルーター管理画面、ファイル共有、ローカルDNSに影響することがあるため避けてください。

システムプロキシとTUNを重ねて混乱させない

一部のクライアントではシステムプロキシとTUNを同時に有効にできます。通常の設定なら動作しますが、トラブル解決時はリクエストがどの経路を通っているか判断しにくくなります。まずTUNを無効にし、システムプロキシだけでブラウザーをテストします。正常になったらシステムプロキシを無効にするか、クライアントの推奨に従って設定を残し、TUNだけでターミナルや他のアプリをテストします。各段階でログを確認し、Webページが偶然一度開いただけで結論を出さないでください。

アプリとOSごとの違いを追加確認する

同じデバイスで一部のプログラムだけが失敗する場合、グローバルなサブスクリプションを変更し続ける必要はありません。ブラウザーは独自のプロキシやセキュアDNSを使用することがあります。ターミナルツールは HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 環境変数を参照する場合があります。ゲームやストアアプリはシステムプロキシを完全に迂回することもあります。まずアプリがどのネットワーク経路を使っているかを明確にし、そのうえでアプリ内プロキシ、システムプロキシ、TUNのどれを使うか決めます。

Windows

「設定」の手動プロキシがクライアントと一致しているか確認し、古い自動構成スクリプトにも注意します。アプリによってはネットワーク分離やループバック制限により、デスクトップブラウザーは正常なのにストアアプリだけ異常になることがあります。ファイアウォールがコアプログラムの待ち受けや外向き通信を阻止する場合もあります。クライアントの実行ファイルの場所を変更した場合は、システムファイアウォールの許可を改めて確認し、クライアントのログで該当アプリからリクエストが発生しているか検証します。

macOS

システムプロキシはネットワークサービスごとに保存されます。Wi-Fiと有線ネットワークを切り替えた後、プロキシが以前のサービスにしか設定されていないことがあります。現在使用中のネットワークサービスを開き、WebプロキシとセキュアWebプロキシを確認してください。TUNや拡張モードではネットワーク拡張が正常に有効になっている必要もあります。システムアップデート後に拡張機能の許可がリセットされた場合は、クライアントの案内に従って再承認します。

Linux

デスクトップ環境のシステムプロキシがターミナルプログラムに影響するとは限らず、ターミナルの環境変数がGUIアプリに影響するとも限りません。設定の適用範囲を明確にして、それぞれ個別にテストします。TUNを使用する場合は /dev/net/tun、ルーティングテーブル、ポリシールーティング、DNS管理サービスを確認し、NetworkManager、systemd-resolved、手動で書き込んだ名前解決設定が互いに上書きしないようにします。

AndroidとiOS

モバイル端末では通常、システムVPNインターフェースを使って通信を取り込みます。ステータスバーにVPNが表示されているのにリクエストが失敗する場合は、システムがクライアントのバックグラウンド動作を制限していないか、別のVPNも同時に有効になっていないか、現在のWi-Fiで先にポータル認証が必要でないかを確認します。モバイルデータ通信とWi-Fiを切り替えると、特定の接続ネットワークだけの問題かすばやく判断できます。アプリごとの振り分けやLANのバイパス設定も実際の結果を変えます。

変更を最小限にしてアクセスを復旧する手順

以下の手順では、障害箇所を外側から内側へ段階的に確認します。「昨日まで使えていたのに、今日はすべて開けない」という場合に適しています。1つ終えるたびにすぐテストし、ログの変化を記録してください。復旧したら、最後に変更した項目を見直し、それ以降の手順を続けないでください。

  1. システムプロキシとTUNを無効にし、デバイスの基礎ネットワークとローカルへの直接アクセスが正常か確認する。
  2. Clashコアを起動し、YAML、ルールプロバイダー、待ち受けポート、権限のエラーなく設定が読み込まれていることを確認する。
  3. 現在有効なサブスクリプション設定を確認し、更新後に再読み込みして、検証可能なノードを明示的に選択する。
  4. ダイレクトモードになっていないことを確認し、短時間だけグローバルモードを使ってルールが原因か判断する。
  5. システムプロキシだけを有効にし、Webページを更新してログを確認する。ログがなければシステムプロキシを調べ、ログがあればルール、ノード、DNSを調べる。
  6. 明示的なプロキシコマンドでローカルの待ち受けポートをテストし、ブラウザー拡張機能やアプリ設定の影響を除外する。
  7. ポートの使用中、コアプロセスの二重起動、システムに残った古いプロキシアドレスを確認する。
  8. 名前解決エラーとDNSログに基づき、上流サーバー、ブラウザーのセキュアDNS、Fake IP、ノードのドメイン解決を確認する。
  9. システムプロキシが安定してからTUNを有効にし、権限、仮想インターフェース、ルート、他のVPNとの競合を確認する。
  10. ルールモードと普段の設定に戻し、ブラウザー、ターミナル、対象アプリでそれぞれ検証する。

グローバルモードですべてのノードがタイムアウトするのに基礎ネットワークが正常な場合は、別のネットワークで同じ設定を再テストし、ローカルネットワークの制限とサブスクリプションのノード障害を切り分けます。1つのノードだけが失敗する場合は、ログを保存したうえでノードを直接切り替えます。設定全体を読み込めない場合は、設定の提供元にサブスクリプションの状態と形式を確認してください。問い合わせ時にOS、クライアントのバージョン、コアの種類、プロキシモード、DNSモード、必要な情報を残したエラーログを添えると、「接続できない」とだけ説明するより正確な判断を得やすくなります。

「Clashは接続済みなのにインターネットに接続できない」問題の多くは、単一のスイッチが原因ではありません。確実な対処は、まず基礎ネットワークを確認し、次に設定とノードを確認し、その後通信がローカルポートへ入っているかを調べ、最後にDNSとTUNを処理することです。インストールと権限設定をやり直す必要がある場合は、完全ガイドに沿って一項目ずつ確認し、古い設定の上に変更を重ねないようにします。