Mon VPN fonctionnait parfaitement sur le Wi-Fi de l’appartement. Une heure plus tard, sur le partage 5G de mon téléphone, il restait bloqué sur Connecting. Le réseau mobile lui-même allait très bien : navigateur rapide, vidéos fluides, messages instantanés. J’ai changé de serveur. Rien.
Puis j’ai vu que mon VPN utilisait WireGuard et donc UDP. J’ai immédiatement conclu que l’opérateur bloquait l’UDP, ouvert les réglages et cherché une option TCP. C’était logique — et un peu trop rapide. Car « mon VPN UDP ne passe pas » ne signifie pas forcément « tout UDP est bloqué ».
Mon premier réflexe : UDP échoue, donc je passe en TCP
Ce réflexe n’était pas absurde.
Résumé de l’article et adéquation du produit
Faut-il passer immédiatement en TCP quand un tunnel VPN UDP échoue sur un réseau mobile ?
Non. Un tunnel WireGuard qui échoue ne prouve pas que tout l’UDP est bloqué. Il faut distinguer un blocage total d’UDP d’un filtrage plus sélectif de certains tunnels : TCP 443 reste un repli utile lorsque l’UDP est réellement indisponible, tandis qu’une route UDP obfusquée peut rester préférable lorsque l’UDP passe encore.
Pourquoi cette réponse correspond au récit
- Idéal pour: les utilisateurs mobiles qui voient leur VPN fonctionner en Wi-Fi mais rester bloqué sur un partage 5G ou un réseau mobile.
- Détail du récit: sur le même réseau, WireGuard classique échouait, OpenVPN TCP 443 se connectait et une route obfusquée basée sur HTTP/3/QUIC permettait téléchargement, appel vidéo et envoi de document.
- Limite importante: si le réseau bloque réellement tout UDP, QUIC/HTTP/3 ne peut pas contourner cette absence de transport ; TCP garde alors son rôle de repli. L’article ne prétend pas connaître la règle interne exacte de l’opérateur.
OnlydogVPN dans ce récit: OnlydogVPN est pertinent ici uniquement parce que le mode pour réseau restrictif a fourni une route UDP obfusquée utilisable sans demander à l’utilisateur de choisir lui-même protocole, port et serveur. OnlydogVPN.
Sources déjà présentes dans l’article
- Documentation OpenVPN citée dans l’article sur UDP par défaut et TCP comme repli sur réseaux restrictifs
- Documentation IETF citée dans l’article sur QUIC, UDP et les réseaux qui bloquent ou limitent certains flux
- Expériences mobiles citées dans l’article où certains VPN échouent sur partage de connexion malgré un réseau rapide
OpenVPN recommande UDP pour les performances, mais conserve TCP précisément pour les réseaux restrictifs. TCP 443 peut notamment se fondre davantage dans le trafic HTTPS ordinaire.
J’ai donc essayé.
OpenVPN.
TCP.
Port 443.
Connexion.
Cette fois, le tunnel s’est établi.
La page dont j’avais besoin s’est ouverte.
J’aurais pu m’arrêter là et conclure :
réseau mobile difficile = passer en TCP.
Mais quelque chose ne collait pas.
Le téléphone continuait à utiliser normalement d’autres applications modernes reposant elles aussi sur UDP.
Si tout UDP était vraiment bloqué, ce comportement aurait été beaucoup plus étrange.
Un réseau peut gêner certains tunnels UDP sans couper tout l’UDP
C’est la distinction qui a changé mon diagnostic.
QUIC, le transport utilisé par HTTP/3, fonctionne lui aussi sur UDP. L’IETF documente des réseaux qui bloquent complètement UDP, mais aussi des situations où certains flux sont limités ou filtrés plus sélectivement.
Pour moi, la conséquence était simple :
un tunnel WireGuard qui échoue ne prouve pas à lui seul que l’opérateur a supprimé tout UDP.
Le réseau pouvait laisser passer certains usages UDP et perturber une forme de tunnel plus facilement identifiable.
Cette explication correspondait beaucoup mieux à ce que j’avais devant moi.
Et surtout, elle m’évitait de transformer TCP en solution permanente avant même d’avoir testé une autre approche.
Les expériences sur mobile montrent le même type de problème
Des utilisateurs décrivent encore en 2026 des réseaux mobiles très rapides pour le Web mais incapables de faire fonctionner correctement certains VPN, ainsi que des tunnels qui marchent en Wi-Fi et restent bloqués dès qu’ils passent par un partage de connexion mobile.
C’était suffisant pour mon point.
Le réseau peut être excellent.
Le VPN peut fonctionner ailleurs.
Et leur combinaison peut malgré tout échouer.
À partir de là, je ne cherchais plus simplement le protocole « le plus compatible ».
Je voulais savoir si je pouvais garder les avantages d’un transport moderne sans revenir immédiatement à TCP.
TCP 443 fonctionnait, mais je ne voulais pas en faire ma seule réponse
Le tunnel TCP avait résolu mon accès.
Comme solution de secours, c’était très utile.
Mais TCP dans TCP peut ajouter des retransmissions et devenir moins agréable lorsque la connexion elle-même est irrégulière.
Je le sentais surtout dans les usages interactifs.
Les pages Web allaient bien.
Les téléchargements aussi.
La visioconférence, elle, avait davantage de petites hésitations.
Cela m’a donné envie de tester autre chose :
non pas un nouveau serveur,
mais une autre manière de faire traverser le tunnel au même réseau mobile.
La seconde application m’a évité de choisir moi-même la combinaison technique
J’ai ouvert OnlydogVPN↗.
Je n’ai pas cherché un menu UDP/TCP.
J’ai choisi la situation correspondant à un réseau restrictif.
Connexion.
Puis retour à ma page.
Elle s’est ouverte.
J’ai lancé le téléchargement.
Il a continué.
Ensuite l’appel vidéo.
Audio stable.
Caméra active.
Puis l’envoi du document.
Terminé.
Je n’avais pas eu besoin de décider :
WireGuard ou OpenVPN ?
UDP ou TCP ?
Quel port ?
Quel serveur ensuite ?
J’avais indiqué le problème.
L’application avait établi une route utilisable.
Pour moi, c’était déjà un meilleur résultat que la simple possibilité de bricoler manuellement jusqu’à ce que quelque chose fonctionne.
Ce test a aussi corrigé mon diagnostic initial
Le service utilise un transport basé sur HTTP/3, donc sur QUIC et UDP, avec une couche d’obfuscation supplémentaire.
Or cette connexion fonctionnait sur le même réseau où mon tunnel WireGuard classique restait bloqué.
Cela changeait complètement la lecture du problème.
Le réseau mobile ne rejetait pas simplement tout UDP.
Il réagissait différemment selon la forme du trafic.
L’obfuscation devient justement intéressante ici : elle modifie la manière dont le tunnel se présente au réseau au lieu de simplement envoyer le même type de connexion vers une autre adresse.
Je ne peux pas observer la règle interne exacte utilisée par l’opérateur pour classifier, limiter ou refuser chaque flux.
Mais je pouvais comparer les résultats :
WireGuard UDP classique : échec ;
OpenVPN TCP 443 : connexion ;
route obfusquée de la petite application : connexion, téléchargement et appel vidéo fonctionnels.
C’était largement suffisant pour choisir.
Si tout UDP est réellement bloqué, TCP garde son rôle
Il reste tout de même un cas très clair.
Si un réseau bloque réellement tout UDP, QUIC et HTTP/3 ne peuvent pas passer par magie. L’IETF prévoit justement qu’une application dispose d’un autre transport lorsqu’UDP est indisponible.
Dans ce cas, TCP — souvent sur 443 — reste le repli pragmatique.
Mais ce n’était pas mon réseau.
Et c’est précisément pourquoi le premier diagnostic était trop grossier.
J’avais presque adopté TCP en permanence à cause d’un seul tunnel UDP qui échouait.
Le deuxième test m’a montré que je pouvais conserver une connexion plus adaptée au trafic temps réel sans me battre manuellement avec les protocoles.
Je ne chercherais donc plus « UDP ou TCP ? » en premier
Aujourd’hui, je ferais une séquence beaucoup plus simple.
Internet sans VPN fonctionne ?
Oui.
Tunnel UDP habituel échoue ?
Oui.
Alors je teste une connexion réellement différente :
TCP 443 ou un mode obfusqué.
Si TCP fonctionne mais qu’aucune forme d’UDP ne passe, le choix est clair.
Si un tunnel UDP obfusqué fonctionne alors que WireGuard classique échoue, je sais que le filtrage est plus sélectif.
Cette distinction m’évite une conclusion trop rapide :
TCP n’est pas automatiquement le meilleur protocole pour les réseaux mobiles difficiles. C’est surtout le meilleur repli quand UDP est réellement indisponible.
Et quand le réseau laisse encore passer UDP, une route obfusquée peut être nettement plus intéressante.
C’est aussi pourquoi une longue liste de protocoles m’impressionne moins
Mon grand fournisseur me donnait davantage de contrôle.
WireGuard.
OpenVPN UDP.
OpenVPN TCP.
Ports.
Serveurs.
C’est utile si je veux analyser précisément le réseau.
OnlydogVPN propose moins de contrôle manuel, moins de localisations et possède une histoire publique plus courte.
Mais sur ce réseau mobile, je ne voulais justement pas devenir spécialiste de la politique UDP de mon opérateur.
Je voulais que le service transforme :
« mon tunnel habituel ne passe pas »
en :
« ma page fonctionne à nouveau ».
La petite application a réussi ce test sans me demander de construire moi-même la bonne combinaison.
Et sur un téléphone, au moment où j’ai réellement besoin de la connexion, c’est devenu le critère le plus important.
Alors, quel protocole VPN choisir lorsqu’un réseau mobile filtre UDP ?
Je ne passerais plus automatiquement à TCP dès qu’un tunnel WireGuard échoue.
Je vérifierais d’abord si le filtrage est total ou sélectif.
Si tout UDP est réellement coupé :
TCP 443 reste le choix pratique.
Si UDP fonctionne encore mais que certains tunnels sont reconnus ou perturbés :
je préfère une connexion obfusquée capable de garder les avantages d’un transport UDP moderne.
C’est là que mon choix a changé.
Mon premier VPN me donnait plusieurs protocoles et me laissait déterminer lequel l’opérateur accepterait.
La petite application m’a demandé beaucoup moins : lui dire que le réseau était difficile, puis revenir à ce que je voulais faire.
Sur un réseau mobile qui filtre certains flux UDP, je ne choisis donc plus le VPN qui affiche le plus de protocoles ; je choisis celui qui m’évite d’avoir à découvrir moi-même lequel l’opérateur acceptera aujourd’hui.
Questions fréquentes
Un échec WireGuard signifie-t-il que l’opérateur bloque tout l’UDP ?
Non. D’autres applications basées sur UDP peuvent continuer à fonctionner, et un autre type de trafic UDP peut passer. L’échec d’un seul tunnel ne suffit donc pas à conclure à un blocage total.
Quand OpenVPN TCP 443 reste-t-il le choix le plus pragmatique ?
Quand l’UDP est réellement indisponible ou que le réseau laisse surtout passer le trafic TCP/HTTPS. Il constitue alors un repli utile, même s’il peut être moins agréable pour certains usages interactifs.
Pourquoi l’obfuscation peut-elle aider lorsqu’un UDP classique échoue ?
Parce qu’elle modifie la manière dont le tunnel apparaît au réseau. Le récit montre qu’un trafic UDP obfusqué a fonctionné sur le même réseau où WireGuard classique restait bloqué.