Comment savoir si le réseau mobile bloque le protocole VPN plutôt que le serveur ? Changez une variable, pas cinq serveurs

Mon VPN fonctionnait parfaitement sur le Wi-Fi.

Je suis passé en 5G.

Plus rien.

L’application restait bloquée sur « connexion », puis abandonnait.

Ma première conclusion était évidente: le serveur était mort.

J’en ai choisi un autre.

Même résultat.

Puis un troisième.

Puis un quatrième dans un autre pays.

Toujours rien.

J’étais déjà en train de chercher une cinquième destination lorsque j’ai fait un test beaucoup plus utile: j’ai réactivé le Wi-Fi et sélectionné exactement le premier serveur.

Connexion immédiate.

C’est là que j’ai arrêté de demander:

« Quel serveur fonctionne? »

La vraie question devenait:

« Qu’est-ce que le réseau mobile refuse que le Wi-Fi accepte? »

Et pour le savoir, changer encore de serveur était précisément la mauvaise chose à faire.

Quatre serveurs qui échouent de la même façon sont déjà un indice

Un serveur VPN peut évidemment tomber en panne.

Mais si plusieurs destinations échouent uniquement sur la connexion mobile, alors que le même téléphone et le même serveur fonctionnent dès que je reviens au Wi-Fi, le serveur devient une explication beaucoup moins convaincante.

C’est aussi la logique du dépannage classique: OpenVPN recommande notamment de comparer avec une autre connexion et de vérifier si certains ports ou types de trafic sont filtrés.

J’avais donc isolé une variable importante.

Même téléphone.

Même application.

Même serveur.

Seul le réseau changeait.

Wi-Fi: connexion.

5G: échec.

Des utilisateurs de WireGuard décrivent le même type de symptôme sur réseau cellulaire. Mais ce détail ne faisait que confirmer mon intuition: il fallait désormais tester le transport, pas continuer à parcourir la carte.

Le test utile consistait à garder la 5G et changer de protocole

Mon fournisseur principal utilisait WireGuard dans le mode que j’avais laissé activé.

Cette fois, je n’ai pas choisi un sixième serveur.

J’ai gardé:

le même téléphone;

la même 5G;

le même emplacement;

le même fournisseur.

Puis j’ai changé uniquement le protocole.

Je suis passé à OpenVPN sur TCP.

Connexion.

Cette fois, elle s’est établie.

J’ai ouvert une page.

Puis ma messagerie.

Puis un fichier dans le cloud.

Tout passait.

Ce résultat valait beaucoup plus que mes quatre changements de serveur.

OpenVPN prévoit justement TCP 443 comme solution de repli utile lorsque certains réseaux laissent mal passer d’autres transports ou ports.

À partir de là, mon diagnostic était suffisamment clair pour agir:

si plusieurs serveurs échouent avec un transport mais fonctionnent dès que je change de transport sur le même réseau mobile, le problème n’est probablement pas la destination choisie.

Le levier utile est ailleurs.

J’ai aussi arrêté de dire trop vite « l’opérateur bloque WireGuard »

C’était ma deuxième erreur.

Le symptôme ne révèle pas forcément la règle exacte appliquée par le réseau.

WireGuard utilise UDP et n’intègre pas lui-même une couche d’obfuscation destinée à masquer la nature du tunnel. Le réseau peut donc réagir au port, au transport UDP, à une signature identifiable ou à une combinaison de ces éléments.

Je ne peux pas observer la règle interne appliquée par l’opérateur mobile.

Mais, pour résoudre le problème, je n’ai pas besoin de connaître son nom exact.

Si changer de serveur ne change rien et changer de transport rétablit immédiatement la connexion, je sais déjà quelle variable mérite mon attention.

C’est là que la comparaison entre VPNs a commencé à devenir intéressante.

Mon gros VPN pouvait fonctionner — à condition que je sache quoi changer

Mon fournisseur habituel avait une vraie qualité: plusieurs protocoles étaient disponibles.

Une fois le problème compris, je pouvais passer manuellement sur une option plus compatible avec cette 5G.

Et cela fonctionnait.

Le problème était ce qui se passait avant que je comprenne.

L’interface rendait extrêmement facile de changer de pays, de ville ou de serveur.

Donc c’est ce que je faisais.

Paris.

Amsterdam.

Francfort.

Encore Paris.

Mais si le réseau mobile traitait mal le même type de tunnel vers toutes ces destinations, la taille de la liste ne résolvait rien.

Je pouvais changer de serveur toute la soirée sans toucher à la variable qui échouait réellement.

C’est précisément à ce moment-là que j’ai testé une approche différente.

Avec OnlydogVPN^↗, je suis resté sur la 5G qui posait problème

J’ai installé OnlydogVPN sur le même téléphone.

Je n’ai pas réactivé le Wi-Fi.

Je voulais conserver la connexion qui venait de mettre les autres essais en échec.

Même téléphone.

Même pièce.

Même 5G.

Au lieu de choisir encore un autre pays, j’ai utilisé le profil destiné aux réseaux plus difficiles.

Connexion.

Le tunnel s’est établi.

J’ai ouvert les mêmes services qu’avant.

La messagerie s’est synchronisée.

Le fichier est parti.

J’ai lancé un appel.

Il a tenu.

Cette fois, la différence ne venait pas d’un serveur supplémentaire.

Elle venait de la manière dont le trafic traversait le réseau.

L’application utilise un transport basé sur HTTP/3 et ajoute de l’obfuscation pour rendre le trafic VPN moins évident sur des réseaux qui traitent mal les tunnels conventionnels.

C’était exactement le type de réponse que mon problème demandait.

L’obfuscation comptait plus que la taille de la carte

J’avais commencé en pensant:

« Ce serveur est bloqué. »

Puis:

« Peut-être que tous les serveurs de ce pays sont mauvais. »

Après les tests, la question était devenue beaucoup plus précise:

« Est-ce que cette 5G laisse passer ce type de trafic VPN? »

Et cette formulation change tout.

Un fournisseur peut avoir des centaines de serveurs.

Si je les atteins tous avec le même transport que le réseau mobile refuse ou identifie facilement, cent nouvelles destinations ne m’aident pas beaucoup.

Une seule route qui passe avec un transport mieux adapté devient plus utile que toute cette variété.

C’est ce qui m’a fait préférer la seconde approche dans ce scénario.

Pas parce qu’elle proposait davantage d’endroits.

Parce qu’elle agissait sur le problème que mes premiers tests avaient isolé.

Depuis, mon diagnostic tient en deux comparaisons

Quand un VPN fonctionne en Wi-Fi mais pas en données mobiles, je ne commence plus par changer de pays.

Je garde le serveur qui vient d’échouer.

Je repasse en Wi-Fi.

S’il fonctionne immédiatement, le serveur lui-même n’est plus mon premier suspect.

Ensuite, je retourne sur le réseau mobile et je change le protocole ou le mode de transport.

Si la connexion revient, je sais que chercher un autre serveur me ferait surtout perdre du temps.

Cette méthode évite une erreur très simple:

modifier trois variables à la fois, puis essayer de deviner laquelle a réellement corrigé le problème.

Serveur identique.

Réseau différent.

Puis réseau identique.

Transport différent.

En quelques minutes, on apprend beaucoup plus qu’en testant dix pays au hasard.

La petite application a une limite claire

Le compromis existe.

Un grand fournisseur propose généralement davantage de pays, davantage de serveurs et beaucoup plus d’historique public.

Si un serveur précis est réellement en panne ou surchargé, cette profondeur de réseau est très utile.

L’application plus petite offre moins de localisations et moins de recul indépendant.

Mais ce jour-là, je n’avais pas besoin d’un cinquième serveur.

J’en avais déjà essayé plusieurs.

Tous butaient sur la même 5G avec le même type de tunnel.

Ajouter une destination ne changeait pas le problème.

Changer la manière de traverser le réseau, oui.

Maintenant, le sixième serveur est mon dernier test

Si demain mon VPN fonctionne en Wi-Fi mais refuse de se connecter sur le réseau mobile, je regarderai d’abord le motif.

Un seul serveur échoue alors que les autres fonctionnent sur la même 5G?

Je regarde le serveur ou sa route.

Plusieurs serveurs échouent sur la 5G mais fonctionnent sur Wi-Fi?

Je regarde le réseau.

Les mêmes services redeviennent accessibles dès que je change de protocole ou utilise un transport obfusqué?

Je cesse de changer de destination.

Mon grand fournisseur me donnait suffisamment de serveurs pour chercher longtemps.

La seconde application m’a poussé vers la variable qui comptait réellement.

C’est désormais ainsi que je distingue les deux problèmes: si changer de serveur ne change rien mais changer la manière dont le VPN traverse le réseau rétablit la connexion, je ne cherche plus un meilleur serveur — je cherche un meilleur chemin pour l’atteindre.