Shadowrocket ブログ · 仕組み

なぜ Shadowrocket は
「特定アプリだけプロキシ」できないのか。

デスクトップのように「このアプリはプロキシ、他は直通」と指定したい人は多いです。iOS ではほぼ実現できません。原因は Shadowrocket ではなく、iOS のネットワーク基盤です。制限の所在と、実際に使っている代替手段を説明します。

iOS の VPN は Apple の枠組みを通る

iOS は、デスクトップのように第三者がネットワーク下層を直接握り、トラフィックを自由に傍受・改変することを許しません。転送が必要なアプリ(Shadowrocket を含む)は、Apple 公式の Network Extension を通す必要があり、転送の中核が NEPacketTunnelProvider です。初回に「VPN 構成」の許可が出るのは、この公式経路の必須ステップであり、Shadowrocket 独自の仕組みではありません。

動作モードは2つ。混ぜられない

Apple 公式ドキュメントによると、NEPacketTunnelProvider が使えるルーティングは次の2モードだけで、排他です。

モード動作制限
宛先 IP でルーティング
destinationIP
アクセス先のアドレスでトンネルに入れるかを決める。Shadowrocket のグローバルプロキシとルール分流はこちらこのモードではシステムは「どのアプリからのリクエストか」を教えません。ドメインか IP で判断するしかなく、発信元アプリは見えません
発信元アプリでルーティング
sourceApplication
トラフィックの発信元アプリで、トンネルへ転送するかを決めるこの「Per-App VPN」では、あるアプリのトラフィックがトンネルに入ったら全部処理する必要があり、一部だけプロキシ・一部は直通にはできません。通常は MDM(企業デバイス管理)が必要で、一般ユーザーが自分で入れたアプリでは使えません

つまり Apple の設計には「アプリで分けたうえで、同じアプリの一部だけさらに分流する」モードはありません。どのプロキシが未実装という話ではなく、システム API が開いていません。開発者フォーラムの公式回答でも「Per-App VPN では、あるアプリの一部トラフィックだけを処理する仕組みは無い」と明記されています。

Shadowrocket が実際に使う代替手段

システムから「このリクエストはどのアプリか」が取れない以上、Shadowrocket は 宛先ドメイン / IP で判定 します。ルールファイルの DOMAIN-SUFFIXIP-CIDRGEOIP などは、「そのアプリがよく繋ぐドメインやサーバー」でアプリ単位分流に近づける近似であり、発信元アプリを識別しているわけではありません。

実際の利用で見かける次の現象も、これで説明できます。

ではルール分流に意味は無い?

いいえ。よくある「日本のサイトは DIRECT、地域制限のある先は PROXY」なら、ドメインと IP で十分分かれます。iOS ができないのは、同じアプリの通信の一部だけ PROXY、残りは DIRECT、という分割です。

注:技術詳細は Apple 公式デベロッパドキュメント(Network Extension / Packet Tunnel Provider)と開発者フォーラムの公式回答に基づきます。API の挙動は最新の公式ドキュメントを優先してください。

仕組みが分かると、設定は速くなる 制限の所在が分かれば、ルールの書き方と、いつグローバルプロキシを使うかも判断しやすい
ダウンロードへ →

関連記事:ルール構文の解説 · サイトが開けないときの手順