なぜ「全体プロキシ」だけでは足りないか

Android で Clash 系クライアントを有効にすると、ブラウザや一部アプリは期待どおり海外ノードへ流れます。一方で、決済・チャット・地図・動画の国内 CDN まで遠回りし、遅延やログイン失敗が起きることがあります。原因はルールの誤りだけではなく、トラフィックをそもそもプロキシ側に載せているかというレイヤーの問題です。PC では「システムプロキシ」「TUN」「プロセス単位」の切り分けが語られがちですが、モバイルではアプリ単位のアクセス制御が実務上の主役になります。

本稿の対象は、Clash / mihomo 系の Android クライアントで、選んだアプリだけをトンネルに載せ、それ以外は VPN を素通りさせない（直結に近い経路に戻す）構成を目指す読者です。メニュー名はフォークごとに「アクセス制御」「アプリフィルタ」「分アプリ」などと表記が揺れますが、考え方は共通です。

アプリ別プロキシと「バイパス一覧」は何が違うか

多くの実装では、次の二つのモードのどちらか（または同等の意味合い）を選びます。

• 指定アプリのみプロキシ（ホワイトリスト）：チェックしたアプリの通信だけを Clash の仮想インターフェース側へ送る。それ以外はトンネル外＝基本的に直結。
• 指定アプリをバイパス（ブラックリスト）：チェックしたアプリだけをトンネルから外し、残りはすべてプロキシ側へ。国内アプリを数個だけ外したいときに向く。

どちらを選ぶかは用途次第です。「海外のブラウザと特定の SNS だけ」ならホワイトリストが管理しやすく、「ほぼ全部プロキシだが銀行と決済だけ直結」ならバイパスが直感的です。いずれの場合も、リストに入れたアプリのパッケージ単位で効く点は同じです。システムアプリやマルチプロセスのアプリでは、見え方が分かりにくいことがあるため、一度「仮に全部許可」から絞り込むより、テスト用に IP 表示アプリを一つ入れて挙動を確認すると早いです。

前提：プロファイル、VPN 権限、動作モード

アプリ別制御を使うには、多くの場合VPN（またはそれに相当するトラフィック捕捉）権限が必要です。これは「悪意ある監視」のためではなく、Android がトラフィックを仮想インターフェースへ振り分けるために要求されるものです。初回起動で許可ダイアログを拒否したままだと、リストを設定しても効かないので、OS の設定アプリから該当クライアントの権限を確認してください。

また、TUN モードとシステムプロキシのみのような切り替えがあるビルドでは、アプリ別リストがどのモードと組み合わさるかをリリースノートやドキュメントで確認します。古い端末・カスタム ROM では省電力制限でバックグラウンドが落ち、リストが一瞬だけ無効化されることもあるため、バッテリー最適化の例外に入れるかは端末ごとに検討が必要です。

設定の流れ（一般的な手順）

フォークにより文言は異なりますが、次の順で進めると迷いにくいです。

1. 有効なプロファイルを読み込む：サブスクリプションまたはローカル YAML をインポートし、少なくともプロキシとルールがエラーなく読めている状態にする。
2. メインスイッチをオン：コアが起動し、接続ログが流れることを確認する。
3. アクセス制御／アプリの項目を開く：「すべてのアプリ」「バイパス」「指定のみ」などのモード選択がある場合、目的に合わせてモードを先に決める。
4. アプリを選択：ブラウザ、対象の SNS、開発用ターミナルなど、ノード経由にしたいものだけにチェックする（ホワイトリストの場合）。バイパスモードなら直結させたい国内アプリにチェックする。
5. 反映と再起動：一部の実装では設定保存後にトンネルを一度切る必要がある。「適用」ボタンやトグル OFF/ON で状態を揃える。

ここまでで「どのアプリがトンネルに乗るか」は決まります。残るのは、トンネルに乗ったあとどのノード・どのルールに流すかという話であり、これは従来どおり proxy-groups と rules の設計領域です。デスクトップの Clash Verge 系の操作感とは UI が異なる点に注意してください（クロスプラットフォームの導入全般は別稿のデスクトップ手順を参照）。

効いているか確認する（グローバル影響を避けるチェック）

設定ミスが起きやすいのは、「リストは合っているのに、実は別プロファイルが有効」「省電力でプロセスが再起動しリストが初期化」といった系統です。確認は次のように段階的に行うとよいです。

• IP 確認用アプリ：トンネルに載せた場合だけ出口 IP が変わるかを見る。載せていないアプリでは国内 IP のままになるのが期待どおり。
• ブラウザとネイティブアプリを分けて試す：ブラウザだけ載せたつもりが、WebView を使う別アプリが載っていないケースに気づきやすい。
• ログ画面：接続ログに対象ドメインが現れるか。現れないならトンネル外か、DNS が別経路の可能性を疑う。

国内サービスを直結させたいのにまだ遅い場合は、アプリ別設定以前にそのアプリが独自 DNS（DoH）やプライベート DNS を使っていないかも見ます。OS 全体の「プライベート DNS」が有効だと、見かけ上の挙動が変わることがあります。

よくあるつまずき

リストを変えても体感が変わらない：モード（ホワイト／バイパス）を逆に解釈している、別ユーザープロファイルが有効、バッテリー最適化でサービスが落ちている、などを疑います。

国内アプリだけ異常に遅い：バイパスに入れ忘れ、あるいはルール側で広い MATCH が海外プロキシに流している可能性があります。アプリ境界とルールの両方を見ます。

ゲームや VoIP が不安定：遅延志向ならプロキシ自体をオフにする時間帯を分けるほうが現実的なこともあります。アプリ別制御は万能ではなく、UDP や端末の省電力と相性が悪いケースがあります。

まとめ

Clash for Android 系では、PC の YAML だけをいじっても解決しない不具合の多くが、アプリ境界でのトラフィック捕捉に起因します。アプリ別プロキシ（ホワイトリスト）とバイパス（ブラックリスト）のどちらで目的を達成するかを先に決め、VPN 権限と動作モードを揃えたうえで、IP 確認とログで効き目を検証するのが最短です。ルール設計の深掘みはデスクトップ向け記事やドキュメントと役割分担すると学習コストを抑えられます。

クライアントの入手と端末向けビルドの選択は、ダウンロードページから行うと、コアと UI の対応関係を追いやすいです。オープンソースのリポジトリは挙動確認に役立ちますが、実行ファイルの主な入手経路として配布ページを使うと更新履歴の見落としが減ります。→ 無料で Clash をダウンロードし、アプリ別プロキシの検証を始める