トラブルシューティング 読了目安 13分

Clashは接続済みなのにネットにつながらない？Android版の項目別トラブルシューティング

サブスクリプションの期限、利用可能なノード、DNS、システムプロキシとTUNの競合、アプリの振り分け設定を順に確認し、接続済みなのにウェブページを開けない原因を特定します。

AndroidのステータスバーにVPNの鍵アイコンが表示されても、ClashがシステムVPNの権限を取得してサービスを開始したことを示すだけで、サブスクリプションの有効性、ノードへの到達性、DNSの正常動作までは保証しません。画面に「接続済み」と表示されているのに通信できない場合、トラフィックはクライアントに入っているものの、ノード、ルール、名前解決、アプリの振り分けのいずれかで止まっていることが多いです。

トラブルシューティングでは複数の項目を同時に変更しないでください。まず問題の範囲を確認し、「ネットワーク基礎 → 設定 → ノード → プロキシグループ → DNS → TUNとシステム設定 → アプリの振り分け」の順に対応します。各手順の後にテストページを開き、結果を記録してください。一時的に復旧した場合でも、真の原因を特定しやすくなります。

ステップ1：プロキシの障害か、スマートフォン自体のオフラインかを確認

まず停止・起動の2パターンでテストする

Clashのメイン画面でサービスを停止し、ステータスバーからVPNアイコンが消えるまで待ちます。その後、Wi-Fiとモバイルデータを使い、普段アクセスできるウェブサイトを2つ開きます。Clashを停止してもアクセスできない場合、原因はプロキシ設定ではありません。ルーター、モバイル回線、機内モード、料金未払い、システムのネットワーク制限を先に確認してください。

  1. Clashサービスを停止し、Wi-Fiで通常のウェブページとメッセージアプリをテストする。
  2. Wi-Fiをオフにして4Gまたは5Gへ切り替え、同じテストを繰り返す。
  3. Clashを再起動し、同じネットワークだけで再テストする。
  4. 「すべてのアプリがオフライン」「ブラウザだけオフライン」「国内サイトには直接つながるが、プロキシ経由の対象にはアクセスできない」のどれかを記録する。

障害範囲は、切り分けにおける最も重要な分岐条件です。すべてのアプリがオフラインなら、まず無効なノード、DNS、VPNの競合、誤ったグローバルルーティングを確認します。特定のアプリだけ異常なら、アプリの振り分け、バイパスリスト、そのアプリが依存するQUIC、IPv6、証明書環境を確認します。直接接続のサイトは正常で、プロキシ対象だけ利用できない場合は、通常ノードまたはプロキシグループが原因です。

IPアドレスとドメイン名でDNS問題を切り分ける

ドメイン名はまずIPアドレスへ名前解決する必要がありますが、IPアドレスへの接続では名前解決を省略できます。ブラウザでルーターの管理アドレス、たとえば 192.168.1.1 にアクセスしてみてください。LAN内のIPは開けるのにすべてのドメイン名で失敗するなら、DNSを最優先で確認します。公開IPへのアクセスだけで断定するのは避けてください。サイトによってはIPアドレスによる直接アクセスを拒否するためです。

症状 優先して確認 後回しでよい項目
Clashを停止してもオフライン Wi-Fi、モバイルデータ、システムネットワーク プロキシグループとルール
直接接続は正常、プロキシ対象は失敗 ノード、サブスクリプション、プロキシ選択 スマートフォンのハードウェア
IPには到達できるが、ドメイン名は失敗 DNS、プライベートDNS、Fake IP ノードの遅延順
1つのアプリだけ失敗 アプリの振り分け、バイパス、UDP サブスクリプション全体が無効

ステップ2：サブスクリプションの状態と設定が実際に反映されているか確認

選択中の設定が古いコピーではないことを確認

「サブスクリプションの更新は成功したのに、実際には別のローカル設定が動いている」というケースは少なくありません。Clash Meta for Androidでよくある画面を例に、「設定」を開き、現在の設定に選択マークが付いているか、更新日時とファイル名を確認します。似た名前の設定が複数ある場合は、一覧の先頭だけで判断せず、出所を1つずつ確認してください。

  • サブスクリプションサービスの有効期限が切れていないか、通信量の上限に達していないか確認する。
  • 「設定」で現在のサブスクリプションを更新し、画面に成功結果が表示されることを確認する。
  • 更新後にその設定を選び直し、ホームへ戻ってサービスを停止してから起動する。
  • 更新時に 401、403、404 が返る場合は、サブスクリプションURLまたはアカウント状態を確認します。
  • 更新時にYAMLの解析エラーが表示される場合は、サービス提供元の元の設定に戻し、カスタムオーバーライドを一時的に無効にします。

サブスクリプションURLからテキストをダウンロードできても、その内容が必ず動作するとは限りません。ノード一覧が空、プロキシグループが存在しないノードを参照、ルールプロバイダーのダウンロードに失敗、といった状態では、コアが起動しても正常な転送を完了できません。「ログ」を開いてサービスを再起動し、起動後30秒間を重点的に確認します。proxy not found、no such host、timeout、ルールセットのダウンロードエラーが続く場合は、該当する対象をさらに切り分けてください。

元の設定を上書きする可能性がある項目を一時停止する

クライアントのオーバーライド機能では、ポート、DNS、ルール、動作モードを変更できます。古いオーバーライドが新しいサブスクリプションの構造と互換性を失うと、サブスクリプション自体が正常でも、mihomoコアに渡される最終設定が不正になることがあります。「設定」→「オーバーライド」または現在のバージョンに対応する入口を開き、最近追加したDNS、ルール、スクリプトのオーバーライドを一時的に無効にしてから、設定を再読み込みします。

ステップ3：ノードとプロキシグループの選択を確認

遅延値だけでは完全な利用可否は判断できない

「プロキシ」ページで現在のプロキシグループの遅延テストを実行します。1回のテストで80～250ms程度なら、引き続き検証できます。タイムアウトが続く、または複数のノードが一律で約5000msになる場合は、テスト要求に応答がありません。遅延テストで確認できるのはテスト先への接続結果だけで、すべてのTCP、UDP、対象ドメインが利用できることを保証するものではありません。

ノードを選択したら、メイン画面に戻ってリアルタイム通信量を確認します。ウェブページを開いた際に上り・下りが長時間 0 B/s のままなら、アプリがVPNに入っていない、バイパスされている、またはシステムサービスが通信を引き受けていない可能性があります。上りだけ少し発生して下りが常にゼロなら、ノードへの到達不能、ハンドシェイク失敗、戻り経路の障害がよくある原因です。上下とも通信があるのにページが読み込み中のままなら、DNS、UDP、アプリのプロトコルを引き続き確認します。

固定ノードを手動選択し、自動グループの影響を除外する

  1. 「プロキシ」を開き、ルールが実際に参照しているプロキシグループを探します。たとえば PROXY、ノード選択、サービス提供元独自のグループ名などです。
  2. 一時的に 自動選択、フォールバック、負荷分散のサブグループは選ばないでください。
  3. 遅延テストで結果が得られた具体的なノードを1つ選ぶ。
  4. 異なる2つのサイトを連続してテストし、少なくとも30秒間維持する。
  5. 別の地域、または異なるプロトコルのノードへ切り替えて再テストする。

固定ノードではアクセスできるのに自動グループでは失敗する場合、原因は自動テスト先、許容値の設定、またはグループ内の候補ノードにあります。すべてのノードで失敗するなら、同じ地域の似た項目を何度も切り替えず、サブスクリプションの状態、現在のネットワークによるポート制限、ログに出るハンドシェイクエラーを確認してください。

動作モードを確認する

Clashの一般的な動作モードには、ルール、グローバル、直接接続があります。切り分け中は一時的に切り替えても構いませんが、結果を次のように理解してください。

  • ルールモード：ルールに従って通信を直接接続、プロキシ、拒否のいずれかへ振り分けます。日常利用でよく使われるモードです。
  • グローバルモード：大部分の通信をグローバルプロキシグループへ渡します。グローバルグループで無効なノードが選ばれていれば、モードを切り替えても復旧しません。
  • 直接接続モード：クライアントが通信を引き受けた後、直接外部へ接続できるかを確認するために使います。プロキシノードの検証には使いません。

ルールモードでは失敗するのにグローバルモードでは正常なら、ノードには基本的な接続能力があります。次にルールのマッチ結果を確認してください。「ログ」を開き、アクセスに失敗する対象へ接続し、該当する接続記録で最終的にどのプロキシグループへ入ったかを確認します。対象が誤って DIRECT、REJECT、または無効なグループへ送られている場合は、ノードのポートではなくルールの提供元またはオーバーライドを調整します。

ステップ4：DNS、プライベートDNS、Fake IPを確認

まずAndroidのプライベートDNSの競合に対処する

AndroidのプライベートDNSは暗号化された名前解決を使用します。ネットワークによっては指定されたプライベートDNSホストへ接続できず、「Wi-Fiは接続済みなのにドメインを開けない」状態になります。システムの「設定」→「ネットワークとインターネット」→「プライベートDNS」を開き、一時的に「自動」または「オフ」に変更してからClashを再起動します。メーカーによっては「接続と共有」や「その他の接続」に配置されています。

プライベートDNSをオフにしてすぐ復旧した場合、元のプライベートDNSホストと現在のネットワーク、またはClashのDNS処理経路に互換性がありません。この場合は名前解決の経路を1つに統一します。AndroidのプライベートDNSかmihomoのDNSモジュールのどちらか一方に任せ、2つの強制ルールが互いに上書きしないようにしてください。

DNS設定のフィールドを確認する

mihomoの設定でよく使われるDNS構造は次のとおりです。アドレスはフィールド間の関係を説明するための例であり、サブスクリプション環境から切り離して全体をそのまま置き換えないでください。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8
  fallback:
    - tls://1.1.1.1:853

enable はコアのDNSモジュールを制御します。listen はローカルの待受アドレスです。enhanced-mode の一般的な値は fake-ip または redir-host です。TUNで通信を引き受ける場合は、DNSハイジャックと待受ポートの一致も確認します。設定が要求を 1053 へリダイレクトしているのに、DNSモジュールがそのポートを待ち受けていなければ、ドメイン要求は応答のない宛先へ送られます。

redir-hostでFake IPとの互換性を比較する

Fake IPはドメイン名に予約済みアドレスを返し、コアがマッピングに基づいて転送します。安定したルールマッチングを実現しやすい一方、LAN機器、銀行アプリ、キャストツール、特殊なDNS応答に依存するアプリでは互換性の問題が起きる場合があります。多くのサイトは正常なのに、特定のアプリだけログインできない、LAN内のドメインが使えない、機器の検出に失敗するといった症状が現れます。

設定を1つ複製し、enhanced-mode を fake-ip から redir-host へ一時的に変更して比較テストできます。問題が解消した場合は、すべての拡張名前解決を長期的に無効にするのではなく、該当ドメインをFake IPフィルターへ追加するのが先です。変更後は設定を再読み込みしてサービスを再起動してください。メイン画面へ戻るだけでは、古いマッピングはすぐに無効になりません。

ステップ5：TUN、システムVPN、手動プロキシの競合に対処

同時に動作しているVPNサービスが1つだけか確認する

AndroidのVPNインターフェースは通常、1つのアプリしか使用できません。Clashの起動後に別のVPN、ファイアウォール、通信フィルター、仕事用プロファイルのVPNに置き換えられると、クライアント画面には一時的に動作中と表示されても、システム通信はClashを通らなくなります。システムの「設定」→「ネットワークとインターネット」→「VPN」を開き、現在接続されている項目が実際に使用中のClashクライアントであることを確認してください。

  • Android VPNServiceを使用する他のアプリを停止する。
  • 他のVPN項目の「VPNを常時接続」をオフにする。
  • 切り分け中は「VPNなしの接続をブロック」をオフにする。
  • ClashのVPN要求を再承認し、ステータスバーのアイコンを確認する。

「VPNなしの接続をブロック」は、設定が安定してから使用するのに適しています。トラブルシューティング中にClashサービスがクラッシュしたり、設定の読み込みに失敗したり、システムによって終了させられたりすると、この項目がすべてのネットワークを遮断し、ノードが無効になったように見えることがあります。

Wi-Fiに残った手動プロキシを解除する

Wi-Fiの詳細設定に 127.0.0.1 と 7890 を入力したままのケースがあります。クライアントが現在TUN/VPNで通信を引き受けている、またはローカルのmixed-portが別の値に変更されている場合、この手動プロキシによってブラウザ通信が待受していないポートへ送られます。システムの「設定」→「Wi-Fi」→「現在のネットワーク」→「プロキシ」を開き、切り分け中は「なし」に設定してください。

ポート 7890 はmixed-port、7891 はSOCKSやリダイレクト設定、9090 は外部制御インターフェースに使われることがありますが、具体的な値は現在の設定によって異なります。一般的なポート番号だけで端末の待受状態を判断せず、クライアントの設定またはログで実際のポートを確認してください。

TUNスタックを切り替えて互換性をテストする

mihomoのTUN実装には、system、gVisor、mixedなどのスタックが用意されている場合があります。利用できる選択肢はクライアントのバージョンやシステムの対応状況によって異なります。システムまたはクライアントの更新後に「サービスは起動するのにすべての接続がタイムアウトする」ようになった場合は、「設定」→「ネットワーク」→「TUN」の該当項目を開き、現在の値を記録してから、対応している別のスタックへ切り替えて再テストします。

切り替え後はサービスを完全に停止し、5秒待ってから再起動します。動作中にスイッチだけを切り替えると、古いVPNインターフェースや接続キャッシュが残る場合があります。あるスタックではTCPが正常なのに音声、ゲーム、HTTP/3に問題があるなら、ノード全体が使えないと判断する前にUDP対応を確認してください。

ステップ6：アプリの振り分け、バイパスリスト、省電力制限を確認

特定のアプリだけオフラインならアプリの振り分けを確認する

アプリの振り分けでは、Androidアプリのパッケージ名に基づいてVPNへ入れるかどうかを決められます。ホワイトリスト方式は選択したアプリだけを対象にし、ブラックリスト方式は選択したアプリをバイパスします。2つの方式を取り違えると、ブラウザは正常なのに対象アプリだけプロキシを通らない、または一部のアプリだけ通信できるといった状態になります。

  1. Clashの「設定」→「ネットワーク」→「アプリの振り分け」、または使用中のバージョンに対応する項目を開く。
  2. ホワイトリストとブラックリストのどちらのロジックが使われているか確認する。
  3. アプリの振り分けを一時的にオフにし、通常のアプリをすべてVPNへ入れる。
  4. サービスを再起動し、これまで失敗していたアプリをテストする。
  5. 振り分けを戻す際は、アプリを1つずつ追加し、大量のパッケージ名を一度にインポートしない。

仕事用プロファイル、アプリクローン、デュアルアプリは異なるUIDを使用することがあります。メイン領域のアプリを選択していても、仕事用プロファイル内のコピーが同じルールに従うとは限りません。クローンアプリだけが失敗する場合は、該当するユーザー領域でVPN権限とアプリ一覧を確認してください。

LANバイパスとルーティング除外を確認する

プリンター、キャスト、ルーター管理画面を利用できるよう、設定で 192.168.0.0/16、10.0.0.0/8、172.16.0.0/12 などのプライベートネットワークをバイパスすることがあります。リモートサービスもこれらのアドレス範囲でリソースを提供している場合、広すぎるバイパス設定によって通信がローカルインターフェースから直接送信され、失敗することがあります。

反対に、LAN通信をすべてリモートプロキシへ送ると、ルーターの管理画面やローカル機器にアクセスできなくなる場合があります。ログで対象IPの送信ポリシーを確認し、プライベートアドレスが DIRECT に入っていることを確認してください。リモートアクセスが必要な内部アドレスは、実際のネットワーク設計に従って処理します。

システムによるバックグラウンドサービスの制限を解除する

一部のAndroidシステムでは、画面ロック後にバックグラウンドVPNサービスが制限され、起動直後は使えるのに数分後にはすべての接続が停止することがあります。システムの「設定」→「アプリ」→「Clashクライアント」→「バッテリー」を開き、「制限なし」またはバックグラウンド動作を許可する設定を選びます。続いて「モバイルデータとWi-Fi」で、バックグラウンドデータとデータ無制限使用を許可してください。

画面ロックから5～10分後だけ障害が起き、画面を点灯すると復旧するなら、ノードより省電力設定が疑わしいです。メーカー独自の自動起動、バックグラウンドでのポップアップ表示、タスクのロック権限も確認してください。毎回1項目だけ変更し、画面ロックを含む完全なテストを行います。

ステップ7：ログを使って最終的な原因を特定する

再現可能なテスト記録を作成する

ログが多い場合は、まずログを消去するか現在時刻を控え、その後は失敗する対象を1つだけ開きます。次の形式で記録することをおすすめします。

ネットワーク：自宅のWi-Fi
動作モード：ルール
設定の更新日時：2026-08-14 10:32
プロキシグループ：PROXY → ノードA
テスト時刻：10:36:20
症状：ドメインの読み込みが15秒後にタイムアウト
ログのキーワード：DNS timeout / connection refused

1件の完全な接続記録からは、通常3つの点を確認できます。ドメイン名の名前解決が完了したか、ルールが接続をどこへ送ったか、送信接続がどの段階で失敗したかです。timeout は待機時間超過を示し、ノード、対象、途中のネットワークのいずれかに到達できない可能性があります。connection refused は相手側が明示的に拒否したことを示します。network unreachable はルーティング、インターフェース、IPv6に関係することが多く、TLSハンドシェイクエラーなら時刻、SNI、プロトコルパラメータ、ネットワークによる干渉をさらに確認します。

最小構成でクライアントとサブスクリプションの問題を切り分ける

ここまでの手順でも原因を特定できない場合は、サービス提供元の元のサブスクリプションを使い、カスタムオーバーライド、アプリの振り分け、追加ルールを無効にして、固定ノードを1つだけテストします。元の設定で正常なら、原因はローカルでの変更です。元の設定でも失敗し、同じサブスクリプションが別のネットワークでは正常なら、現在のネットワーク環境を重点的に確認します。複数の端末とネットワークですべて失敗するなら、サブスクリプション提供元にノード状態を確認してください。

テスト中にクライアント、サブスクリプション、ネットワーク、DNS、ノードを同時に変更しないでください。一度に変える変数は1つにし、起動、ドメインへのアクセス、ログ確認をそれぞれ1回以上行います。「接続済みなのにネットにつながらない」問題では、頻繁な再インストールより安定した再現のほうが価値があります。

トラブルシューティング結果の早見表

テスト結果 考えられる原因 次の手順
Clashを停止すると復旧 設定、ノード、DNS、またはVPNによる通信の引き受けに異常 この記事の順序に沿って確認を続ける
固定ノードは使えるが、自動グループは使えない 自動グループの候補またはテスト先に異常 グループメンバーとヘルスチェックを調整する
グローバルモードは使えるが、ルールモードは失敗 ルールマッチまたはプロキシグループの参照ミス ログで実際の送信先を確認する
プライベートDNSをオフにすると復旧 システムの名前解決経路が競合 DNS方式を1つに統一する
アプリの振り分けをオフにすると復旧 ホワイトリスト、ブラックリスト、またはUIDの選択ミス 最小限のアプリ一覧を作り直す
モバイルデータへ切り替えると復旧 Wi-Fiのネットワーク制限またはルーティング異常 ルーターのDNS、IPv6、ポートポリシーを確認する
画面ロック後に使えなくなる 省電力設定がバックグラウンドサービスを終了 バックグラウンド動作とバッテリーの制限なし設定を許可する
インストールパッケージのページへ