まず理解したいAndroidのVpnServiceによる通信制御
Android版のClash系クライアントは通常、システムが提供する VpnService を使ってローカルの仮想ネットワークインターフェースを構築します。サービスを起動すると、Androidは対象範囲の通信をこの仮想インターフェースへ送り、クライアントのコアが設定ファイルのルール、プロキシグループ、ノードに従って接続を処理します。ステータスバーに鍵やVPNのアイコンが表示されるのは、システムのVPN経路が使用中であることを示しますが、端末が従来型の企業VPNサーバーへ直接接続しているという意味ではありません。
この流れは3層に分けて考えると分かりやすくなります。第1層ではAndroidがアプリの通信を仮想インターフェースへ渡します。第2層ではClashまたはmihomoのコアが対象ドメイン、宛先アドレス、ポートなどを読み取り、ルールと照合します。第3層で、DIRECT、プロキシノード、接続拒否などの判定に基づき実際の接続を確立します。サブスクリプションのノードとルール設定は第3層の動作を決め、VpnServiceは第1層の通信入口を担います。
Androidでは、同じユーザースペースで主要なVPNサービスを通常1つしか同時に維持できません。すでに会社のVPN、別のプロキシクライアント、ファイアウォール、またはVpnServiceを利用するフィルタリングツールが接続されている場合、Clashクライアントの起動時に既存のサービスが停止したり、新しいサービスがVPN権限を取得できなかったりします。「起動をタップするとすぐ停止する」場合は、サブスクリプションを何度も更新する前に、ステータスバーとシステムのVPN設定を確認してください。
VpnServiceと通常のシステムプロキシの違い
通常のHTTPシステムプロキシは、アプリが自発的にプロキシ設定へ従うことを前提とします。一部のアプリ、UDP通信、独自のネットワークスタックを実装したソフトウェアは、これを回避する場合があります。VpnServiceはシステムのネットワーク層から対象範囲の通信を受け取るため、一般により広い通信をカバーでき、Androidクライアントではこの方式が多く採用されています。クライアントによってはVPNモード、TUNモード、サービスモードなど名称が異なりますが、確認すべき点はAndroidの仮想インターフェースが作成されているか、どのアプリが対象に含まれているかです。
ここでいうAndroidのVpnServiceは、デスクトップで手動設定するTUNと完全に同じではありません。デスクトップOSでは仮想NICのインストール、ルーティング変更、権限昇格が必要になる場合があります。一方、Androidでは公開されたVPN APIを使って許可を取得します。初回起動時にシステムの確認ダイアログが表示されるのは正常な権限フローであり、承認後にクライアントが経路を構築できるようになります。
初回起動時に確認したい重要設定
サブスクリプションを読み込んだ直後に、すべての不具合をバッテリー設定のせいにするのは避けましょう。まず設定を読み込めること、ノードへ接続できること、プロキシグループが選択されていることを確認し、その後でバックグラウンド維持を調整します。確認の順番を決めておくと、設定ミスとシステム制限を切り分けやすくなります。
- 設定が有効になっているか確認します。設定一覧には複数のサブスクリプションやローカルYAMLファイルが保存されている場合があります。更新に成功しても、新しい設定が現在の設定へ切り替わったとは限りません。有効化マーク、更新日時、設定名を確認してください。
- プロキシグループの選択を確認します。設定内のプロキシグループが、利用できないノードを初期選択している場合や、自動速度測定中の場合があります。まず遅延テストが完了し、接続できるノードを選んでからWebページを確認します。
- システムのVPN権限を許可します。初回起動時には通常、接続リクエストが表示されます。ダイアログをキャンセルすると、クライアントの画面は正常に開いても、システム通信を制御できません。
- 動作モードを確認します。ルールモードは設定内のルールに従って通信を振り分けます。グローバルモードでは通常、大部分の通信を指定したプロキシへ送ります。ダイレクトモードではプロキシを経由しません。テスト時は現在のモードを記録し、ダイレクトモードでノードの障害と誤認しないようにしてください。
- 動作ログを確認します。設定の解析失敗、DNSリクエストの異常、ノードのハンドシェイク失敗、ネットワーク到達不能は、通常それぞれ異なるログを残します。Webページが開くかどうかだけを見るより、ログのほうが障害箇所を正確に絞り込めます。
アプリごとの通信振り分けを設定する方法
多くのAndroidクライアントは、「選択したアプリのみプロキシ」または「選択したアプリを除外」に対応しています。前者はホワイトリスト方式で、チェックしたアプリだけがVpnServiceに入ります。後者はブラックリスト方式で、チェックしたアプリは直接接続になります。名称だけで判断せず、変更前に画面の説明を読み、ブラウザで動作を確認してください。
決済、銀行、LAN機器の操作、キャスト、スマートホームアプリを除外するかどうかは、実際のネットワーク要件に応じて決めます。アプリを除外すると、その通信はClashのルールを通らないため、ログに該当リクエストが表示されないのは想定どおりです。ブラウザは使えるのに特定のアプリだけ接続できない場合は、アプリごとの振り分けリストを優先して確認します。
画面ロック後に切断する主な原因
「画面点灯中は正常なのに、数分ロックすると接続できず、ロック解除してクライアントを開くと復旧する」場合、設定自体は動作しているものの、バックグラウンドサービスが制限された、プロセスが回収された、または待機中にネットワークが切り替わった可能性があります。Android標準のDoze、メーカー独自の電源管理、バックグラウンド起動制限、メモリクリーナーなどが関係します。
Dozeは、端末が静止して画面が消灯し、一定の条件を満たすと、バックグラウンド処理やネットワークアクセスを制限します。フォアグラウンドサービスは通常のバックグラウンドプロセスより停止されにくいため、クライアント起動後は継続通知が表示されることが一般的です。通知権限を無効にしたり、通知チャンネルを許可しない設定にしたりすると、サービスが動き続けるシステムもありますが、通知を正常に表示できないフォアグラウンドサービスをより積極的に制限するシステムもあります。クライアントの動作状態通知は残し、システムのクリーナーで一括終了しないことをおすすめします。
まず切断の種類を確認する
- VPNアイコンが消える:VpnServiceが停止した、アプリのプロセスが終了させられた、または別のVPNサービスがシステム経路を占有した可能性が高い状態です。
- VPNアイコンは残っているのに、すべての接続に失敗する:上流ネットワークの変化後に既存接続が復旧していない、またはノード、DNS、仮想インターフェースに異常がある可能性があります。
- 一部のアプリだけ失敗する:まずアプリのプロキシ対象範囲、ルールの適用状況、IPv6、DNS、対象アプリ自身のバックグラウンド制限を確認します。
- Wi-Fiからモバイルデータへ切り替えると失敗する:ネットワーク切り替え後にクライアントが接続を再構築できるか、モバイルデータの利用権限が有効かを確認します。
- クライアントを開くとすぐ復旧する:バックグラウンド制限を示すことが多い症状です。画面が前面に戻ると、システムが実行機会を再び与え、サービスやコアが復旧します。
切断を調べるときは、再現可能なテストを行います。同じ設定と同じノードを使い、継続的に更新されるページを開いたまま画面をロックして10分待ち、ロック解除後にVPNアイコン、クライアントの動作状態、ログの時系列を確認します。その後、Wi-Fiとモバイルデータでそれぞれ繰り返します。一度に1つの設定だけを変更すれば、どのバッテリー設定が影響したのか判断できます。
画面ロック中にログが完全に途切れ、ロック解除後に再開する場合は、プロセスの維持設定とバッテリー制限を重点的に確認します。ログが記録され続けているのにタイムアウトが大量に出る場合は、ノードの可用性、ネットワーク切り替え、DNSへ調査対象を移します。サービスがシステムによって停止されると、ログ末尾にサービス破棄やコア終了の情報が残るクライアントもあります。ただしプロセスが直接終了させられた場合、原因を完全に記録する前にログが途切れることがあります。
バッテリー最適化の除外とバックグラウンド動作の設定
メーカーによってメニュー名は異なりますが、目的はほぼ共通しています。クライアントの継続的なバックグラウンド動作を許可し、そのアプリへのバッテリー最適化を解除し、必要なバックグラウンド通信を許可します。設定項目は「アプリ情報」「バッテリー」「アプリの自動起動管理」「特別なアプリアクセス」などにあります。
次の順番で調整するのがおすすめです
- バッテリー使用量を「制限なし」にします。クライアントのアプリ情報からバッテリー設定を開き、「制限なし」「バックグラウンドでの使用を許可」など、同じ意味の項目を選択します。Android標準システムでは、アプリ情報内のバッテリー使用量管理が一般的な入口です。
- 自動管理を無効にします。システムによっては、自動起動、関連起動、バックグラウンド動作の3つのスイッチがあります。自動管理を無効にした後、画面の説明に従ってクライアントの自動起動とバックグラウンド動作を許可します。
- フォアグラウンドサービスの通知を残します。クライアントによる動作通知の表示を許可します。通知は状態表示だけでなく、Androidのフォアグラウンドサービス機構にも関係します。
- バックグラウンドデータを許可します。モバイルデータとWi-Fiの権限を確認し、バックグラウンドデータが無効になっていないことを確認します。データセーバーを有効にしている場合は、クライアントを「データ通信を制限しないアプリ」に追加します。
- 最近使ったアプリでクライアントをロックします。メーカー独自のシステムには、タスクカードをロックして一括クリアで終了される可能性を下げる機能があります。バッテリー最適化の除外設定の代わりにはなりませんが、補助策として利用できます。
- クライアントのサービスを再起動します。権限を変更したらVpnServiceを停止して再起動します。必要に応じて端末も再起動し、画面ロックとネットワーク切り替えを確認します。
クライアントをバッテリー最適化の対象外にすると、コアが仮想インターフェース、DNS処理、必要な接続状態を維持するため、バックグラウンドの消費電力が多少増えることがあります。実際の消費量は、通信量、ルール数、ログレベル、ノードのプロトコル、アプリが継続的に通信するかどうかにも左右されます。まず接続を安定させ、その後で負荷の高い不要な設定を一つずつ減らし、バックグラウンド権限を一度にすべて無効にするのは避けてください。
端末起動後に自動復旧するか
端末起動時にクライアントを起動できるかは、アプリがその機能を実装しているか、システムが自動起動を許可しているか、VPN権限とシステムポリシーが有効なままかによって決まります。一部のAndroidバージョンには「常時接続VPN」機能があり、システムのVPN設定でアプリを指定できます。ただし、この機能を有効にしてよいかはクライアントの仕様説明を確認してください。
「VPN未接続時の通信をブロック」は、より厳格なシステム設定です。有効にすると、指定したVPNサービスが確立されていない間、端末が通信できなくなる可能性があります。設定のデバッグ、クライアントの切り替え、サブスクリプションのノード障害時には、問題がより顕著に現れます。通信を常にVPN経由にしたい場合だけ検討し、クライアントが安定して自動起動し、サービスを復旧できることを事前に確認してください。
DNS、プライベートDNS、ネットワーク切り替えの問題
バックグラウンド動作が正常でも、名前解決の経路まで正常とは限りません。Androidの「プライベートDNS」はシステム全体の暗号化DNS設定を使用し、Clashの設定では内蔵DNS、Fake-IP、ルールベースのDNS処理が有効になっている場合があります。クライアントや設定によって、両者が異なる経路を形成することがあります。「IPアドレスには接続できるのにドメインが開かない」「一部のアプリだけ読み込みが終わらない」といった場合は、DNSを独立した確認項目として扱います。
テスト時はAndroidのプライベートDNSを一時的に「自動」へ変更し、クライアントのサービスを再起動します。問題が解消した場合、指定していたプライベートDNSホスト、現在のネットワーク、設定内のDNS経路に互換性の問題がある可能性があります。無作為に切り替えて長期運用するのではなく、DNSが設定で明示的に有効か、リスニング方式がAndroidクライアントに適しているか、ルールが特定ドメインの名前解決を要求していないかを確認してください。
Fake-IPモードでは、ドメインに対して予約アドレス範囲のマッピングアドレスを返し、コアが元のドメインを復元してルールと照合します。ドメイン情報を保持し、ルール判定を安定させやすい一方、特定のLANサービス、特殊なアプリ、実アドレスによる判定に依存する環境では、除外設定が必要になる場合があります。Redir-Hostなど他のモードでは名前解決の流れが異なるため、除外設定をそのまま流用できません。
Wi-Fiとモバイルデータを切り替えた後の復旧
端末がWi-Fiの範囲を離れると、基盤ネットワーク、出口アドレス、DNS環境が変化します。クライアントはデフォルトネットワークの変更を検知し、その後の接続に新しいネットワークを使う必要があります。切り替え後もVPNアイコンが表示されるのに通信できない場合は、数秒待ってからクライアントのサービスを停止・起動します。毎回手動再起動が必要なら、クライアントのバージョン、バックグラウンド通信権限、システムのVPN制限を確認してください。
デュアルSIM、データセーバー、テザリング、LANアクセスを同時に有効にすると、問題はさらに複雑になります。テザリング端末の通信がスマートフォン上のVpnServiceを通るかどうかは、Androidのバージョン、メーカーの実装、クライアントの機能によって異なります。スマートフォン自身がプロキシ接続中だからといって、テザリングの通信も制御されているとは限りません。スマートフォンとテザリング先の端末で、出口アドレスとDNSをそれぞれ確認してください。
ログを使った切り分けと総合的な確認手順
Android版Clashクライアントのログには通常、ルールの適用、接続先、選択したポリシー、DNS処理、エラー情報が含まれます。調査中は一時的にログレベルを情報またはデバッグへ上げても構いませんが、詳細ログを長時間有効にすると書き込みと処理の負荷が増えます。記録が終わったら通常のレベルへ戻してください。
よくあるログの手がかり
timeoutまたは接続タイムアウト:宛先に到達できない、ノードの応答が遅い、ネットワーク切り替えから復旧していない、またはDNSリクエストが完了していない可能性があります。connection refused:宛先ポートが明確に接続を拒否しています。ローカルのリスニングや上流サービスが起動していない場合もあります。- 設定の解析エラー:YAMLのインデント、フィールド形式、サブスクリプションの変換結果、現在のコアが対応していない設定項目を確認します。
DIRECTが継続して適用される:現在のルールが通信を直接接続と判定しています。ルールの順序、モード、対象ドメインを確認してください。- 対象アプリのログがまったくない:アプリがVpnServiceの対象外になっているか、その通信が現在のクライアントに入っていない可能性があります。
システムがプロセスを停止したか詳しく確認するには、Androidの開発者ツールで端末ログを確認できますが、これは高度な方法です。パソコンへ接続してデバッグを許可した後、アプリのパッケージ名、VPNサービス、プロセス状態を軸に情報を絞り込みます。クライアントごとにパッケージ名は異なるため、アプリ情報やインストールパッケージの情報で確認し、別のソフトウェアの名前をそのまま使わないでください。
adb shell dumpsys vpn
adb shell dumpsys deviceidle
adb shell dumpsys activity services
dumpsys vpn は現在のVPN状態の確認に、dumpsys deviceidle は端末のアイドル状態とDozeの確認に役立ちます。サービス一覧を使えば、対象プロセスとサービスが残っているかも確認できます。これらのコマンドの出力はAndroidのバージョンによって変わるため、現象の検証に使い、特定の1行をすべての端末に当てはまる結論として扱わないでください。
おすすめのトラブルシューティング手順
- 前面表示中は、検証済みのノードを1つ固定して使い、ルールモードで正常にアクセスできることを確認します。
- システムのVPNアイコンが表示され、他のVPN、ファイアウォール、プロキシツールが経路を占有していないことを確認します。
- 対象アプリがアプリごとのプロキシ対象範囲に含まれているか確認します。
- 画面を消して時間を測り、VPNアイコン、ログが途切れた時刻、復旧方法を記録します。
- クライアントをバッテリー最適化の除外対象に追加し、バックグラウンド動作、バックグラウンドデータ、動作通知を許可します。
- Wi-Fi、モバイルデータ、そして両者の切り替えをそれぞれテストします。
- ドメインへのリクエストだけが失敗する場合は、プライベートDNS、設定のDNSモード、Fake-IPの互換性を確認します。
- それでも異常が続く場合は、必要な設定をバックアップし、保守されているクライアントのバージョンへ更新して、同じサブスクリプションで再テストします。
クライアント更新後に設定を読み込めなくなった場合、古い設定のすべてのフィールドを新しいコアへそのままコピーしないでください。Clash Meta(mihomo)は従来のClash設定との互換性に加え、ルールやプロトコルの機能を拡張していますが、クライアントに組み込まれたコアのバージョン、対応フィールド、既定動作は異なる場合があります。まずクライアントのエラーログで該当フィールドを特定し、対応するコアのドキュメントを参照して調整してください。
安定動作後のバッテリー消費を抑える方法
接続が安定したら、ログ、速度測定の頻度、不要なバックグラウンドリクエストから消費電力を抑えます。すべてのノードで頻繁に遅延テストを行うと、多数の接続を同時に確立します。サブスクリプションの自動更新間隔が短すぎても、端末の起動回数が増えます。自動速度測定グループの間隔は実際の利用状況に合わせ、毎分最新結果を得るために全ノードを常時確認する必要はありません。
ルール数そのものが、常に最大の消費電力要因になるわけではありません。継続的に動作するアプリ、接続の再試行、DNSの反復失敗、詳細ログのほうが重要な場合があります。無効なノードがプロキシグループで選ばれ続けると、バックグラウンドアプリが何度も再接続し、使い勝手と電池持ちの両方に影響します。ログに同じエラーが密集している場合は、まずノードを変更するかルールを修正してください。
バッテリー最適化の除外設定の目的は、必要なときにVpnServiceを確実に動作させることであり、クライアントを常に高負荷状態に保つことではありません。適切な設定なら、通信がないときはコアの処理を減らし、接続が発生したときにルール判定と転送を行えます。短時間の瞬間的な割合ではなく、システムのバッテリー統計で1日分のデータを確認するほうが参考になります。
最終的には、安定した設定、明確なルールモード、必要なアプリのプロキシ対象範囲、許可したバックグラウンド動作、正常に表示されるフォアグラウンド通知、そしてプライベートDNSとクライアントDNSの組み合わせを記録した簡潔な基準状態を残します。画面ロック後に切断したときは、まずこの基準状態で再テストし、システム更新、クライアントのバージョン、サブスクリプション設定のどれが変わったかを判断してください。
Android版Clashクライアントの設定を続ける
Androidに適したクライアントを選び、利用ガイドに従ってサブスクリプションを読み込み、プロキシモードとシステムのVPN権限を確認します。