なぜ「アプリ別プロキシ」が必要になるのか
スマートフォンで Clash for Android や Mihomo ベースの同等クライアントを動かすと、多くの場合は「VPN セッションに載った通信が、設定どおりにルール分流される」挙動になります。一方で実際のニーズは、ブラウザ・チャット・メールなど少数のアプリだけを出口の多い経路に載せ、決済・地図・国内向け動画などは遅延と容量を抑えた直結のまま使いたい、というパターンが少なくありません。
Android の VPN フレームワークは、アプリ単位(正確には UID)でトンネルへの参加可否を切り替えられる余地があります。クライアントによって Per-App Proxy、アプリ別プロキシ、バイパス、アプリフィルタ など表記は揺れますが、考え方は共通で、「どのアプリのパケットを Clash の TUN/VPN 側に流すか」を絞り込む機能です。デスクトップの「システム全体プロキシ+ルール」より、モバイル向けのスコープ管理に向いています。
始める前の確認事項
- 購読またはローカル設定が取り込まれ、ノード疎通が確認できていること。手順の全体像は 購読インポートの解説 も参照してください。
- 初回接続時に表示される VPN 権限 を許可済みであること。拒否したままだとトンネルが張れません。
- ビルドごとにメニュー位置や文言が異なります。以下は代表的な階層の目安なので、実際の端末の表示を優先してください。
設定画面のたどり方(再現しやすい順序)
多くの Clash for Android 系アプリでは、次のような階層にアプリ別の項目があります。名称は英語のままの場合もあるので、キーワードで探すと早いです。
- ドロワーや下部タブから 設定(Settings) を開く。
- ネットワーク(Network)、VPN、または ルーティング/分流 に近いグループを展開する。
- Per-App Proxy、アプリ別プロキシ、アプリのバイパス などのスイッチと一覧に進む。
一覧を開いたら、まず モードの意味 を確認してください。「チェックしたアプリだけプロキシ」と「チェックしたアプリをバイパス(直結)」は正反対です。ここを誤読すると、「選んでも効かない」「選んでいないのに全部トンネル」といった混乱の原因になります。全選択ボタンがある場合は、いったんクリアしてから1〜2 アプリだけで試すと切り分けが速いです。
有効化のおすすめ手順
- まずはアプリ別モードをオフにした状態で、通常の VPN 接続が安定するか確認する。ここで失敗していると、権限やノードの問題をアプリリストのせいにしがちです。
- アプリ別画面でスイッチをオンにし、「対象のみ」か「バイパス」かを読み取ってからチェックを入れる。
- 最初はブラウザ 1 本など最小集合で保存し、VPN を一度切って再接続。対象アプリだけ期待どおり出口が変わるか確かめる。
- 国内アプリでログイン不可・読み込み停止が出たら、そのパッケージをバイパス側へ移すか、プロキシ対象から外して再接続する。
リスト変更の直後は、古いセッションが UID 集合を抱えたままのことがあります。切断→再接続 を一度挟むと反映が確実になります。また、省電力アプリの「自動終了」でプロセスが落ちると鍵アイコンが消えるので、端末メーカー固有の「バックグラウンド許可」「アプリの固定」も合わせて見てください。
仕事用プロファイル・デュアルアプリ・クローン
仕事用プロファイルやアプリの二重化機能は、しばしば別 UID として扱われます。個人用プロファイル側のリストにブラウザをチェックしても、実際に使っているのが仕事用側ならトンネルに乗りません。対象のユーザ空間ごとに設定するか、テスト用にメイン空間へ移すと原因切り分けが早くなります。
バイパスリストに入れておきたいアプリの例
運用上、次のようなアプリは「プロキシ側に載せない」選択が無難なことが多いです。
- 銀行・決済・公共系:VPN 検知で利用停止になる例があります。
- SMS・電話・キャリア系ユーティリティ:端末や ROM によっては通信経路に敏感です。
- 国内向けに十分な CDN 経路がある動画・音楽:無理にトンネルへ載せると遅延と転送量の両方を増やす場合があります。
新しいアプリを入れるたびに、「Clash をオンにしたときだけ不調」が出たら、まずリストから外すかバイパスへ回すのが実用的です。
アプリ別設定と「ルールモード」の関係
アプリ別プロキシは どのプロセスをトンネルに入れるか を決め、YAML の rules: は トンネルに入ったあとどのポリシーへ送るか を決めます。トンネル外のアプリは、DOMAIN や GEOIP のルール自体に到達しません。トンネル内の通信だけが、いつもどおりプロキシグループとルールセットの対象になります。
「トンネルに載せたアプリはとにかく海外ノードへ」といった整理は、ルール側の MATCH やポリシーグループ設計で行います。考え方の骨格は ルール分流の解説 と同じで、モバイルでは入口の絞り込みがアプリ次元になっている、と捉えると混乱しにくいです。
よくあるつまずきと対処
- 選んだアプリがプロキシを通らない:モードの反転(対象のみ/バイパス)を再確認。再接続後もダメなら、WebView や別プロセスに通信を逃がすアプリでは UID が分かれる場合があります。クライアントのログに接続が出るかで「トンネル外」か「ルール誤り」かを分けます。
- すぐ切断される:設定アプリの バッテリー で Clash を「制限なし」相当にし、メーカー独自の電池最適化・自動起動も許可します。過剰な省電力プリセットはバックグラウンド VPN を止めがちです。
- 画面オフで途切れる:「常時接続 VPN(Always-on)」は他 VPN と排他になり得るため、信頼できるクライアントかつポリシーが許す場合のみ検討し、そうでなければバックグラウンド固定とスリープ除外の組み合わせを優先します。
- プライベート DNS や別 VPN と競合:Android は同時に一つのフル VPN にしかなれません。常時オン型の別製品をオフにしてから試してください。
ドメイン単位の細かい分流まで含めた全体像は 全プラットフォーム向けのドキュメント で補完すると理解が早いです。開発者向けに IDE だけ別経路へ回す例は Cursor 向けの分流記事 でも触れています。
まとめ
Clash for Android のアプリ別プロキシは、システムが許す範囲で「トンネルに載せる集合」を最小化し、その上で Clash のルールとノード選択に任せるための入口です。いきなり大量チェックせず、少数アプリで成功パターンを作ってから広げるのが最もトラブルが少ない進め方です。
クライアントの入手とプラットフォーム別パッケージは ダウンロードページ から選べます。ルールの柔らかさとコミュニティ実績のバランスは、他ツールと比較しても導入しやすいスタックになっています。