Clash Meta for Android 使い方徹底解説

By /

Clash Meta for Android (CMA) 使い方徹底解説：自由自在なネットワークルーティングをマスターする

まえがき：Clash Meta for Androidの世界へようこそ

インターネットは私たちの日常生活に欠かせないインフラストラクチャとなりました。Webブラウジング、動画視聴、オンラインゲーム、リモートワークなど、その用途は多岐にわたります。しかし、時には地理的な制限、検閲、あるいは単なるプライバシー保護のために、インターネット接続の方法をより柔軟にコントロールしたいと考えることがあるでしょう。そこで登場するのが、ネットワークプロキシクライアントです。

数あるプロキシクライアントの中でも、特に高機能かつ柔軟な設定が可能として知られているのが「Clash」です。そして、そのClashのコアをさらに強化し、より多くのプロトコルや高度な機能に対応したのが「Clash Meta」です。このClash MetaをAndroidデバイス上で利用可能にしたアプリケーションが、「Clash Meta for Android (CMA)」です。（しばしば「Clash for Android」と混同されますが、CMAはClash Metaコアを使用している点が異なります。後述で詳しく解説します。）

CMAは、単に「VPNのように接続する」だけでなく、通信の種類や宛先、アプリケーションなどに応じて、使用するプロキシサーバーを自動的に切り替えたり、特定の通信だけを直連（プロキシを経由しない）させたり、あるいはブロックしたりといった、非常にきめ細やかなネットワークルーティングを実現します。これは、単一のプロキシ接続では実現できない柔軟性であり、まさにインターネット接続を「自由自在にコントロールする」ための強力なツールと言えます。

しかし、その高機能さゆえに、設定はやや複雑に感じられるかもしれません。特に、設定ファイルがYAML形式で記述されるため、コマンドラインツールや設定ファイルを直接編集することに慣れていないユーザーにとっては、ハードルが高く見えるかもしれません。

この記事は、そんなClash Meta for Androidを「徹底的に使いこなす」ための詳細な解説書となることを目指します。CMAの基本的な仕組みから、設定ファイルの構造、プロキシグループの活用方法、高度なルーリング設定、DNSの詳細な設定、そしてClash Metaコア特有の機能まで、初心者の方でも理解できるように、ステップバイステップで丁寧に解説していきます。さらに、よくあるトラブルシューティングやパフォーマンス改善のヒントも盛り込みます。

この記事を読み終える頃には、あなたはClash Meta for Androidを単なるプロキシアプリとしてではなく、あなたのAndroidデバイスにおける強力なネットワークコントローラーとして活用できるようになっているはずです。さあ、Clash Meta for Androidの世界への扉を開きましょう。

第1部：Clash Metaの基本理解

Clash Meta for Androidを使い始める前に、まずはその核となる「Clash」そして「Clash Meta」の基本的な概念を理解しておきましょう。

1.1 Clashとは何か？

Clashは、もともとGo言語で開発された、クロスプラットフォーム対応のルールベースネットワークプロキシクライアントです。その最大の特徴は、設定ファイルに基づいて、様々な条件（ドメイン、IPアドレス、プロセス、地域など）によって異なるプロキシサーバーを経由させたり、直連させたりする「ルールベースルーティング」を行う点にあります。

これにより、例えば「日本のウェブサイトは直連」「海外のストリーミングサービスは特定国のプロキシ」「広告ドメインはブロック」といった複雑なネットワークポリシーを一つの設定で実現できます。

Clashは、その高機能さと柔軟性から、多くの派生プロジェクトを生み出しました。Clash for Android (CFA) もその一つであり、Android上でClashの機能を提供します。

1.2 Clash Metaとは何か？

Clash Metaは、オリジナルのClashコアから派生した高性能なフォーク（分岐プロジェクト）です。Clash Metaは、オリジナルのClashコアには含まれていない、あるいは開発が活発ではない、より新しいプロトコルや機能に対応しています。

具体的には、Metaコアは以下のような特徴を持ちます。

  • より広範なプロトコルサポート: オリジナルのClashコアよりも多くの種類のプロキシプロトコル（例: Hysteria, TUICなど）に対応している場合があります。
  • Metaコア固有の機能: Sniffing（接続先プロトコルの自動判定）、TLS Fingerprinting（TLS接続の識別に利用）、より詳細なDNS設定など、Metaコア独自あるいは強化された機能を提供します。
  • 継続的な開発: コミュニティによって積極的に開発が進められており、新しい技術への対応やパフォーマンス改善が頻繁に行われます。

Clash Meta for Android (CMA) は、このClash MetaコアをAndroidアプリケーションとしてパッケージングしたものです。そのため、CMAはオリジナルのClash for Android (CFA) とは異なるコアを使用しており、CFAにはない機能やプロトコルが利用可能です。

1.3 Clash for Android (CFA) との違い

CMAとCFAは、どちらもAndroid上でClashの設定ファイルを読み込んで動作するアプリケーションですが、使用している「Clashコア」が異なります。

  • Clash for Android (CFA): オリジナルのClashコアをベースにしています。安定しており広く使われていますが、Metaコアに比べて対応プロトコルや高度な機能の面で一部制限がある場合があります。
  • Clash Meta for Android (CMA): Clash Metaコアをベースにしています。より多くの最新プロトコルやMetaコア独自の機能を利用できますが、Metaコア自体の性質や開発状況によっては、CFAに比べてリリースサイクルが早かったり、特定の機能がベータ版であったりする場合があります。

どちらを選ぶかは、利用したいプロトコルや機能、安定性への要求によって異なります。最新の技術やプロトコルを積極的に利用したい場合はCMAが、より広範な互換性と実績を求める場合はCFAが適していると言えるでしょう。この記事では、CMAに焦点を当てて解説します。

第2部：Clash Meta for Android (CMA) の入手とインストール

CMAは公式のGoogle Playストアでは配布されていません。これは、VPNやプロキシ関連のアプリケーションに対するストアのポリシーや規制が厳しいためです。CMAは、主に開発元のGitHubリポジトリから直接APKファイルをダウンロードしてインストールします。

2.1 GitHubリリースページからのダウンロード方法

CMAの最新版または過去のバージョンは、GitHubのリリースページで公開されています。

  1. GitHubリポジトリにアクセス: WebブラウザでCMAのGitHubリポジトリページを開きます。通常、「ClashMetaForAndroid」やそれに類する名前のリポジトリを探します。開発元によってリポジトリ名や場所が変わる可能性があるため、最新の情報を確認してください。（本記事執筆時点では、MetaCubeX/ClashMetaForAndroid が主要なリポジトリの一つです。）
  2. 「Releases」セクションを探す: リポジトリのページにある「Code」「Issues」「Pull requests」「Actions」「Projects」「Wiki」「Security」「Insights」といったタブの中から、「Releases」またはリリースを表すタグ（例: 「vX.Y.Z」）を探してクリックします。
  3. 利用可能なリリースバージョンを確認: リリースページには、過去のバージョンがリスト表示されています。通常、一番上に最新のリリースが表示されます。

  4. ダウンロードするファイルを選ぶ: 各リリースの項目を展開すると、「Assets」（アセット）というセクションが表示されます。ここに、そのバージョンで利用可能なファイルがリストされています。CMAのAndroidアプリケーションファイルは通常 .apk という拡張子を持っています。

    • どのAPKファイルを選ぶか？ 通常、複数の.apkファイルがあります。デバイスのCPUアーキテクチャに合わせたファイルを選ぶのが最も効率的ですが、よく分からない場合は「universal」や「fat」といった名前の付いたファイルを選ぶと、多くのデバイスで動作する可能性があります。例えば、cma-universal-full-vX.Y.Z.apk のようなファイル名です。full は通常、Metaコアやその他の必要なコンポーネントが含まれていることを示します。
    • 署名ファイル (.asc) について: .apk ファイルの他に、.asc という拡張子のファイルがあることがあります。これはAPKファイルの署名ファイルで、ダウンロードしたファイルが改ざんされていないかを確認するために使用できます。セキュリティを重視する場合は、これもダウンロードして検証することが推奨されます。（検証方法は別途ツールの使用が必要になります。）
    • APKファイルをダウンロード: 選択した.apkファイルをクリックしてダウンロードを開始します。

2.2 GitHubのリリースバージョンの選び方

リリースページには様々なタグが付いています。

  • Latest release (最新リリース): 通常、最も安定した最新バージョンです。特に理由がなければこれを選ぶのが良いでしょう。
  • Pre-release (プレリリース): まだ開発中の機能を含んでいたり、十分にテストされていないバージョンです。新しい機能を試したい場合や、特定のバグが修正されている場合に利用しますが、安定性は低い可能性があります。
  • Older versions (過去のバージョン): 特定のバージョンに依存する理由がある場合や、最新版で問題が発生した場合に利用します。

通常ユーザーは「Latest release」を選ぶのが推奨されます。

2.3 インストール手順

GitHubからダウンロードしたAPKファイルをインストールするには、Androidの設定で「未知のソースからのアプリのインストール」を許可する必要があります。セキュリティリスクを理解した上で実行してください。

  1. ダウンロードしたAPKファイルを開く: ファイルマネージャーアプリなどを使って、ダウンロードした.apkファイルを探してタップします。
  2. 「未知のソースからのインストール」を許可: デバイスの設定によって、「提供元不明のアプリ」や「未知のソースからのインストール」がブロックされている場合があります。許可を求められたら、インストール元（通常はファイルマネージャーアプリやブラウザ）に対して、この種類のアプリのインストールを許可する設定を有効にしてください。設定方法はAndroidのバージョンやメーカーによって異なります。
  3. インストール実行: 許可設定を終えたら、再度APKファイルをタップしてインストールを開始します。「インストール」ボタンをタップして完了するまで待ちます。
  4. 完了: インストールが完了したら、「開く」をタップしてCMAを起動できます。

注意点:

  • 非公式なサイトからダウンロードしたAPKファイルは、マルウェアが含まれている可能性があります。必ず公式のGitHubリポジトリからダウンロードしてください。
  • 「未知のソースからのインストール」の許可は、セキュリティ上のリスクを伴います。CMAのインストール後、必要であればこの設定を無効に戻すことを検討してください。

2.4 アップデート方法

CMAのアップデートも、基本的に新しいバージョンのAPKファイルをダウンロードし、既存のインストールの上に重ねてインストールする形で行います。設定やプロファイルは通常維持されます。

  1. GitHubのReleasesページで新しいバージョンを確認し、ダウンロードします。
  2. ダウンロードした新しいバージョンのAPKファイルをタップしてインストールを開始します。
  3. 既存のアプリへのアップデートとして認識され、インストールが進行します。
  4. インストールが完了すればアップデートは完了です。

第3部：初期設定と基本操作

CMAをインストールしたら、次は実際に設定ファイルを読み込んでインターネット接続を開始するステップです。

3.1 初めての起動と権限許可

CMAを初めて起動すると、いくつかの権限許可を求められます。

  • VPN接続の許可: CMAはインターネットトラフィックを捕捉・ルーティングするために、AndroidシステムのVPN機能を利用します。これを有効にするために、VPN接続の確立を許可するダイアログが表示されます。「OK」や「許可」をタップしてください。この許可がないと、CMAはネットワークトラフィックを制御できません。
  • 通知の許可（任意）: バックグラウンドでの動作状況などを通知するために、通知の許可を求められることがあります。これは必須ではありませんが、許可しておくと便利です。
  • バッテリー最適化の無効化（任意）: Androidのバッテリー最適化機能により、バックグラウンドで動作するアプリが強制終了されることがあります。CMAを安定して動作させるためには、バッテリー最適化の対象からCMAを除外することが推奨されます。アプリの設定画面などから、CMAのバッテリー使用設定を「最適化しない」に変更してください。

3.2 設定ファイルのインポート方法

CMAを利用するには、Clash形式の設定ファイル（YAML形式）が必要です。このファイルには、利用可能なプロキシサーバーの情報、それらをどのようにグループ化するか、そしてどのようなルールでトラフィックをルーティングするかが記述されています。

設定ファイルは、主に以下の3つの方法でインポートできます。

  1. URLから (サブスクリプションリンク)

    • 最も一般的で推奨される方法です。多くのプロキシサービスプロバイダーは、Clash形式の設定ファイルを生成するサブスクリプションURLを提供しています。このURLをCMAに登録すると、CMAは定期的にそのURLから最新の設定ファイルをダウンロードし、自動的に更新してくれます。
    • 手順:
      • CMAのホーム画面で、「Profiles」（プロファイル）タブを選択します。
      • 画面下部にある「New Profile」（新規プロファイル）ボタンや「+」ボタンをタップします。
      • 「Import From URL」（URLからインポート）を選択します。
      • 表示された入力フィールドに、プロキシサービスから提供されたサブスクリプションURLを貼り付けます。
      • プロファイルに分かりやすい名前（例: “MyService – JP”）をつけます。
      • 「Save」（保存）ボタンをタップします。
      • CMAがURLから設定ファイルをダウンロードし、検証を行います。成功すると、プロファイルリストに表示されます。
      • リストからインポートしたプロファイルをタップして選択します。これにより、そのプロファイルがアクティブな設定として読み込まれます。

  2. ローカルファイルから

    • 手元にYAML形式の設定ファイルがある場合（自分で作成した、他の場所からダウンロードしたなど）に利用します。
    • 手順:
      • CMAのホーム画面で、「Profiles」タブを選択します。
      • 画面下部にある「New Profile」ボタンや「+」ボタンをタップします。
      • 「Import From File」（ファイルからインポート）を選択します。
      • ファイル選択画面が表示されるので、デバイス内に保存されているYAML設定ファイル（例: config.yaml）を選択します。
      • プロファイルに名前をつけて、「Save」ボタンをタップします。
      • プロファイルリストに表示された設定ファイルをタップして選択し、アクティブにします。

  3. QRコードから

    • 一部のサービスやクライアントは、Clash設定をQRコードとして提供します。
    • 手順:
      • CMAのホーム画面で、「Profiles」タブを選択します。
      • 画面下部にある「New Profile」ボタンや「+」ボタンをタップします。
      • 「Import From QR Code」（QRコードからインポート）を選択します。
      • カメラアクセスを許可します。
      • デバイスのカメラで、表示されたClash設定のQRコードを読み取ります。
      • QRコードの内容が認識されると、URLからのインポートと同様に、プロファイル名をつけて保存する画面が表示されます。保存してアクティブにします。

3.3 プロファイル管理

CMAは複数の設定ファイル（プロファイル）を管理できます。異なるプロキシサービス、異なる設定パターン（例: 全てプロキシ経由用、特定のサービスだけプロキシ用など）をプロファイルとして保存しておき、状況に応じて切り替えることが可能です。

  • プロファイルの切り替え: 「Profiles」タブで、使用したいプロファイルをタップするだけです。
  • プロファイルの編集: プロファイルリストで、プロファイルの右側にある編集アイコン（ペンや歯車のマーク）をタップすると、プロファイル名やURLを編集したり、ローカルファイルのパスを確認したりできます。
  • プロファイルの更新: サブスクリプションURLからインポートしたプロファイルの場合、プロファイルリストを下にスワイプすることで手動で最新の設定ファイルをダウンロードし直すことができます。また、設定で自動更新の間隔を設定することも可能です。
  • プロファイルのエクスポート: 現在アクティブな設定ファイルをYAML形式でエクスポートし、バックアップしたり他のデバイスと共有したりできます。
  • プロファイルの削除: 不要になったプロファイルはリストから削除できます。

3.4 簡単なインターフェース説明

CMAの主要な画面タブとその機能は以下の通りです。

  • Home (ホーム):
    • CMAの起動・停止ボタン。
    • 現在の接続状況（アップロード/ダウンロード速度、合計トラフィック量）。
    • 現在の接続モード（Global, Rule, Direct）。タップして切り替え可能。
    • Pingテストの結果や利用可能なプロキシの簡単なリスト（設定による）。
  • Profiles (プロファイル):
    • インポート済みの設定ファイル（プロファイル）のリスト。
    • 新規プロファイルのインポート（URL、ファイル、QRコード）。
    • プロファイルの選択、編集、更新、削除。
  • Proxies (プロキシ):
    • 現在アクティブなプロファイルに含まれるプロキシサーバー、およびプロキシグループのリスト。
    • select タイプのプロキシグループの場合、ここで使用するプロキシを手動で選択できます。
    • プロキシの遅延テスト（Ping）を実行できます。
  • Rules (ルール):
    • 現在アクティブなプロファイルに含まれるルールのリスト。
    • どのような通信がどのルールにマッチし、結果としてどのプロキシグループ/アクション（Proxy, Direct, Reject）が適用されるかを確認できます（ログ機能と組み合わせる）。
  • Connections (接続):
    • 現在CMAを通過しているアクティブなネットワーク接続のリスト。
    • 各接続がどのルールにマッチし、どのプロキシ/アクションが適用されているかを確認できます。
    • 特定の接続を強制的に切断することも可能です。
  • Logs (ログ):
    • CMAの動作ログ。設定ファイルの読み込みエラー、DNSクエリ、ルールマッチングの結果、接続エラーなどが表示されます。
    • 問題発生時のデバッグに非常に役立ちます。ログレベルを設定で変更できます。
  • Settings (設定):
    • CMAアプリケーション全体の詳細設定。
    • VPNモード設定、DNS設定、外部コントローラー設定、UI設定、自動アップデート設定など、様々な項目をカスタマイズできます。

CMAを使いこなす上で最も重要なのは、「Profiles」タブで適切な設定ファイルを読み込み、「Home」タブでVPN接続を有効にすること、そして必要に応じて「Proxies」タブで手動プロキシ選択や遅延テストを行うことです。さらに詳細な設定を行うには、「Settings」タブや、直接設定ファイル（YAML）の編集が必要になります。

第4部：プロファイルと設定ファイルの詳細

Clash Meta for Androidの心臓部は、使用する「設定ファイル」です。このファイルが、どのようなプロキシを利用し、どのようにルーティングを行うかの全ての指示を含んでいます。設定ファイルはYAML形式で記述されており、その構造と各パラメータの意味を理解することが、CMAを自由に使いこなすための鍵となります。

4.1 Clash設定ファイルの構造 (YAML形式の基本)

Clashの設定ファイルは、人間が読み書きしやすいデータ記述言語であるYAMLで記述されます。YAMLはインデント（字下げ）によってデータの階層構造を示します。キーと値はコロン（:）で区切られ、リスト項目はハイフン（-）で示されます。

基本的な構造は以下のようになります。

“`yaml

基本設定

port: 7890
socks-port: 7891
redir-port: 7892
allow-lan: false
mode: rule
log-level: info
unified-delay: true
sniffing:
enabled: true
timeout: 5
excluded-domains:
– ‘cdn.jsdelivr.net’ # 例: スニッフィングを除外するドメイン

DNS設定

dns:
enable: true
ipv6: false
listen: 0.0.0.0:53 # または ‘127.0.0.1:53’
enhanced-mode: fake-ip # または ‘redir-host’
fake-ip-range: 198.18.0.1/16 # fake-ip モードの場合
fake-ip-filter:
– ‘*.lan’
– ‘localhost’
– ‘captive.apple.com’
nameserver:
– ‘tls://1.1.1.1:853’ # Cloudflare DNS over TLS
– ‘quic://dns.adguard.com:784’ # AdGuard DNS over QUIC
fallback:
– ‘8.8.8.8’ # Google Public DNS (Fallback)
– ‘8.8.4.4’
fallback-filter:
geoip: true
geoip-code: CN
domains:
– ‘geosite:cn’

プロキシプロバイダー (外部ファイルからプロキシリストを取得)

proxy-providers:
myservice:
type: http # または file など
url: “https://example.com/proxies.yaml” # プロキシリストのURL
interval: 3600 # 更新間隔 (秒)
healthcheck:
enable: true
url: “http://www.gstatic.com/generate_204” # ヘルスチェックURL
interval: 300 # ヘルスチェック間隔 (秒)
# filter: “名前のパターンをフィルタリングする正規表現” # 任意

プロキシリスト (静的に設定)

proxies:
– name: “JP Node 1”
type: vmess # プロトコルの種類
server: “jp.example.com”
port: 443
uuid: “your-uuid”
alterId: 0
cipher: “auto”
tls: true
network: “ws”
ws-path: “/ws”
ws-headers:
Host: “jp.example.com”
# skip-cert-verify: true # 開発・テスト用。本番環境では非推奨。
– name: “US Node 1”
type: trojan
server: “us.example.com”
port: 443
password: “your-password”
tls: true
# skip-cert-verify: true

プロキシグループ

proxy-groups:
– name: “Proxy” # グループ名
type: select # グループタイプ
proxies: # このグループに含まれるプロキシまたは他のグループ
– “JP Node 1”
– “US Node 1”
– “Auto” # 別のグループ “Auto” を参照
– name: “Auto”
type: url-test
url: “http://www.gstatic.com/generate_204”
interval: 300 # テスト間隔 (秒)
tolerance: 50 # 遅延許容範囲 (ミリ秒)
proxies:
– “JP Node 1”
– “US Node 1”
– “🇺🇸 US Provider” # proxy-providers で定義したグループを参照
– name: “Fallback”
type: fallback
url: “http://www.gstatic.com/generate_204”
interval: 300
proxies:
– “JP Node 1”
– “US Node 1”
– name: “🇺🇸 US Provider” # proxy-providers から参照されるグループ
type: select
use: # proxy-providers で定義したプロバイダー名
– myservice
# filter: “US|アメリカ” # プロバイダー内のプロキシ名をフィルタリング

ルール

rules:
# – PROCESS,com.twitter.android,Proxy # 例: TwitterアプリはProxyグループを経由
– DOMAIN-SUFFIX,google.com,DIRECT # 例: google.comとサブドメインは直連
– GEOIP,CN,Proxy # 例: 中国のIPアドレス宛ての通信はProxyグループを経由
– MATCH,Proxy # 例: 上記どのルールにもマッチしない通信はProxyグループを経由
“`

各セクションの詳細解説

  • 基本設定 (port, socks-port, allow-lan, mode, log-level, sniffingなど):

    • port, socks-port: HTTPおよびSOCKS5プロキシサーバーとしてリッスンするポート番号。他のデバイスからCMAを介してインターネットにアクセスしたい場合に設定します。Android単体利用では通常デフォルトで問題ありません。
    • redir-port: リダイレクトプロキシとしてリッスンするポート番号。通常は使用しません。
    • allow-lan: trueに設定すると、ローカルネットワーク上の他のデバイスからCMAのHTTP/SOCKSポート経由でアクセスできるようになります。セキュリティリスクを伴うため、必要なければfalseのままにしてください。
    • mode: デフォルトのルーティングモード。
      • rule: ルールに従ってルーティングします（最も一般的）。
      • global: 全ての通信をデフォルトのプロキシグループ（通常は最初のselectグループの最初のプロキシ）経由にします。
      • direct: 全ての通信を直連にします（CMAを一時的に無効にするようなもの）。
    • log-level: ログの詳細度 (debug, info, warning, error, silent)。問題発生時はdebugやinfoが役立ちます。
    • unified-delay: trueにすると、全てのプロキシテストで同じURLを使用します。
    • sniffing: 特定のプロトコル（HTTP, TLS）をスニッフィングして、接続先情報を正確に取得し、ルールマッチング精度を向上させます。通常はenabled: trueにしておくのが推奨されます。excluded-domainsでスニッフィングしないドメインを指定できます。

  • DNS設定 (dns):

    • Clash MetaのDNS設定は非常に強力で柔軟です。詳細は後述の「第7部：DNS設定の詳細」で詳しく解説します。enhanced-mode (fake-ip or redir-host)、nameserver (使用するアップストリームDNSサーバー)、fallback (プライマリが失敗した場合のフォールバックDNS)、fake-ip-filter、fallback-filterなどが重要な項目です。

  • プロキシプロバイダー (proxy-providers):

    • 外部のURLからプロキシサーバーのリストを動的に取得・管理するためのセクションです。多くのプロキシサービスプロバイダーが、この形式で設定ファイルを提供しています。
    • type: プロバイダーのタイプ (http, fileなど)。サブスクリプションURLの場合は通常httpです。
    • url: プロキシリストをダウンロードするURL。
    • interval: プロキシリストを自動更新する間隔（秒単位）。
    • healthcheck: プロバイダー内のプロキシサーバーのヘルスチェック設定。urlでテスト対象のURL、intervalでテスト間隔を指定します。
    • filter: （任意）ダウンロードしたプロキシリストの中から、名前に特定のパターン（正規表現）を含むプロキシだけを選択する場合に使用します。例えば、特定の国名のプロキシだけを抜き出すのに便利です。
    • ここで定義したプロバイダーは、proxy-groupsセクションでuse: [provider_name]という形式で参照されます。

  • プロキシリスト (proxies):

    • 設定ファイル内にプロキシサーバー情報を直接記述する場合に使用します。個別のサーバーを手動で設定する場合や、少数のプロキシを使用する場合に便利です。
    • 各プロキシはリスト項目（-で始まる行）として定義され、name, type, server, portなどの必須情報と、プロトコル固有のパラメータ（uuid, password, tls, network, ws-pathなど）を含みます。
    • 対応しているプロトコルタイプ（type）は、Clash Metaコアのバージョンによって異なりますが、一般的にss (Shadowsocks), vmess, trojan, snell, http, socks5, hysteria, tuicなどがサポートされています。各プロトコルの詳細なパラメータはClash Metaのドキュメントを参照する必要があります。

  • プロキシグループ (proxy-groups):

    • これがClashのルールベースルーティングの中核となる部分です。複数のプロキシサーバーや他のプロキシグループをまとめて一つのグループにし、そのグループに対してルーティング指示を出します。グループ自体が、特定のロジック（速度テスト、手動選択、フォールバックなど）に基づいて、グループ内のどのプロキシを使用するかを決定します。
    • 各グループはリスト項目として定義され、name, type, proxiesなどの必須情報を含みます。proxiesリストには、このグループに含まれるプロキシの名前（proxiesセクションまたはproxy-providersで定義された名前）や、他のプロキシグループの名前を指定します。
    • 様々なtypeのグループがあり、それぞれ異なる動作をします。詳細は後述の「第5部：プロキシグループの詳細活用」で解説します。

  • ルール (rules):

    • これがClashのルーティングエンジンを動かす指示リストです。ネットワークトラフィックの属性（宛先ドメイン、IPアドレス、アプリケーション、地域など）に基づいて、そのトラフィックをどのプロキシグループまたはアクション（DIRECT直連, REJECT拒否）に送るかを決定します。
    • ルールはリスト形式で上から順に評価されます。最初にマッチしたルールが適用され、それ以降のルールは評価されません。
    • 各ルールは通常 RULE_TYPE,VALUE,PROXY_GROUP_OR_ACTION の形式で記述されます。
    • 様々なRULE_TYPEがあります。詳細は後述の「第6部：ルール設定の詳細活用」で解説します。
    • リストの最後のルールは通常 MATCH,PROXY_GROUP_OR_ACTION とし、どのルールにもマッチしなかった場合のデフォルトの動作を定義します。

4.2 設定ファイルの手動編集 (YAMLエディタの使用)

サブスクリプションURLから設定ファイルをインポートした場合でも、CMAの設定画面から直接編集することはできません（アプリによっては一部設定のみ変更可能）。設定ファイルを細かくカスタマイズしたい場合は、一度ファイルをエクスポートし、外部のテキストエディタ（YAMLに対応したものが望ましい）で編集してから、ローカルファイルとして再インポートする必要があります。

手順:

  1. CMAの「Profiles」タブで、編集したいプロファイルを選択し、エクスポート機能（通常は共有アイコンやメニューオプション）を使って設定ファイルをデバイスストレージに保存します（例: Downloadフォルダなど）。
  2. Androidデバイス上で動作するYAML/テキストエディタアプリを開きます。PCにファイルを転送して編集しても構いません。YAMLの構文ハイライトや検証機能があるエディタが推奨されます（例: QuickEdit Text Editor for Android, VS Code with YAML extension for PC）。
  3. 保存した設定ファイルを開き、必要な変更を加えます（プロキシ情報の追加/編集、プロキシグループの構成変更、ルールの追加/修正、DNS設定の調整など）。YAMLのインデントが非常に重要です。 スペースを使って正確に字下げしてください（タブ文字は避けるのが無難です）。
  4. 変更をファイルに保存します。
  5. CMAに戻り、「Profiles」タブで「New Profile」-> 「Import From File」を選択し、編集・保存したファイルをインポートします。元のプロファイルとは別のプロファイルとして追加されるか、既存のプロファイルを上書きするか選択できる場合があります。
  6. インポートした新しいプロファイルを選択し、ホーム画面でVPNを再接続して変更を反映させます。ログを確認してエラーが出ていないか確認しましょう。

手動編集は強力ですが、YAML構文エラーがあるとCMAが設定ファイルを読み込めなくなります。少しずつ変更を加え、エラーが出たらログを確認しながら修正するのが安全です。

4.3 サブスクリプション設定 (自動更新)

サブスクリプションURLからインポートしたプロファイルは、プロキシサービス側でサーバー情報が変更された際に自動的にCMA側の設定も更新できるメリットがあります。

  • 自動更新間隔: CMAの「Settings」->「Profile」->「Auto Update Interval」で、サブスクリプションプロファイルを自動更新する間隔を設定できます（例: 1時間ごと、1日ごと）。データ通信量に注意しつつ、適切な間隔を設定しましょう。
  • 手動更新: プロファイルリスト画面でリストを下にスワイプすると、いつでも手動で更新を実行できます。
  • proxy-providers の更新: 設定ファイル内でproxy-providersセクションを使用している場合、intervalパラメータでプロバイダー内のプロキシリスト自体を更新する間隔を設定できます。これはプロファイルファイル自体の更新とは別に実行されます。

第5部：プロक्सीグループの詳細活用

プロキシグループは、複数のプロキシサーバーや他のプロキシグループをまとめて管理し、特定のロジックに基づいて使用するサーバーを決定するための機能です。Clashのルーリングにおいて、ルールが「どのグループを使うか」を指定し、グループが「その中でどのサーバーを使うか」を決定します。様々なタイプのプロキシグループを組み合わせることで、柔軟で効率的なネットワークルーティングを実現できます。

以下に主要なプロキシグループのタイプと、その活用方法を解説します。

5.1 select グループ (手動選択)

  • 機能: グループに含まれるプロキシサーバーの中から、ユーザーが手動で一つを選択して使用します。CMAの「Proxies」タブで、このタイプのグループに対応する項目をタップすると、利用可能なプロキシのリストが表示され、選択できます。

  • 設定例:

    yaml
    proxy-groups:
    - name: "Manual Select Proxy"
    type: select
    proxies:
    - "JP Server 1"
    - "US Server 2"
    - "SG Server 3"
    - "Auto Speed Test" # 別のグループを参照

  • 活用:

    • 特定の国やサーバーを手動で選びたい場合。
    • 速度テスト結果を見ながら最適なサーバーを選びたい場合。
    • 複数のプロキシグループへの入り口として、ユーザーが次のステップ（例: 速度テストグループ、フォールバックグループなど）を選択できるようにする場合。
  • CMAでの表示: 「Proxies」タブにグループ名「Manual Select Proxy」が表示され、タップすると「JP Server 1」「US Server 2」「SG Server 3」「Auto Speed Test」という選択肢が表示されます。

5.2 url-test グループ (速度テストによる自動選択)

  • 機能: グループに含まれるプロキシサーバーに対し、指定したURLへの接続速度（遅延）を定期的にテストし、最も遅延の少ないサーバーを自動的に選択して使用します。サーバー障害発生時には、遅延が許容範囲外になったサーバーを一時的に使用対象から外し、利用可能な中で最も速いサーバーを選び直します。

  • 設定例:

    yaml
    proxy-groups:
    - name: "Auto Speed Test"
    type: url-test
    url: "http://www.gstatic.com/generate_204" # テスト対象URL (到達可能な軽量なURLが望ましい)
    interval: 600 # テスト間隔 (秒, 例: 10分ごと)
    tolerance: 50 # 遅延許容範囲 (ミリ秒)。遅延がこの値を超えると、同じ遅延のサーバーがあった場合にそちらを選ぶ。
    proxies:
    - "JP Server 1"
    - "JP Server 2"
    - "JP Server 3"
    - "SG Server 1"

  • 活用:

    • 複数の同一地域または近距離のサーバーがあり、常に最も速いサーバーを自動で使いたい場合。
    • サーバーの状態が変動しやすく、遅延に基づいて最適なサーバーを自動選択させたい場合。
  • 注意点: urlに指定するURLは、プロキシを経由せずに直連で到達可能なURLであり、かつ高速に応答を返す軽量なものが適しています。http://www.gstatic.com/generate_204 や http://cp.cloudflare.com/generate_204 などがよく使われます。あまり頻繁にテストするとリソースを消費します。

5.3 fallback グループ (プライマリ失敗時のフォールバック)

  • 機能: グループに含まれるプロキシサーバーをリストの順序で評価します。最初のサーバーをプライマリとして使用しようとし、指定したURLへのヘルスチェックが失敗した場合（接続できない、タイムアウトなど）に、リストの次のサーバーに自動的に切り替えて使用します。全てのサーバーが失敗した場合は、グループ全体が使用不能と判断されます。

  • 設定例:

    yaml
    proxy-groups:
    - name: "Reliable Fallback"
    type: fallback
    url: "http://www.gstatic.com/generate_204" # ヘルスチェックURL
    interval: 300 # ヘルスチェック間隔 (秒)
    proxies:
    - "Main Server" # プライマリ
    - "Backup Server 1" # プライマリ失敗時のフォールバック先1
    - "Backup Server 2" # フォールバック先1失敗時のフォールバック先2

  • 活用:

    • 安定性が最優先される通信（例: リモートワーク、ビデオ会議）で、プライマリサーバーが落ちた場合にすぐにバックアップサーバーに切り替えたい場合。
    • 特定のリソースにアクセスする際に、複数の代替サーバーを用意しておき、自動的に切り替えたい場合。
  • 注意点: url-testとは異なり、fallbackは「遅延が少ないサーバーを選ぶ」のではなく、「生きているサーバーの中でリストの先頭に近いものを選ぶ」という挙動をします。

5.4 load-balance グループ (負荷分散)

  • 機能: グループに含まれるプロキシサーバー間で、接続をラウンドロビン方式などのアルゴリズムで分散させます。

  • 設定例:

    yaml
    proxy-groups:
    - name: "Load Balance Group"
    type: load-balance
    strategy: consistent-hashing # または round-robin
    proxies:
    - "Server A"
    - "Server B"
    - "Server C"

  • 活用:

    • 大量の同時接続を複数のサーバーに分散させたい場合。
    • 利用可能なリソースを均等に活用したい場合。
  • 注意点: ストリーミングサービスなど、セッション維持が重要なサービスでは、load-balanceを使うとIPアドレスが頻繁に変わる可能性があり、サービスの利用に支障が出る場合があります。一般的にはurl-testやselectの方が使いやすいことが多いです。

5.5 relay グループ (プロキシチェイン)

  • 機能: 複数のプロキシサーバーを順番に経由させる、いわゆる「プロキシチェイン」を構築します。トラフィックはリストの最初のプロキシから始まり、次のプロキシ、その次のプロキシ…と順番に通過し、リストの最後のプロキシから最終的な宛先に到達します。

  • 設定例:

    yaml
    proxy-groups:
    - name: "JP via US"
    type: relay
    proxies:
    - "US Server" # まずUSサーバーを経由
    - "JP Server" # 次にJPサーバーを経由して宛先へ

  • 活用:

    • セキュリティや匿名性を高めるために多段階のプロキシを経由したい場合（ただし遅延は増加します）。
    • 特定の国から別の国を経由してアクセスしたい場合（例: 日本からアメリカを経由して特定のサービスにアクセス）。
  • 注意点: チェイン内のいずれかのプロキシが機能しないと、チェイン全体が機能しなくなります。また、各ステップで暗号化/復号化が行われる場合、パフォーマンスへの影響が大きくなります。

5.6 try-all グループ (Metaコア固有)

  • 機能: url-test や fallback に似ていますが、接続試行がより積極的です。リスト内のプロキシを順番に全て試行し、最初に成功したプロキシを使用します。ヘルスチェックに失敗したプロキシは一時的に使用対象から外されますが、後で再度試行される可能性があります。

  • 設定例:

    yaml
    proxy-groups:
    - name: "Try All Servers"
    type: try-all
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    proxies:
    - "Server A"
    - "Server B"
    - "Server C"

  • 活用:

    • 利用可能なプロキシのどれかが生きていれば良い、という状況で、自動的に生きているプロキシを見つけて接続したい場合。
    • 特にプロキシの生存率が低い場合に、接続試行を繰り返して粘り強く接続を確立したい場合。
  • 注意点: 接続試行が増えるため、ログが大量に出力されたり、リソース消費が増えたりする可能性があります。

グループ設定例：複雑なルーティングの構築

これらのグループタイプを組み合わせることで、非常に柔軟なルーティングポリシーを構築できます。

例：

“`yaml
proxy-groups:
# ユーザーが手動で全体の接続方式を選択するグループ
– name: “Global Policy”
type: select
proxies:
– “Proxy” # 通常のプロキシグループを参照
– “Direct” # 直連
– “Reject” # 拒否

# 通常のプロキシ通信に使用するグループ。速度テストで最適な日本のサーバーを選ぶ。
– name: “Proxy”
type: url-test
url: “http://www.gstatic.com/generate_204”
interval: 600
tolerance: 50
proxies:
– “🇯🇵 JP Auto” # 日本のプロキシ自動選択グループ
– “🇺🇸 US Auto” # アメリカのプロキシ自動選択グループ
– “Reliable Fallback” # フォールバックグループ

# 日本のプロキシサーバー群から速度テストで選ぶグループ (proxy-providersを使用)
– name: “🇯🇵 JP Auto”
type: url-test
url: “http://www.gstatic.com/generate_204”
interval: 600
use: # proxy-providers セクションで定義したプロバイダー名
– MyProviderJP
filter: “JP|日本” # プロバイダー内のプロキシ名から日本関連をフィルタリング

# アメリカのプロキシサーバー群から速度テストで選ぶグループ (proxy-providersを使用)
– name: “🇺🇸 US Auto”
type: url-test
url: “http://www.gstatic.com/generate_204”
interval: 600
use:
– MyProviderUS
filter: “US|アメリカ”

# 重要なサービス向けの信頼性重視フォールバックグループ
– name: “Reliable Fallback”
type: fallback
url: “http://www.gstatic.com/generate_204”
interval: 300
proxies:
– “Main Server A” # 静的に定義したメインサーバー
– “Backup Server B” # 静的に定義したバックアップサーバー
– “🇺🇸 US Auto” # 信頼できる地域の自動選択グループ

rules:
– PROCESS,com.google.android.gm,DIRECT # Gmailアプリは直連
– DOMAIN-SUFFIX,netflix.com,🇺🇸 US Auto # Netflixはアメリカの自動選択グループ
– GEOIP,CN,Proxy # 中国宛てはProxyグループ
– MATCH,Global Policy # それ以外はGlobal Policyグループ (手動選択)
“`

この例では、「Global Policy」グループを手動で「Proxy」「Direct」「Reject」の中から選択できます。さらに、「Proxy」グループは「🇯🇵 JP Auto」「🇺🇸 US Auto」「Reliable Fallback」の3つのグループから、速度テストに基づいて最適なグループを選びます。各地域の自動選択グループは、プロバイダーから取得したリストをフィルタリングし、その中から速度テストを行います。「Reliable Fallback」は、特定のサーバー群を順次試します。最終的に、どのトラフィックがどのルールにマッチし、どのグループを経由するかによって、使用されるプロキシサーバーが決定されます。

このように、プロキシグループを多層的に構成することで、非常に複雑なルーティングポリシーを実現できます。

第6部：ルール設定の詳細活用

ルールは、Clashがネットワークトラフィックをどのようにルーティングするかを決定するための最も基本的な指示です。設定ファイルのrulesセクションに記述され、上から順に評価されます。特定のトラフィックがどのルールにもマッチしなかった場合、リストの最後に定義されたMATCHルールが適用されます。

ルールの基本的な構文は RULE_TYPE,VALUE,PROXY_GROUP_OR_ACTION です。

  • RULE_TYPE: マッチングの条件を指定します。
  • VALUE: マッチングの基準となる値（ドメイン名、IPアドレス、地域コードなど）を指定します。
  • PROXY_GROUP_OR_ACTION: マッチした場合に適用するアクションを指定します。これはプロキシグループの名前（例: Proxy, Auto Select）または特別なアクション（DIRECT, REJECT）です。

以下に主要なルールタイプとその活用方法を解説します。

6.1 主要なルールタイプ

  • DOMAIN,hostname,POLICY: 指定した完全なドメイン名にマッチします。
    • 例: DOMAIN,www.google.com,DIRECT (www.google.com へのアクセスを直連)
  • DOMAIN-SUFFIX,suffix,POLICY: 指定した接尾辞（ドメインの末尾部分）を持つドメイン名にマッチします。サブドメインを含む場合に便利です。
    • 例: DOMAIN-SUFFIX,google.com,DIRECT (google.com およびその全てのサブドメイン、例: mail.google.com, drive.google.com へのアクセスを直連)
    • 例: DOMAIN-SUFFIX,.cn,Proxy (中国のトップレベルドメイン (.cn) を持つドメインへのアクセスをProxyグループ経由)
  • DOMAIN-KEYWORD,keyword,POLICY: 指定したキーワードを含むドメイン名にマッチします。
    • 例: DOMAIN-KEYWORD,ads,REJECT (ドメイン名に “ads” が含まれるアクセスを拒否 – 広告ブロックの簡易版)
  • GEOIP,country_code,POLICY: 接続先のIPアドレスが指定した国コードに属する場合にマッチします。IPデータベース（GeoLite2など）が必要です。国コードはISO 3166-1 Alpha-2形式で指定します（例: CN 中国, US アメリカ, JP 日本）。!CN のように否定形も使用できます。
    • 例: GEOIP,CN,Proxy (接続先が中国のIPアドレスであればProxyグループ経由)
    • 例: GEOIP,!CN,DIRECT (接続先が中国以外のIPアドレスであれば直連)
    • 例: GEOIP,LAN,DIRECT (ローカルネットワーク内のIPアドレスであれば直連 – これは通常必要です)
  • IP-CIDR,ip_cidr,POLICY: 接続先のIPアドレスが指定したCIDRブロック（IPアドレス範囲）に属する場合にマッチします。
    • 例: IP-CIDR,192.168.1.0/24,DIRECT (192.168.1.0/24 のローカルネットワーク内のIPアドレスを直連)
    • 例: IP-CIDR,10.0.0.0/8,DIRECT (プライベートIPアドレス範囲の直連設定としてよく使われます)
    • 例: IP-CIDR,0.0.0.0/32,DIRECT (0.0.0.0 アドレスの直連)
    • no-route オプションを付けると、そのIP範囲へのルーティングを試みないようになります (IP-CIDR,192.168.1.0/24,DIRECT,no-route)。
  • SRC-IP-CIDR,ip_cidr,POLICY: 接続元のIPアドレスが指定したCIDRブロックに属する場合にマッチします。Androidデバイス単体利用ではあまり使われません。
  • PROCESS,process_name,POLICY: 接続を開始したAndroidアプリケーションのパッケージ名（プロセス名）にマッチします。
    • 例: PROCESS,com.twitter.android,Proxy (Twitterアプリからの通信はProxyグループ経由)
    • 例: PROCESS,com.android.vending,DIRECT (Google Playストアアプリからの通信は直連)
    • プロセス名はCMAのConnectionsタブや他のツールで確認できます。
  • DST-PORT,port,POLICY: 接続先のポート番号にマッチします。
    • 例: DST-PORT,22,Proxy (SSH (ポート22) 通信はProxyグループ経由)
  • SRC-PORT,port,POLICY: 接続元のポート番号にマッチします。Androidデバイス単体利用ではあまり使われません。
  • MATCH,POLICY: 上記のどのルールにもマッチしなかった、全ての残りのトラフィックにマッチします。これはルールリストの最後に必ず一つ記述する必要があります。 これがないと、どのルールにもマッチしないトラフィックが処理されずにブロックされる可能性があります。
    • 例: MATCH,Proxy (デフォルトで全ての通信をProxyグループ経由)
    • 例: MATCH,DIRECT (デフォルトで全ての通信を直連 – 特定のルールにマッチするものだけプロキシ経由にしたい場合)

6.2 ルールマッチングの優先順位

Clashはルールを上から順に評価し、最初にマッチしたルールを適用します。ルールの順序は非常に重要です。 より限定的なルールは、より一般的なルールの前に記述する必要があります。

悪い例 (意図しない挙動になる可能性):

yaml
rules:
- DOMAIN-SUFFIX,google.com,DIRECT # google.comとサブドメインを直連
- DOMAIN,mail.google.com,Proxy # mail.google.com を Proxy 経由にしたい
- MATCH,Proxy

この場合、mail.google.com へのアクセスは最初のルール DOMAIN-SUFFIX,google.com,DIRECT にマッチして直連されてしまい、二番目のルール DOMAIN,mail.google.com,Proxy は評価されません。

良い例 (より限定的なルールを先に):

yaml
rules:
- DOMAIN,mail.google.com,Proxy # mail.google.com は Proxy 経由
- DOMAIN-SUFFIX,google.com,DIRECT # それ以外の google.com とサブドメインは直連
- MATCH,Proxy

この順序であれば、mail.google.com は最初のルールにマッチしてProxy経由となり、それ以外の google.com や www.google.com などは二番目のルールにマッチして直連となります。

一般的に、ルールリストは以下の順序で記述するのが推奨されます。

  1. ローカルネットワーク関連 (GEOIP,LAN, IP-CIDR プライベートIP帯など): DIRECT にすることが多い
  2. 特定のアプリケーション (PROCESS): DIRECT または特定のプロキシグループ
  3. 特定の完全一致ドメイン (DOMAIN): DIRECT または特定のプロキシグループ
  4. 特定のキーワードを含むドメイン (DOMAIN-KEYWORD): REJECT (広告ブロックなど)
  5. 特定の接尾辞ドメイン (DOMAIN-SUFFIX): DIRECT または特定のプロキシグループ
  6. 特定のIPアドレス範囲 (IP-CIDR パブリックIP帯): DIRECT または特定のプロキシグループ
  7. 特定の地域 (GEOIP 特定の国): 特定のプロキシグループまたは REJECT
  8. 特定のポート (DST-PORT)
  9. MATCH,POLICY: 最後のデフォルトルール

6.3 複雑なルールセットの構築例

上記を踏まえ、いくつかの複雑なルールセットの例を考えます。

例1：特定のサービスだけ海外プロキシ、その他は直連、広告ブロックも

“`yaml
rules:
# ローカルネットワークとプライベートIPは直連 (必須級)
– GEOIP,LAN,DIRECT
– IP-CIDR,127.0.0.0/8,DIRECT
– IP-CIDR,10.0.0.0/8,DIRECT
– IP-CIDR,100.64.0.0/10,DIRECT # CG-NAT などの範囲
– IP-CIDR,172.16.0.0/12,DIRECT
– IP-CIDR,192.168.0.0/16,DIRECT
– IP-CIDR,0.0.0.0/32,DIRECT

# 特定の海外サービスは海外プロキシグループ (例: Netflix, Hulu)
– DOMAIN-SUFFIX,netflix.com,US_Proxy
– DOMAIN-SUFFIX,hulu.com,US_Proxy # .com 以外にも .jp などが必要な場合あり
– DOMAIN-SUFFIX,hulu.jp,US_Proxy

# 広告関連のドメインを拒否 (簡易的な広告ブロック)
– DOMAIN-KEYWORD,ad,REJECT
– DOMAIN-SUFFIX,googlesyndication.com,REJECT
# より詳細な広告ブロックリストは別途インポートするか、別のルールタイプを使うのが一般的 (例: geosite)

# それ以外の全ての通信は直連 (デフォルトは直連)
– MATCH,DIRECT
“`
この例では、必要なサービスだけを海外プロキシ経由にし、それ以外の通信は全て直連にしています。広告ブロックもキーワードベースで追加しています。

例2：日本国内は直連、海外は地域に応じてプロキシを使い分け

“`yaml
rules:
# ローカルネットワークとプライベートIPは直連
– GEOIP,LAN,DIRECT
– IP-CIDR,127.0.0.0/8,DIRECT
– IP-CIDR,10.0.0.0/8,DIRECT
– IP-CIDR,100.64.0.0/10,DIRECT
– IP-CIDR,172.16.0.0/12,DIRECT
– IP-CIDR,192.168.0.0/16,DIRECT
– IP-CIDR,0.0.0.0/32,DIRECT

# 日本国内のIPアドレスは直連
– GEOIP,JP,DIRECT

# 中国のIPアドレスは特定のプロキシグループ経由
– GEOIP,CN,CN_Proxy

# それ以外の海外IPアドレスは別の汎用プロキシグループ経由
– MATCH,Global_Proxy
``
この例では、日本のIP宛ては直連とし、中国宛ては専用プロキシ、それ以外の海外宛ては別のプロキシグループを経由させるようにしています。GEOIP` ルールは非常に強力で、地域制限の解除や、特定の地域のサービスへのアクセス制御に役立ちます。

6.4 GEOIPデータベースの活用

GEOIP ルールを使用するためには、CMAが最新のGeoLite2などのIPデータベースにアクセスできる必要があります。通常、設定ファイルが読み込まれる際に自動的にダウンロード・更新されますが、手動で更新したり、特定のファイルを使用するように設定したりできる場合もあります。CMAの設定画面やログで、GEOIPデータベースの状態を確認できます。

6.5 特殊なルールタイプ (Metaコア固有など)

Metaコアは、オリジナルのClashコアにはない、あるいは強化されたルールタイプをサポートしている場合があります。

  • PROCESS-NAME,process_name,POLICY: PROCESS と同様、アプリケーション名でマッチします。（Metaコアでは PROCESS が推奨されることが多い）
  • SRC-PORT,port,POLICY: 接続元ポート。
  • RULE-SET,rule_set_name,POLICY: 外部ファイルで定義されたルールセットを参照する。大規模なルールリストをモジュール化するのに便利。

また、geosite や geoip といったClashのルールセット形式をサポートしている場合があります。これらは、ドメインやIPアドレスのリストをまとめた外部ファイルで、設定ファイルを簡潔に保つのに役立ちます。例えば、geosite:cn は中国国内の主要なドメインリスト、geoip:cn は中国国内のIPアドレスリストを指します。これらをルール内で使用できます。

  • 例: - DOMAIN-SUFFIX,geosite:cn,Proxy (geosite:cn に含まれる全てのドメインをProxy経由) – これは通常 geosite ルールタイプと組み合わせて使用します。
  • 例: - GEOIP,geoip:cn,Proxy (geoip:cn に含まれる全てのIPアドレスをProxy経由) – これは通常 geoip ルールタイプと組み合わせて使用します。

これらの高度なルールタイプやルールセットの利用方法は、使用しているClash Metaコアのバージョンや、プロキシサービスプロバイダーが提供する設定ファイルによって異なります。設定ファイルの説明やMetaコアの公式ドキュメントを参照するのが確実です。

ルール設定はCMAの機能の中核であり、あなたのネットワークトラフィックをどのように制御するかを決定します。時間をかけて様々なルールを試し、あなたのニーズに最適な設定を構築してください。CMAのConnectionsタブで、各接続がどのルールにマッチしているかを確認しながら調整すると効率的です。

第7部：DNS設定の詳細

DNS (Domain Name System) は、人間が覚えやすいドメイン名（例: google.com）を、コンピュータが通信に使用するIPアドレス（例: 172.217.160.142）に変換するシステムです。Clash Meta for AndroidにおけるDNS設定は、単なる名前解決だけでなく、プライバシー保護、セキュリティ向上、特定の地域制限回避、さらにはパフォーマンス改善にも大きく関わる重要な要素です。

Clash MetaのDNS設定は非常に柔軟で、設定ファイルのdnsセクションで行います。

yaml
dns:
enable: true # DNS 기능을 활성화할지 여부
ipv6: false # IPv6 DNS 쿼리를 활성화할지 여부 (IPv6 환경이 아니면 false)
listen: 0.0.0.0:53 # Clash가 DNS 쿼리를 수신할 주소 및 포트 (일반적으로 로컬 주소)
enhanced-mode: fake-ip # 또는 redir-host. 후술할 DNS 모드 선택.
fake-ip-range: 198.18.0.1/16 # fake-ip 모드일 경우 가상 IP 대역
fake-ip-filter: # fake-ip 모드일 경우 가상 IP를 사용하지 않을 도메인 목록
- '*.lan'
- 'localhost'
- 'captive.apple.com'
- '+.stun.*.*' # STUN 도메인 (일부 서비스 호환성)
- '+.nat.*.*' # NAT 도메인 (일부 서비스 호환성)
- '+.stun.*.*.*'
- '+.nat.*.*.*'
- '.msftconnecttest.com'
- '.msftncsi.com'
nameserver: # 기본 업스트림 DNS 서버 목록 (우선 순위)
- 'tls://1.1.1.1:853' # Cloudflare DNS over TLS (DoT)
- 'quic://dns.adguard.com:784' # AdGuard DNS over QUIC (DoQ)
- 'https://dns.google/dns-query' # Google DNS over HTTPS (DoH)
- 'tcp://8.8.8.8' # Google Public DNS (TCP)
- 'udp://8.8.8.8' # Google Public DNS (UDP)
fallback: # nameserver 의 모든 서버가 실패했거나 특정 조건에 해당할 경우 사용할 DNS 서버 목록
- '8.8.4.4'
- '208.67.222.222' # OpenDNS
fallback-filter: # fallback DNS 서버를 사용하게 하는 조건
geoip: true # 지리 정보 필터 활성화
geoip-code: CN # 쿼리된 IP가 중국일 경우 fallback 사용
domains: # 특정 도메인일 경우 fallback 사용
- 'geosite:cn'
- '+.google.com' # Google 관련 도메인일 경우 (중국에서 사용 시 유용)
domain-keyword: # 특정 키워드를 포함한 도메인일 경우 fallback 사용
- 'facebook' # 예: Facebook 관련 도메인
domain-suffix: # 특정 접미사를 가진 도메인일 경우 fallback 사용
- 'youtube.com' # 예: youtube.com 및 서브도메인
# specific-attribute: # Meta 코어의 특정 속성 기반 DNS 설정 (사용하는 코어 버전에 따라 다름)
# example.com:
# nameserver: ['8.8.8.8'] # example.com 쿼리는 8.8.8.8 만 사용
# +.another.org:
# fallback: ['1.1.1.1'] # another.org 와 서브도메인 쿼리는 fallback 으로 1.1.1.1 사용

7.1 DNSモード (enhanced-mode)

Clash Metaは、トラフィックルーティングの精度を高めるために、独自のDNS処理モードを提供します。

  • fake-ip:
    • Clash Metaが、DNSクエリに対して実際のIPアドレスではなく、プライベートIPアドレス範囲（デフォルトでは 198.18.0.1/16）から割り当てた「偽のIPアドレス (Fake IP)」を返答します。
    • クライアントアプリケーションは偽のIPアドレスに接続を試みますが、この接続は実際にはClash Metaによって傍受されます。
    • Clash Metaは傍受した接続から、元のドメイン名を特定し、そのドメイン名とルールを照合して使用するプロキシグループを決定します。実際のプロキシ接続は、Clash Metaが内部的に解決した実際のIPアドレスに対して行われます。
    • メリット:
      • SNI (Server Name Indication) に依存しないルーティング: TLS接続などで暗号化された後でも、元のドメイン名に基づいて正確なルーティングが可能です。これは特に、SNIを偽装するような技術（例: TLS in TLS）に対しても有効なルーティングが行える可能性を示唆します。
      • 複雑なルーリングへの対応: アプリケーションレベルやドメインレベルでの正確なルール適用が容易になります。
    • デメリット:
      • 一部のアプリケーションやサービス（特にP2Pアプリケーションや、独自のIPアドレスチェックを行うもの）で互換性の問題が発生する可能性があります。
      • fake-ip-filterで除外リストを適切に設定しないと問題が発生しやすいです。
  • redir-host:
    • Clash Metaは、DNSクエリに対して実際のIPアドレスを返答します。
    • クライアントアプリケーションは返答された実際のIPアドレスに接続を試みますが、この通信はAndroidのVPN機能によってClash Metaにリダイレクトされます。
    • Clash Metaはリダイレクトされた通信から接続先のIPアドレスとポートを取得し、必要に応じてSniffing機能を使ってドメイン名を特定しようと試みます。そして、ドメイン名やIPアドレス、ポートなどの情報とルールを照合してルーティングを決定します。
    • メリット:
      • 多くのアプリケーションとの互換性が高いです。
      • fake-ipで問題が発生する場合の代替として有効です。
    • デメリット:
      • Sniffingが有効でない場合や、プロトコルによっては正確なドメイン名を取得できないことがあり、その場合はIPアドレスベースのルーティングに限定される可能性があります。
      • SNI偽装などに対してはルールが正確に適用できない場合があります。

一般的には、より強力なルーティング制御と互換性のバランスからfake-ipが推奨されますが、問題が発生する場合はredir-hostを試してみてください。fake-ip-filterで除外するドメインを適切に設定することも重要です。

7.2 アップストリームDNSサーバー (nameserver, fallback)

Clash Meta自身が名前解決を行うために使用するDNSサーバーを指定します。

  • nameserver:
    • Clash Metaが優先的に使用するDNSサーバーのリストです。上から順に試行されます。
    • ここに指定するDNSサーバーは、プロキシを経由せずに直連でアクセスできる必要があります（Clash MetaがDNSクエリ自体をプロキシ経由で送る設定もありますが、通常は直連です）。
    • プライバシー保護やセキュリティの観点から、DoH (DNS over HTTPS)、DoT (DNS over TLS)、DoQ (DNS over QUIC) のような暗号化されたDNSプロトコルを使用することが強く推奨されます。
      • DoH: https://dns.google/dns-query のようなURL形式
      • DoT: tls://1.1.1.1:853 のような tls://IP:Port 形式
      • DoQ: quic://dns.adguard.com:784 のような quic://IP:Port 形式
    • 従来のUDP/TCP DNSも指定可能です (udp://8.8.8.8, tcp://8.8.8.8)。
  • fallback:
    • nameserverリストの全てのサーバーが応答しないか、またはfallback-filterで指定された条件にマッチした場合に代替として使用するDNSサーバーのリストです。
    • 特定の地域に偏らない、汎用的なDNSサーバー（例: Google Public DNS, OpenDNS, Cloudflare Public DNS）を指定することが多いです。
    • 検閲回避のために、検閲されていないDNSサーバーを指定することもあります。

7.3 フォールバック条件 (fallback-filter)

どのような場合にfallbackリストのDNSサーバーを使用するかを定義します。

  • geoip: true と geoip-code: COUNTRY_CODE: 解決されたIPアドレスが指定した国コードに属する場合にフォールバックを使用します。例えば、geoip-code: CN と設定すると、DNSクエリの結果が中国のIPアドレスだった場合に、そのクエリの応答を受け取ったnameserverではなくfallbackのサーバーを使おうとします。これは、nameserverが毒されたDNS応答（例: 中国国内からのクエリに対する偽の応答）を返してきた場合に、信頼できるfallbackサーバーに切り替えて正しい応答を得ようとする目的で利用されます。
  • domains: [...]: 指定したドメインリスト（geositeを含む）にクエリされたドメインが含まれる場合にフォールバックを使用します。
  • domain-keyword: [...]: 指定したキーワードを含むドメイン名にクエリされた場合にフォールバックを使用します。
  • domain-suffix: [...]: 指定した接尾辞を持つドメイン名にクエリされた場合にフォールバックを使用します。

これらのフィルターは、特定の地域やドメインに関するDNS応答の信頼性を高めるために使用されます。

7.4 DNS設定によるパフォーマンス改善とプライバシー保護

  • パフォーマンス:
    • 高速で応答性の高いDNSサーバーをnameserverリストの先頭に配置することで、名前解決の速度を向上させることができます。
    • unified-delay: true は、プロキシの遅延テストでDNS解決時間を含めるかどうかに影響します。
  • プライバシー保護:
    • DoH, DoT, DoQ を使用することで、ISPやネットワークの監視者からDNSクエリの内容を秘匿できます。これは、あなたがどのようなウェブサイトにアクセスしようとしているかを知られないようにする上で非常に重要です。
    • 信頼できるDNSサーバーを選択することが重要です。

7.5 Metaコア特有のDNS機能

Clash Metaコアは、オリジナルのClashコアに加えて、より高度なDNS設定オプションを提供することがあります。例えば、特定のドメインに対して異なるDNSサーバーを設定したり（specific-attributeのようなもの）、DNS応答の最小TTL (Time To Live) を制御したりする機能です。これらの機能の詳細は、使用しているCMAのバージョンやMetaコアのドキュメントを確認する必要があります。

DNS設定はClash Metaの強力な機能の一つですが、設定ミスはインターネット接続全体に影響を与える可能性があります。特にfake-ipモードやfallback-filterの設定は注意深く行う必要があります。CMAのLogsタブでDNSクエリのログを確認し、意図した通りに名前解決が行われているかデバッグすることをお勧めします。

第8部：高度な機能と設定

Clash Meta for Androidは、その基盤となるClash Metaコアが持つ様々な高度な機能を活用できます。これらの機能を使うことで、より洗練された、あるいは特定の状況に特化したネットワーク制御が可能になります。

8.1 Metaコアの追加機能

Metaコアは、オリジナルのClashコアにはない、あるいは強化された以下のような機能を提供します。

  • 嗅探 (Sniffing):
    • 機能: TCP接続の最初の数パケットを分析して、接続がHTTPかTLSか（そしてTLSの場合はSNIからドメイン名）を自動的に判別する機能です。
    • 活用: redir-host モードで、IPアドレスしか分からない通信から正確なドメイン名を特定し、ドメインベースのルールを適用するために必須です。fake-ip モードでも、一部の特殊なケースで役立つことがあります。
    • 設定: sniffing: セクションで enabled: true と設定します。timeout でスニッフィングを行う最大時間、excluded-domains でスニッフィングを除外するドメインを指定できます。
  • TUNモード:
    • 機能: AndroidのVPN機能を使って、より低レベル（IPパケットレベル）でネットワークトラフィックを捕捉・処理するモードです。
    • redirモードとの違い: 従来のredirモードはTCP/UDP接続のリダイレクトに依存しますが、TUNモードはシステム全体のIPトラフィックをClash Metaが管理する仮想ネットワークインターフェースに流し込みます。
    • 活用: redirモードでは捕捉できない種類の通信（例: 一部のゲームや特殊なアプリケーションの通信）も処理できるようになります。より広範な互換性を提供します。
    • 設定: CMAのSettingsタブや設定ファイルでTUNモードを有効にするオプションがあります。通常、tun: セクションで enable: true や stack: system または gvisor のようなスタックタイプを選択します。Root化されていないデバイスでも利用可能ですが、一部の細かい設定（特定のUID/GID除外など）はRoot権限が必要な場合があります。
  • 混合観察 (Mixed-port):
    • 機能: HTTPプロキシとSOCKS5プロキシの両方の機能を提供する単一のポートを開く機能です。
    • 活用: クライアントアプリケーション側でHTTPまたはSOCKS5のどちらか指定されたプロキシタイプしか設定できない場合に便利です。
    • 設定: 設定ファイルの基本設定セクションで mixed-port: PortNumber と設定します。
  • TLS指紋 (TLS Fingerprinting):
    • 機能: TLSクライアントHelloパケットの特定の属性（暗号スイートの順序、拡張機能など）を分析し、接続元のアプリケーション（ブラウザの種類など）を識別しようとする機能です。
    • 活用: 特定のアプリケーションからの通信に対して、プロキシサービス側でブロックや制限が行われている場合に、そのブロックを回避するためにTLS指紋を偽装する（特定のブラウザの指紋に合わせる）目的などで利用されることがあります。Metaコアがクライアント側のTLS指紋偽装をサポートしている場合、設定ファイルで指定できます。
    • 設定: プロキシ設定（proxiesセクション）やグローバル設定で、client-fingerprint: browser_name のような形で指定します。（例: chrome, firefox, ios, androidなど）この機能のサポート状況や設定方法はMetaコアのバージョンによって異なります。

これらのMetaコア固有機能は、一般的な用途では必須ではありませんが、特定の技術的な課題に対処したり、パフォーマンスや匿名性を向上させたりするのに役立ちます。機能の詳細や設定方法は、利用しているCMAのバージョンに同梱されているMetaコアのドキュメントを参照するのが最も確実です。

8.2 外部コントローラー (Clash Dashboardなどとの連携)

Clash Metaは、外部のアプリケーションやWebインターフェースから制御するためのAPIを提供します。これを「外部コントローラー」と呼びます。これにより、Androidアプリの画面だけでなく、PCのブラウザなどからClash Meta for Androidの状態監視、プロキシ切り替え、設定変更などを行うことができます。

  • 設定方法:

    • 設定ファイルの基本設定セクションで、external-controller と secret を設定します。
      yaml
      external-controller: '0.0.0.0:9090' # または '127.0.0.1:9090' (ローカルからのみアクセス許可)
      secret: 'your_api_secret' # 外部からのアクセスに使用するパスワード (任意の文字列)
      external-controllerには、外部からのアクセスを許可するIPアドレスとポートを指定します。0.0.0.0は全てのインターフェースからのアクセスを許可します（セキュリティリスクに注意）。secretには、APIアクセス時に認証に使用する任意のパスワードを設定します。
    • Androidのファイアウォール設定: 0.0.0.0 を指定した場合、Androidのシステム設定や他のファイアウォールアプリで、指定したポート（例: 9090）へのアクセスを許可する必要がある場合があります。

  • Clash Dashboardの導入と使い方:

    • Clash Dashboardは、Clash/Clash Metaの外部コントローラーAPIを通じて、Webブラウザ上で動作するGUIを提供するプロジェクトです。代表的なものに Clash Dashboard (Dreamacro公式ではない)、yacd (Yet Another Clash Dashboard) などがあります。
    • これらのダッシュボードは、通常、静的なHTML/CSS/JSファイルセットとして提供されるか、npmなどでインストールしてローカルで起動して使用します。
    • 使用手順 (例: yacd):
      1. PCのブラウザで、yacdのリポジトリページ（GitHubなど）にアクセスし、提供されているホストされたバージョン（例: https://yacd.haishoku.me/）を開くか、ソースコードをダウンロードしてローカルでホストします。
      2. ダッシュボードの接続設定画面で、CMAを起動しているAndroidデバイスのIPアドレスと、CMAの設定ファイルで指定した外部コントローラーのポート番号（例: 9090）、およびsecret（パスワード）を入力します。
      3. 「Connect」ボタンなどをクリックして接続します。
      4. 接続に成功すると、ダッシュボード上にCMAの状態（トラフィック、プロキシリスト、接続リスト、ログなど）が表示され、PCのブラウザからプロキシグループの切り替えなどの操作が行えるようになります。

  • 他のダッシュボード: yacd以外にも様々なClash/Clash Meta対応ダッシュボードが存在します。機能やUIが異なるため、好みに合わせて選ぶことができます。

外部コントローラーとダッシュボードの連携は、CMAをより快適に、そして詳細に管理するための強力な手段です。特に、設定変更や状態確認を頻繁に行う場合に便利です。ただし、external-controllerに0.0.0.0を指定する場合は、ローカルネットワーク内の他のデバイスからのアクセスが可能になるため、セキュリティには十分に注意してください。信頼できるネットワーク環境でのみ使用するか、アクセス元IPを制限する設定（もし可能であれば）を行うことを検討してください。

第9部：トラブルシューティングとパフォーマンス改善

Clash Meta for Androidは高機能な反面、設定が複雑なためトラブルが発生することもあります。ここでは、よくある問題とその解決策、およびパフォーマンスを改善するためのヒントを紹介します。

9.1 一般的な問題と解決策

  • VPN接続が開始できない、すぐに切断される:
    • 原因: VPN権限が許可されていない、設定ファイルに構文エラーがある、Clash Metaコアが起動できない、他のVPNアプリと競合しているなど。
    • 解決策:
      • CMAアプリにVPN接続の権限が許可されているか確認してください。
      • 設定ファイルのYAML構文にエラーがないか確認してください。CMAのLogsタブを確認すると、設定ファイルのパースエラーが表示されることが多いです。YAMLエディタで検証するのも有効です。
      • 他のVPNやネットワーク制御アプリが動作していないか確認し、停止させてください。
      • CMAを再起動したり、デバイスを再起動したりしてみてください。
      • CMAのバージョンを最新版にアップデートしてみてください。
      • 設定ファイルが破損している可能性があるため、再インポートしてみてください。
  • 一部のウェブサイトやサービスが開かない、正しく表示されない:
    • 原因: ルール設定が間違っている、使用しているプロキシサーバーがそのサービスに対応していない（ブロックされている、地域制限など）、DNS設定の問題、Sniffingの問題など。
    • 解決策:
      • CMAのConnectionsタブを確認し、その接続がどのルールにマッチし、どのプロキシグループ/アクションが適用されているかを確認してください。意図したルールが適用されているか？ 意図しない REJECT や DIRECT になっていないか？
      • 問題のドメイン/IPアドレスに対するルールを修正してください。例えば、DOMAIN-SUFFIX,example.com,DIRECT となっているべきが Proxy になっていたり、その逆だったりしないか。
      • そのサービスが特定の地域のIPアドレスを要求する場合、対応する地域のプロキシサーバーが選ばれているか確認してください。プロキシグループを手動で切り替えて試すのが有効です (select グループを使う)。
      • 使用しているプロキシサーバー自体に問題がないか、他のサービスでは接続できるか確認してください。
      • DNS設定を確認してください。特にfake-ipモードで問題が発生しやすいサービス（特定のゲームやアプリ）の場合、そのドメインをfake-ip-filterに追加してみてください。DNSサーバーが正しいIPアドレスを返しているか、DNSログを確認してください。
      • Sniffingが有効になっているか確認してください。特にredir-hostモードの場合、Sniffingが無効だとドメイン名が特定できず、ルールが正しく適用されないことがあります。
  • インターネット速度が遅い:
    • 原因: 使用しているプロキシサーバーの性能が低い、プロキシサーバーまでの経路が遅延している、設定ファイルのヘルスチェックURLや間隔が不適切、DNS解決が遅い、デバイスやネットワーク環境の問題など。
    • 解決策:
      • CMAのProxiesタブで、各プロキシサーバーの遅延テストを実行し、遅延の少ないサーバーを選択してください。
      • url-test グループを使用している場合、テスト対象のURLが適切か、interval が適切か確認してください。テスト間隔が長すぎると、サーバーの速度変動に対応できません。短すぎるとリソースを消費します。
      • 別のプロキシサーバーや、別のプロキシサービスプロバイダーを試してみてください。
      • DNS設定を確認してください。応答の速いDNSサーバーをnameserverリストの先頭に配置してください。暗号化DNS（DoH/DoT/DoQ）のオーバーヘッドが速度に影響する場合、暗号化されていないDNSサーバーを試す（ただしプライバシーリスクが増加）などの検証も有効かもしれません。
      • デバイスのネットワーク接続（Wi-Fi/モバイルデータ）自体に問題がないか確認してください。
      • CMAのLogsタブでエラーが出ていないか確認してください。

9.2 ログの確認方法とデバッグ

CMAのLogsタブは、トラブルシューティングの最も重要なツールです。

  • ログレベル: Settings -> Logs -> Log Level で詳細度を変更できます。問題発生時は info や debug に設定すると、より詳細な情報（ルールマッチング、DNSクエリ、接続試行など）が得られます。ただし、debugはログ量が非常に多くなります。
  • ログの内容:
    • [Config] 設定ファイルの読み込みに関するエラーや警告。
    • [DNS] DNSクエリとその応答、Fake IPの割り当て状況など。
    • [Rule] 接続がどのルールにマッチしたか。
    • [Proxy] プロキシサーバーへの接続試行、エラーなど。
    • [Connection] 新しい接続が確立されたこと、切断されたこと、適用されたポリシーなど。
  • ログの活用: 特定のウェブサイトやサービスにアクセスできない場合、そのドメイン名やIPアドレスでログを検索し、その通信がどのような処理を受けているか（どのルールにマッチしたか、どのプロキシが選ばれたか、エラーは発生しているかなど）を確認します。

9.3 設定ファイルのエラーチェック

YAML構文エラーは、CMAが設定ファイルを読み込めない最も一般的な原因の一つです。

  • CMAのLogsタブに「Error parsing config file」のようなエラーが表示されていないか確認してください。エラーメッセージには、問題が発生している行番号やエラーの種類が示されていることが多いです。
  • オンラインのYAMLバリデーター（例: https://jsonformatter.org/yaml-validator）などに設定ファイルの内容を貼り付けて、構文エラーがないかチェックしてみてください。
  • 手動で編集した場合は、特にインデントが正しいか、コロンやハイフンの打ち間違いがないかなどを注意深く確認してください。

9.4 Clash Metaのパフォーマンス設定

一部の高度な設定は、CMAのパフォーマンスに影響を与える可能性があります。

  • tcp-concurrent, udp-concurrent: 設定ファイル（またはSettingsタブ）で、TCP/UDPの同時接続数を設定できます。デフォルト値で問題ないことが多いですが、多くの同時接続を扱う場合は調整が必要かもしれません。
  • チューニング: Metaコアによっては、さらに詳細な低レベルのチューニングオプションが提供されている場合があります。これらはMetaコアのドキュメントを参照し、慎重に変更してください。

9.5 Androidのバッテリー最適化設定

前述しましたが、Androidのバッテリー最適化機能がCMAを強制終了させないように、CMAを最適化の対象から除外することが非常に重要です。

  • Androidの設定 -> アプリ -> CMA -> バッテリー -> バッテリー最適化 を探し、「最適化しない」を選択します。

第10部：Clash Meta for Androidのメンテナンスとセキュリティ

CMAを安全かつ快適に使い続けるためには、いくつかのメンテナンスとセキュリティに関する考慮事項があります。

10.1 定期的なアップデートの推奨

  • CMAおよびその基盤となるClash Metaコアは、活発に開発が進められています。定期的にGitHubのReleasesページを確認し、最新版にアップデートすることを推奨します。
  • アップデートにより、新しいプロトコルのサポート、パフォーマンス改善、バグ修正、そしてセキュリティ脆弱性の修正などが含まれる可能性があります。
  • ただし、プレリリース版は不安定な可能性があるため、安定性を重視する場合は公式リリース版を使用してください。

10.2 設定ファイルのバックアップと復元

  • 苦労して作成・カスタマイズした設定ファイルは、定期的にバックアップしておくことを強く推奨します。
  • CMAの「Profiles」タブから設定ファイルをローカルにエクスポートし、安全な場所に保存しておきましょう。
  • 万が一、設定が失われたり、アプリの再インストールが必要になった場合でも、バックアップから容易に復元できます。

10.3 GitHub Issueやコミュニティでの情報収集

  • CMAやClash Metaに関する不明な点や問題が発生した場合、開発元のGitHubリポジトリのIssuesセクションを確認したり、関連するコミュニティフォーラムやチャットグループで質問したり情報収集したりすることが有効です。
  • 他のユーザーが同じ問題に遭遇しているかもしれませんし、解決策が見つかる可能性があります。

10.4 セキュリティとプライバシーに関する注意点

Clash Meta for Androidは強力なツールですが、その設定と使用にはセキュリティとプライバシーに関する注意が必要です。

  • 信頼できるプロキシサービス/設定ファイルの選択:
    • インターネット上の無料プロキシや、出所不明の設定ファイルは、セキュリティリスク（通信傍受、マルウェア配布など）が高いです。必ず信頼できる有料プロキシサービスや、開発元が明確な設定ファイルを使用してください。
    • 特に、プロキシサーバーの運営元があなたの通信内容を記録・監視していないか確認することが重要です。
  • DNS設定の重要性:
    • DNSクエリは、あなたがアクセスしようとしているウェブサイトやサービスを露呈します。プライバシー保護のため、可能な限りDoH/DoT/DoQのような暗号化されたDNSプロトコルを使用し、信頼できるDNSサーバー（例: Cloudflare, Google, AdGuardなど）を設定してください。
    • fallback-filter の設定は、DNS毒や検閲を回避するために重要ですが、設定を誤ると意図しない情報漏洩につながる可能性もあります。
  • ログの取り扱い:
    • CMAのログには、アクセスしたドメイン名やIPアドレス、通信内容の一部（HTTPヘッダーなど、ログレベルによる）が含まれる可能性があります。これらのログが他のアプリからアクセスされたり、意図せず外部に送信されたりしないよう、デバイスのセキュリティには注意してください。
  • Root化の有無による機能差:
    • Root化されたAndroidデバイスでは、Root権限が必要な特定のネットワーク機能（例: 特定のUID/GIDのトラフィックを除外する、より低レベルなパケット操作など）を利用できる場合があります。しかし、Root化自体がセキュリティリスクを伴うため、必要がなければRoot化せずに利用するのが推奨されます。CMAの主要な機能はRoot化不要で利用可能です。
  • allow-lan 設定:
    • 設定ファイルでallow-lan: trueとすると、ローカルネットワーク上の他のデバイスからあなたのCMAを経由してインターネットにアクセスできるようになります。これは便利な機能ですが、悪意のある第三者に利用されないよう、信頼できるネットワーク環境以外では無効にしておくべきです。secret を設定して認証を必須にすることも重要です。

CMAはあなたのネットワークトラフィックを完全に制御するため、その設定は慎重に行う必要があります。提供元不明の設定ファイルや無料プロキシの使用は避け、常にセキュリティとプライバシーを意識した設定を心がけてください。

第11部：まとめ

この記事では、Clash Meta for Android (CMA) の基本的な概念から、入手・インストール、初期設定、そして設定ファイルの構造、プロキシグループ、ルール、DNS、Metaコア固有機能、外部コントローラー、トラブルシューティング、メンテナンス、セキュリティに至るまで、幅広くかつ詳細に解説してきました。

Clash Meta for Androidは、単なるVPNクライアントではなく、あなたのAndroidデバイスのネットワークトラフィックを自由自在に、そして非常にきめ細やかにコントロールするための強力なツールです。プロキシサーバーの種類や、接続先、アプリケーションなど、様々な条件に基づいて最適なルーティングを自動的に行うルールベースルーティングは、CMAの最大の強みであり、他の多くのプロキシアプリにはない柔軟性を提供します。

YAML形式の設定ファイルは最初は難しく感じるかもしれませんが、その構造と各パラメータの意味を理解すれば、あなたの特定のニーズに合わせてCMAの動作を完璧にカスタマイズすることが可能です。プロキシグループを組み合わせることで複雑な負荷分散やフェイルオーバー構成を構築し、ルール設定を駆使して特定のサービスへのアクセス方法を最適化し、DNS設定を調整してプライバシーとパフォーマンスを向上させることができます。Metaコアが提供する先進的な機能は、さらに高度なユースケースに対応します。

この記事が、あなたがClash Meta for Androidを理解し、その潜在能力を最大限に引き出すための一助となれば幸いです。最初は基本的な設定から始め、徐々に複雑なルールやグループ、高度な機能へと挑戦していくのが良いでしょう。Logsタブを頻繁に確認し、接続がどのように処理されているかを理解することは、設定のデバッグと学習に非常に役立ちます。

インターネット接続は、もはや単に「繋がる」だけでなく、「どのように繋がるか」が重要になっています。Clash Meta for Androidをマスターすることで、あなたは自身のデジタルライフにおけるネットワーク制御権を取り戻し、より安全で、より自由で、そしてより快適なインターネット体験を実現できるはずです。

さあ、この記事で得た知識を元に、あなたのAndroidデバイスでClash Meta for Androidを自由に使いこなしてください！

付録：参考情報

  • YAML構文チートシート (簡易版):
    • key: value : キーと値
    • key: \
      value1 \
      value2 : ネストされたキーと値（インデントが必須）
    • list_key: \
      - item1 \
      - item2 : リスト（-とスペースが必須）
    • # comment : コメント
    • インデントはスペースのみを使用し、一貫した数（通常2または4）を使用するのが推奨されます。
  • 一般的なルール例:
    • 広告ブロック: 多くの広告ドメインリストを提供するサブスクリプションURLをproxy-providersやrulesのRULE-SETなどで参照し、それらをREJECTするルールを設けるのが効果的です。
    • 特定のアプリを直連: PROCESS,com.example.app,DIRECT
    • 海外のストリーミングサービス: DOMAIN-SUFFIX,streaming-service.com,US_Proxy_Group
    • 日本国内サイトは直連: GEOIP,JP,DIRECT （GEOIPデータベースが必要です）
  • Clash Metaコア公式ドキュメント: 使用しているCMAのバージョンに同梱されているMetaコアのドキュメント（通常はアプリ内やGitHubリポジトリにリンクがあります）を参照すると、最新の機能、対応プロトコル、詳細な設定オプションについて最も正確な情報を得られます。
  • プロキシサービスプロバイダー: 多くのプロキシサービスプロバイダーは、Clash/Clash Meta対応のサブスクリプションURLを提供しています。サービス選択にあたっては、プロトコル対応、サーバーの質、価格、ログポリシーなどを比較検討してください。

この記事は、公開情報に基づいてClash Meta for Androidの一般的な使い方を解説したものです。アプリの仕様やMetaコアの機能はバージョンによって変更される可能性があります。常に最新の情報を参照し、自己責任において利用してください。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール