Android で VPN を有効にすると MMS が失敗する：まず通信事業者の経路
画像メッセージは事業者独自の経路とネットワーク機能を使うため、ブラウジングが動いても何の証明にもなりません。VPN に触れる前に SMS、MMS、RCS を切り分けてください。
Web ページは開き、通話も機能するのに、画像メッセージは対応できるエラーも出さずに送信中のまま止まっている。この組み合わせはインターネット障害ではない。MMS は事業者独自の設定と独自の配送経路を持つサービスであり、Android ではプラットフォームがブラウザの使った経路を再利用するのではなく、そのための特定のネットワークを要求できる。そこから三つの判断が導かれる——実際に失敗したのはどの種類のメッセージか、転送を所有しているのは誰か、そもそも VPN が関与しているのか。
実際に失敗したのはどの種類のメッセージか
SMS、事業者の MMS、RCS は一つの会話ウィンドウを共有する三つの異なるサービスである。スレッドの吹き出しはどれが使われたかを教えてくれず、一つを直しても他には触れない。実際には RCS メッセージである失敗した画像メッセージは APN 設定を変えても直らず、端末から一度も出ていない MMS は RCS を再登録しても直らない。
使える最も平易な言葉で障害を確定する——テキストのみの SMS は届くのか、小さな画像は送信時・受信時・その両方のどれで失敗するのか、その障害は VPN より前からあるのか。受信側の画像だけが失敗するという答えなら、あなたが見ているのはダウンロード経路であり、制限されたネットワークではアップロード経路とは違う振る舞いをする。
MMS は経路だけでなくネットワークを要求する
Android は MMS の操作をSmsManagerとプラットフォームの MMS サービスを通じて公開しており、特定のサブスクリプションに対して MMS 機能を持つセルラーネットワークを要求できる。既定の経路でアプリが HTTPS 接続を開くより狭い要求である。だからこそ通常の通信をすべて運ぶ VPN が機能する MMS 経路と共存でき、逆の組み合わせが障害として現れる。
この区別が重要になるのは、責任の所在が異なるからだ。プラットフォームの MMS 要求を満たせないなら、問題はサブスクリプションか事業者側にある。要求が成功しても VPN が有効な間だけ転送が止まるなら、アプリのネットワーク統合か VPN ポリシーの方が疑わしい。この二つの間で推測することが、この種の報告で最も時間を無駄にする。
| What you observe | Where to look first |
|---|---|
| No mobile data at all, SMS also fails | Subscription, carrier data service, SIM state |
| Browsing works, MMS fails only with the VPN on | The app's network integration or the VPN policy |
| MMS fine, RCS will not register | RCS registration, unrelated to the MMS transport |
| MMS fails on one SIM but not the other | Which subscription owns mobile data, and which sent the message |
事業者の設定には手を触れない
事業者が意図した APN、MMS サーバーのアドレス、プロキシ設定はそのままにしておく。VPN がブラウジングの挙動を変えることは、見慣れない APN や公開 DNS サーバーを貼り付ける理由にはならない——MMS はブラウザが好むリゾルバーを使わず、間違った APN は機能していた唯一の経路を壊す。
デュアル SIM の端末では、二つの別々のことを確認する——現在モバイルデータを持つのはどのサブスクリプションか、メッセージはどのサブスクリプションから送られたか。たまたまデータを持つ SIM で試しているのに、失敗しているスレッドがもう一方に結び付いていることはよくある。古いサードパーティ製メッセージアプリは、システム統合経路とは違う振る舞いをする独自または旧式のネットワーク経路を使うこともあるので、古いバージョンで覚えたメニュー名より、保守されているアプリの文書化されたモードを優先する。
比較を狭くする
検証する一つの変数以外はすべて固定する——同じアプリ、同じ相手、同じサブスクリプション、小さな機密性のないテスト画像一枚。送信・受信・その両方のどれが失敗するのか、正確なエラー文言は何か、VPN が有効だと結果が変わるのかを記録する。
個人の端末でポリシーが許すなら、VPN なしの短い比較が依存関係を切り分ける。これは診断であり、保護なしで動かすことの推奨ではない——管理端末やロックダウン端末では、サポートされる手順はフォーラムの投稿ではなく管理者から来る。一度再現できる障害を再現するためだけに、私的なメディアを何度も送るのは避ける。
サポートに何を渡すか、何を仮定しないか
VPN が有効な場合だけ失敗するなら、有用な報告にはクライアント名とバージョン、メッセージアプリのバージョン、ネットワーク種別、使用中のサブスクリプション、障害の正確な現地時刻が含まれる。この五つの事実があれば、推測する代わりに事業者とクライアントのログに障害を突き合わせられる。
メッセージアプリを除外すれば治る、と仮定してはいけない。システムのテレフォニーコンポーネントが操作の一部を所有していることがあり、VPN なしのブロックポリシーは単純な除外とは違う振る舞いをするので、除外されているように見えてもアプリは失敗し続けることがある。除外を仮説として検証し、結果を残し、証拠が支持しないなら元に戻す。