MMS en échec sur Android avec le VPN actif : d’abord le chemin de l’opérateur
Les messages avec image passent par un chemin propre à l’opérateur et par une capacité réseau propre, donc une navigation qui fonctionne ne prouve rien. Distinguez SMS, MMS et RCS avant de toucher au VPN.
Les pages web se chargent, les appels passent, et un message avec image reste sur « envoi » sans erreur exploitable. Cette combinaison n’est pas une panne d’internet. MMS est un service de l’opérateur avec sa propre configuration et son propre chemin de livraison, et sur Android la plateforme peut demander un réseau précis pour lui plutôt que de réutiliser la route qu’a prise votre navigateur. Trois décisions en découlent : quel type de message a réellement échoué, à qui appartient le transport, et si le VPN est impliqué tout court.
Quel type de message a réellement échoué
SMS, MMS de l’opérateur et RCS sont trois services différents qui partagent une seule fenêtre de conversation. La bulle du fil ne vous dit pas lequel a été utilisé, et la réparation de l’un ne touche pas les autres. Un message avec image en échec qui est en réalité un message RCS ne se réparera pas en changeant les réglages d’APN, et un MMS qui n’a jamais quitté le téléphone ne se réparera pas en réenregistrant RCS.
Établissez la panne avec les mots les plus simples disponibles : un SMS texte arrive-t-il, une petite image échoue-t-elle à l’envoi, à la réception ou les deux, et la panne précède-t-elle le VPN. Si la réponse est que seules les images entrantes échouent, vous regardez un chemin de téléchargement, qui se comporte différemment d’un chemin d’envoi sur un réseau contraint.
MMS demande un réseau, pas seulement une route
Android expose les opérations MMS via SmsManager et le service MMS de la plateforme, qui peut demander un réseau cellulaire doté de la capacité MMS pour un abonnement donné. C’est une demande plus étroite que celle d’une application ouvrant une connexion HTTPS par la route par défaut. C’est aussi pourquoi un VPN qui transporte tout le trafic ordinaire peut coexister avec un chemin MMS fonctionnel, et pourquoi la combinaison inverse apparaît comme une panne.
La distinction compte parce qu’elle désigne des responsables différents. Si la demande MMS de la plateforme ne peut pas être satisfaite, le problème est du côté de l’abonnement ou de l’opérateur. Si elle réussit mais que le transfert se bloque uniquement lorsque le VPN est actif, l’intégration réseau de l’application ou la politique du VPN est le meilleur suspect. Deviner entre ces deux options est ce qui fait perdre le plus de temps dans ce type de rapport.
| 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 |
Laissez la configuration de l’opérateur tranquille
Conservez l’APN prévu par l’opérateur, l’adresse du serveur MMS et les réglages de proxy tels quels. Qu’un VPN modifie votre comportement de navigation n’est pas une raison pour coller un APN inconnu ou un serveur DNS public ; MMS n’utilise pas le résolveur que votre navigateur préfère, et un APN erroné casse le seul chemin qui fonctionnait.
Sur un téléphone double SIM, vérifiez deux choses séparées : quel abonnement possède actuellement les données mobiles, et depuis quel abonnement le message a été envoyé. Il est courant de tester sur la SIM qui a des données par hasard alors que le fil en échec est lié à l’autre. Une application de messagerie tierce plus ancienne peut aussi utiliser un chemin réseau personnalisé ou hérité qui se comporte différemment du chemin intégré au système, donc préférez le mode documenté de l’application maintenue aux libellés de menu dont vous vous souvenez d’une ancienne version.
Rendez la comparaison étroite
Gardez tout constant sauf la variable que vous testez : même application, même destinataire, même abonnement, une petite image de test non sensible. Notez si l’envoi, la réception ou les deux échouent, quel est le texte exact de l’erreur, et si le résultat change avec le VPN actif.
Si la politique le permet sur un appareil personnel, une comparaison courte sans le VPN isole la dépendance. C’est un diagnostic, pas une recommandation de travailler sans protection, et sur un appareil géré ou verrouillé le flux de travail pris en charge vient de l’administrateur et non d’un message de forum. Évitez d’envoyer des médias privés à plusieurs reprises juste pour reproduire une panne que vous pouvez reproduire une fois.
Ce qu’il faut remettre au support, et ce qu’il ne faut pas supposer
Si seul le cas avec VPN actif échoue, le rapport utile contient le nom et la version du client, la version de l’application de messagerie, le type de réseau, l’abonnement utilisé et l’heure locale exacte de la panne. Avec ces cinq faits, quelqu’un peut aligner la panne sur les journaux de l’opérateur et du client au lieu de deviner.
Ne supposez pas qu’exclure l’application de messagerie soit le remède. Les composants de téléphonie du système peuvent posséder une partie de l’opération, et une politique de blocage sans VPN se comporte différemment d’une simple exclusion, donc l’application peut continuer d’échouer tout en paraissant exemptée. Testez l’exclusion comme une hypothèse, gardez le résultat, et revenez dessus si les preuves ne la soutiennent pas.