まずクライアントの操作階層を把握する
Clash Meta for Androidは、通常、グラフィカルインターフェース、mihomoカーネル、設定ファイルの3つで構成されています。グラフィカルインターフェースはサブスクリプションのインポート、プロキシの選択、状態確認を担当します。mihomoカーネルはDNS解決、ルール照合、接続の転送を実行し、設定ファイルにはプロキシノード、プロキシグループ、ルール、動作パラメータが保存されます。画面上の1回のタップは、最終的にカーネルの状態または設定内容の変更へ変換されます。
この記事では、一般的なClash Meta for Android 2.11.xの画面を基準に説明します。ビルドによっては「オーバーライド」が設定画面の右上、サイドバー、「設定」内に配置されていたり、「ログ」と「接続」が別々の入口に分かれていたりしますが、各セクションの役割は基本的に同じです。インストール直後は、「設定 → プロキシ → ホームで起動 → ログで確認」の順に操作することをおすすめします。
5つの主要セクションの役割
| セクション | 主な用途 | よく使う操作 |
|---|---|---|
| ホーム | サービスの状態と動作モードを確認 | 起動、停止、ルールモードの切り替え、通信量の確認 |
| プロキシ | プロキシグループとノードを操作 | ノード選択、遅延テスト、プロキシグループの展開 |
| 設定 | サブスクリプションとローカルYAMLを管理 | 設定のインポート、更新、切り替え、削除 |
| オーバーライド | 端末上で一部の設定パラメータを調整 | DNS、ポート、ルーティング、TUN関連の設定を変更 |
| ログ | カーネルの動作記録を確認 | DNS、ルール照合、接続、設定エラーを特定 |
ホーム:カーネルを起動し、モードと動作状態を確認
ホームは動作を制御する画面です。設定をインポートして選択したら、起動ボタンをタップします。AndroidはVPN接続の作成を求めます。システムのステータスバーに鍵やVPNのアイコンが表示されても、それは端末のVPNインターフェースが確立されたことを示すだけです。対象サイトへ正常にアクセスできるかどうかは、ノードの可用性、プロキシグループの選択、DNS、ルール照合の結果にも左右されます。
起動前に3つの状態を確認
- 現在の設定:ホームに表示される設定名が、インポートしたばかりのサブスクリプションと一致していることを確認し、古い設定を使い続けていないか確認します。
- 動作モード:通常は「ルール」または「Rule」を選び、ルールに応じて直接接続とプロキシ接続を振り分けます。グローバルモードでは大半の接続を指定したプロキシグループへ渡し、ダイレクトモードではプロキシを経由しません。
- VPN権限:初回起動時にシステムのVPNリクエストを許可します。同時にAndroidのVPNインターフェースを使用できるアプリは1つだけです。
バージョンによっては、ホームにアップロード速度、ダウンロード速度、累計通信量、アクティブ接続数が表示されます。速度はカーネルを通過しているリアルタイムの通信量であり、ノードの帯域上限を示すものではありません。画面に2.4 MB/sと表示される場合、現在1秒あたり約2.4 MBのデータが通過しているという意味で、回線速度がこの値に制限されるという意味ではありません。
ルール・グローバル・ダイレクトモード
- ルールモード:設定内の
rulesを上から順に照合します。業務サイトは直接接続し、特定のドメインはプロキシグループへ渡すといった振り分けが可能です。 - グローバルモード:接続をグローバルプロキシグループに集約します。特定のノードが動作するか一時的に確認する用途には適していますが、細かな通信の振り分けを長期的に置き換える方法ではありません。
- ダイレクトモード:接続先へ直接アクセスします。問題がローカルネットワークにあるのか、プロキシ経路にあるのかを切り分ける際に利用できます。
プロキシ画面:プロキシグループ、ノード、遅延結果を理解する
プロキシ画面は単なるサーバー一覧ではありません。画面上部やグループカードに表示されるのはプロキシグループで、その中にノードや別のプロキシグループが含まれます。ルールファイルは、PROXY、Streaming、Finalなど、接続ごとに指定されたグループへ振り分けます。グループ内で選択した項目によって、そのグループに接続が渡された後にどの経路を使うかが決まります。
よく使われるプロキシグループの種類
| 画面上の表示 | 設定の種類 | 動作 |
|---|---|---|
| ノードを手動で1つ選択 | select |
設定が更新されるか、再度切り替えるまで選択状態を維持 |
| 自動で速度を測定して選択 | url-test |
テストURLと設定した間隔に基づいてノードを評価 |
| 障害時に切り替え | fallback |
リストの先頭から利用可能なノードを優先して使用 |
| 接続を分散 | load-balance |
設定に従い、異なる接続を複数のノードへ振り分け |
遅延の数値をどう見るか
速度テストボタンをタップすると、通常は設定で指定されたテストアドレスへリクエストを送信します。よく使われるアドレスは https://www.gstatic.com/generate_204 で、正常な応答ではステータスコードだけが返り、完全なウェブページはダウンロードされません。86 msと表示された場合、その探測に約86ミリ秒かかったことを示します。タイムアウトは、制限時間内にリクエストが完了しなかったという意味です。120 msと135 msの1回限りの差で頻繁に切り替える必要は通常ありません。継続的なタイムアウト、800 ms超、数百ミリ秒単位の大きな変動がある場合に、より詳しく確認します。
速度テストに成功しても、すべてのウェブサイトへアクセスできるとは限りません。テストアドレス、対象サイト、ノードの出口は異なる経路を通る場合があります。まずノードを選択し、その後ログまたは接続画面で対象ドメインが実際にどのルールとプロキシに割り当てられたかを確認するのが正しい手順です。
ノードを切り替える基本手順
- 「プロキシ」を開き、ルールで実際に参照されているプロキシグループ(
PROXYなど)を見つけます。 - グループ内で遅延テストを1回実行し、継続的にタイムアウトするノードを除外します。
- 遅延が安定したノードを選び、選択マークがその項目へ移動したことを確認します。
- ホームに戻ってサービスを動作させたまま、対象アプリを再度開きます。
- アプリが古い接続を再利用する場合は、アプリを強制終了してからテストします。
設定画面:サブスクリプションのインポート・更新・切り替え
設定画面には、リモートサブスクリプションとローカルファイルを保存します。リモートサブスクリプションは通常、URLからYAMLの内容を取得し、更新時にプロキシノード、プロキシグループ、ルールを再ダウンロードします。ローカル設定は端末上のファイルを直接読み込みます。取得元にかかわらず、同時に有効化する設定は1つに明確に決めておく必要があります。
サブスクリプションURLからインポートする
- 「設定」画面を開き、追加ボタンをタップします。
- 「URL」または「リンクからインポート」を選びます。
- 識別しやすい名前を入力し、完全なサブスクリプションURLを貼り付けます。
- 保存してダウンロードが完了するまで待ち、設定項目にエラー表示がないことを確認します。
- その設定をタップし、現在の有効な設定に指定します。
- ホームに戻ってサービスを起動し、プロキシ画面でプロキシグループを選択します。
サブスクリプションの更新と設定の切り替えは別の操作です。更新では、そのサブスクリプションをローカルに保存した内容を置き換え、切り替えでは次回カーネルが読み込む内容を決めます。更新後もプロキシ画面に古いノードが表示される場合は、まず有効な設定を確認し、カーネルを停止して再起動してください。
設定一覧でよく使う操作
- 更新:サブスクリプションURLへ再度リクエストを送信します。期限切れ、認証失敗、ネットワークへの接続不能などでHTTPエラーが発生する場合があります。
- 編集:設定名、サブスクリプションURL、自動更新間隔を変更します。編集できる項目はクライアントのバージョンによって異なります。
- 切り替え:選択した項目を有効な設定にします。切り替え後は、ホームに表示される設定名を確認してください。
- 削除:端末に保存された項目を削除します。現在の設定を削除する前に、別の利用可能な設定へ切り替えてください。
自動更新間隔の設定方法
ノードの変更が少ない場合は、更新間隔を1440分、つまり1日1回に設定できます。頻繁に更新しても回線速度は向上せず、サブスクリプションサービスに一時的に接続できない際に誤った判断につながることがあります。提供元からノード変更の通知があった場合は、「設定」→「現在のサブスクリプション」→「更新」から手動で更新してください。
オーバーライド画面:サブスクリプションを直接編集せず端末側の設定を調整
オーバーライドは、端末上で設定を読み込む際にパラメータを追加適用する機能です。ポート、DNS、IPv6、ルーティングインターフェース、TUNのオプションなどを変更でき、サブスクリプションを更新するたびに元のYAMLを編集し直す必要がなくなります。対応するフィールドの範囲はバージョンによって異なるため、有効化する前に項目の説明を確認し、一度に変更するのは1つのパラメータ群に限定してください。
よく使われる設定フィールド
mixed-port: 7890
mode: rule
log-level: info
ipv6: false
external-controller: 127.0.0.1:9090
mixed-port: 7890:HTTPプロキシとSOCKSプロキシで7890番ポートを共有します。Androidでは主な通信は通常VPNインターフェースが処理しますが、LANツールや手動プロキシがこのポートを使用する場合があります。mode: rule:デフォルトでルールモードを使用します。画面上で動作モードを一時的に切り替えると、実際の状態がこの初期値を上書きする場合があります。log-level: info:通常の動作情報を記録します。複雑な問題を調べるときは一時的にdebugへ変更し、完了後に戻してログ量を減らします。ipv6: false:カーネルのIPv6処理を無効にします。利用中のネットワークとサブスクリプションがIPv6を正しくサポートしている場合に限り、DNS設定と合わせて有効化を検討してください。external-controller:カーネルの制御インターフェースです。127.0.0.1にバインドすると端末自身からのみアクセスでき、9090はよく使われる制御ポートです。
オーバーライドを安全に操作する順序
- 「設定」画面で、元のサブスクリプションが正常に起動できることを確認します。
- 「設定」→「オーバーライド」を開き、テストする項目だけを有効にします。
- サービスを停止して再起動し、カーネルに設定を再読み込みさせます。
- ログを確認し、フィールドの型、ポートの競合、DNS初期化エラーがないか調べます。
- テスト完了後に有効な設定を記録し、不要になったオーバーライド項目を削除します。
オーバーライドを有効にした直後にクライアントが停止する場合は、サブスクリプションを削除せず、まず追加したオーバーライドを無効にしてください。よくある原因は、YAMLのインデントエラー、フィールドの型の誤り、ポートの競合、現在のカーネルバージョンで古いフィールドがサポートされていないことです。たとえばポートは数字の 7890 と記述し、説明文を含む値にはしません。
ログ画面:接続記録から問題を特定する
ログは、カーネルが実際にどのように動作したかを確認する入口です。ホームで起動中と表示されているのにウェブページを開けない場合、スイッチを何度も切り替えるだけでは解決しません。「ログ」を開いて対象サイトへ再度アクセスし、時刻、レベル、ドメイン、ルール、送信先プロキシを基に最新の記録を確認すれば、DNS、ルール、ノードの問題をすばやく切り分けられます。
ログレベルの意味
- Info:正常な起動、接続確立、ルール一致などの通常記録です。日常的なトラブルシューティングではまず確認します。
- Warning:リクエストの再試行、一部機能の縮退、致命的ではない設定問題などです。サービスは動作を続けている場合があります。
- Error:設定の読み込み失敗、DNSリクエスト失敗、ノード接続失敗など、対処が必要なエラーです。
- Debug:内部処理をより詳細に記録します。短時間の問題再現に適していますが、記録量は大幅に増えます。
接続記録で確認するフィールド
TCP 192.168.0.2:53142 → example.com:443
match DomainSuffix(example.com)
using PROXY[Node-A]
この記録は、TCP接続が対象ドメインの443番ポートへアクセスし、ドメインサフィックスのルールに一致した後、PROXY プロキシグループ内の Node-A に渡されたことを示します。プロキシ経由を想定しているのに DIRECT と表示される場合は、ルールの順序を確認してください。プロキシは正しいのに接続がタイムアウトする場合は、ノードまたは回線をテストします。ログにIPアドレスだけが表示されドメイン名がない場合は、DNSとスニッフィングの設定を引き続き確認してください。
よくある4種類のエラーを判断するポイント
| ログの症状 | 優先して確認する項目 |
|---|---|
authentication failed |
ノードの認証情報、サブスクリプションの更新状況、端末時刻の正確さ |
i/o timeout |
ノードへの到達性、ローカルネットワーク、ファイアウォール、回線の混雑 |
no such host |
DNSサーバー、ネットワーク権限、ドメイン名前解決の設定 |
address already in use |
7890や9090などのポートが他のプロセスに使用されていないか |
トラブルシューティングでは、まずログを消去またはスクロール停止し、現在時刻を記録してから問題を1回だけ再現します。これにより、大量のバックグラウンド接続から対象の記録を探す手間を減らせます。ログにはアクセス先ドメイン、LANアドレス、ノード名が含まれる場合があるため、スクリーンショットを共有する前に、サブスクリプションURL、認証情報、公開したくないアクセス履歴を隠してください。
設定とパラメータ画面:DNS・TUN・アプリの通信振り分け
設定セクションでは、クライアント自体とカーネルの動作パラメータを管理します。一般的な経路は「設定」→「パラメータ設定」、「設定」→「ネットワーク」、「設定」→「アプリの通信振り分け」です。メニュー名はバージョンによって変わりますが、機能から判断できます。
TUNとシステムVPNインターフェース
Androidクライアントは通常、システムのVPN APIで仮想ネットワークインターフェースを作成し、アプリの通信をmihomoカーネルへ送ります。TUNを有効にすると、TCPと対応するUDP通信を同じ入口で処理できます。初回起動時にはVPN権限の許可が必要です。別のVPN、ネットワークフィルター、ローカルファイアウォールが動作している場合は、先に停止してください。Androidでは通常、一般的なVPNサービスを同時に1つしか有効にできません。
DNS設定で確認するポイント
- DNS機能が現在の設定に従って有効になっており、nameserverのアドレスへ現在のネットワークからアクセスできることを確認します。
fake-ipモードでは、ドメインが予約アドレス範囲へマッピングされ、カーネルがドメインを復元してルールを照合する場合があります。- 一部のLAN機器、銀行アプリ、ゲームはfake-ipに適さないため、フィルター項目で除外できます。具体的な項目はログを確認して決めてください。
- ドメインを開けない一方でIPアドレスへの直接アクセスが正常な場合は、すべてのノードをすぐに交換するのではなく、まずログでDNSのタイムアウトを確認します。
アプリの通信振り分けにおける2つの考え方
アプリの通信振り分けでは、パッケージ名に基づいてVPNへ送るアプリを決められます。ホワイトリストモードは選択したアプリだけを対象にし、ブラックリストモードは選択したアプリを除外します。モードを切り替えた後は、対象アプリを完全に終了してから再度開いてください。古い接続が切り替え前の経路を維持している場合があるためです。システムコンポーネント、WebView、対象アプリは別々にリクエストを送信することがあり、メインアプリのパッケージ名だけを選ぶと、ログイン画面と本文で異なる経路が使われる場合があります。
繰り返し使える初回設定の流れ
画面に慣れたら、初回設定を決まった手順にまとめられます。設定漏れを減らせるだけでなく、端末の買い替えや再インストール後にも各手順をすばやく確認できます。
- 「設定」→「追加」→「URL」を開き、サブスクリプションをインポートして有効な設定に指定します。
- サブスクリプションを1回更新し、ダウンロードエラーやYAML解析エラーがないことを確認します。
- 「プロキシ」を開き、主要なプロキシグループで遅延テストを実行して利用可能なノードを選びます。
- ホームに戻り、動作モードを「ルール」に設定して起動をタップし、VPNリクエストを許可します。
- 対象のウェブページを開き、ログ画面でドメイン、適用されたルール、送信先プロキシを確認します。
- 特定のアプリをバイパスする必要がある場合は、「設定」→「アプリの通信振り分け」で対象範囲を調整します。
- 基本接続が安定してから、DNS、TUN、ポートのオーバーライドを追加します。
接続異常時は階層ごとに切り戻す
- すべてのノードがタイムアウトする:まずWi-Fiとモバイルネットワークを切り替え、サブスクリプションの更新状況と基本ネットワークを確認します。
- 1つのノードだけ失敗する:プロキシ画面で同じグループの別ノードに切り替え、設定全体を作り直す必要はありません。
- 1つのウェブサイトだけ失敗する:一致したルールとDNS記録を確認し、誤ってダイレクト接続に振り分けられていないか調べます。
- 1つのアプリだけ失敗する:アプリの通信振り分け、古い接続のキャッシュ、IPv6、システムの省電力制限を確認します。
- オーバーライド有効化後に失敗する:最近追加したオーバーライドを無効にしてカーネルを再起動し、ログの変化を比較します。
画面操作の基本的な関係は、設定画面で読み込む内容を決め、プロキシ画面でプロキシグループの現在の選択を決め、ホームでカーネルの動作を制御し、オーバーライド画面で端末側に追加する変更を指定し、ログ画面で通信の最終的な行き先を検証する、というものです。この順序に沿って操作するほうが、起動を繰り返したり闇雲にノードを交換したりするより、問題を見つけやすくなります。