VPN connecté mais upload presque nul : le test MTU qui m’a évité de changer de protocole pour la mauvaise raison

Le VPN était bien connecté. Les pages s’ouvraient, ma messagerie se synchronisait et le débit descendant dépassait encore 200 Mb/s. J’ai donc lancé l’envoi d’une archive de plusieurs gigaoctets vers le cloud en pensant que le plus dur était fait. Le compteur est parti, a ralenti, puis s’est mis à osciller autour de quelques centaines de kilobits par seconde. Sans VPN, le même fichier montait normalement.

Avec le tunnel, presque plus rien. J’ai changé de serveur, puis commencé à regarder les protocoles. Ce n’est qu’après avoir réduit temporairement la taille des paquets que l’upload est reparti. À ce moment-là, j’ai compris que l’icône verte du VPN répondait seulement à la question « le tunnel existe-t-il ? », pas à celle qui m’intéressait : « les gros paquets arrivent-ils réellement à traverser le chemin ? »

Tout fonctionnait assez bien pour me faire chercher au mauvais endroit

C’est ce qui rend ce problème particulièrement agaçant.

Quand un VPN refuse complètement de se connecter, on sait au moins où commencer.

Là, le tunnel était établi.

Je pouvais ouvrir un site.

Recevoir un message.

Télécharger un petit fichier.

Même le ping n’avait rien de catastrophique.

C’était lorsque j’essayais d’envoyer beaucoup de données que tout s’effondrait.

Mon premier réflexe a été le même que d’habitude :

changer de serveur.

Le premier n’a rien changé.

Le deuxième non plus.

J’ai alors commencé à soupçonner le protocole. WireGuard utilisait UDP ; peut-être que ce réseau le traitait mal. J’étais déjà prêt à basculer sur autre chose.

Mais quelque chose ne collait pas.

Si le protocole était simplement inutilisable, pourquoi les petites requêtes continuaient-elles à passer ?

Le tunnel n’était pas mort.

Il semblait surtout se heurter à une limite dès que les paquets devenaient suffisamment gros.

C’était un indice beaucoup plus précis.

Et, contrairement à un changement de protocole complet, je pouvais le tester en modifiant une seule chose.

Le MTU paraît abstrait jusqu’au jour où un fichier reste à 2 %

Le MTU désigne, en simplifiant, la taille maximale d’un paquet que l’on peut faire passer sur un lien sans devoir le fragmenter.

Un VPN ajoute ses propres en-têtes autour du trafic.

Le paquet qui tenait parfaitement sur le réseau avant l’activation du VPN devient donc un peu plus gros une fois placé dans le tunnel.

Et le chemin ne dépend pas seulement de mon ordinateur.

Il peut traverser une box, un opérateur, du PPPoE, de l’IPv6, un réseau mobile, plusieurs équipements intermédiaires, puis l’infrastructure du VPN.

La taille réellement utilisable dépend du passage le plus étroit.

L’IETF appelle cela le Path MTU. Les mécanismes PMTUD et DPLPMTUD servent justement à découvrir quelle taille de paquet peut traverser le chemin. Lorsque cette découverte se passe mal, les petits paquets peuvent continuer à circuler alors que les plus gros disparaissent.

L’image qui m’a débarrassé du jargon était celle d’un colis.

La porte est ouverte.

Le livreur peut entrer.

Les petites boîtes passent.

Puis arrive un carton de deux centimètres trop large.

Il ne ralentit pas forcément.

Il reste coincé.

Mon VPN ressemblait exactement à ça.

J’ai baissé le MTU pour tester une hypothèse, pas pour trouver un nombre magique

J’ai donc conservé :

le même réseau,

le même serveur VPN,

le même protocole.

Et j’ai réduit temporairement le MTU du tunnel.

Je suis descendu vers une valeur plus conservatrice et j’ai relancé le fichier.

Cette fois, il est parti.

Pas à quelques centaines de kilobits.

À plusieurs dizaines de mégabits.

J’ai arrêté l’envoi, remis le réglage précédent, puis recommencé.

Le débit s’est de nouveau effondré.

À partir de là, le serveur VPN avait beaucoup moins de raisons d’être accusé.

J’avais changé une seule propriété du tunnel et l’upload avait changé avec elle.

Une discussion publique de mars 2026 sur r/WireGuard décrit justement cette catégorie de panne : tunnel établi, mais trafic presque inutilisable sur certains chemins, avec le MTU qui finit par devenir le point décisif.

Je n’en ai pas retenu qu’il fallait recopier une valeur précise trouvée dans un forum.

J’en ai retenu quelque chose de beaucoup plus utile :

si une réduction raisonnable du MTU fait immédiatement revenir l’upload sans changer ni serveur ni protocole, la taille des paquets vient de vous donner un indice beaucoup plus fort que le simple statut “Connecté”.

Et cela expliquait enfin pourquoi le Web continuait à sembler presque normal.

Pourquoi l’upload peut s’effondrer alors que les pages s’ouvrent encore

Je pensais qu’un mauvais MTU devait casser Internet de manière spectaculaire.

Pas forcément.

Une page Web commence par beaucoup de petits échanges.

DNS.

Connexions.

Accusés de réception.

Petites requêtes.

Une partie de tout cela peut continuer à circuler suffisamment bien pour donner l’impression que la connexion fonctionne.

Un gros transfert, lui, envoie des paquets de données de façon beaucoup plus continue. Si une certaine taille provoque des pertes, le problème devient soudain visible.

L’IETF recommande d’éviter les datagrammes UDP trop grands pour le MTU du chemin, car la fragmentation rend le trafic plus fragile. Les tunnels compliquent encore les choses lorsque les messages chargés de signaler qu’un paquet est trop gros ne reviennent pas correctement jusqu’à l’émetteur.

Voilà pourquoi l’icône verte du VPN ne me rassurait plus autant.

La poignée de main pouvait être terminée pendant que mon fichier, lui, continuait à se cogner contre une porte invisible.

Une fois ce point compris, le protocole redevenait utile — mais comme test suivant, pas comme premier réflexe.

Le protocole restait utile, mais comme deuxième test

J’ai donc essayé un autre protocole.

Pas pour chercher immédiatement « le plus rapide ».

Pour voir si le symptôme changeait.

WireGuard transporte son trafic sur UDP. Changer de technologie de tunnel peut modifier l’encapsulation, la taille finale des paquets, les ports utilisés et la manière dont le réseau intermédiaire traite le trafic.

Si l’ajustement du MTU ne change rien, cette comparaison devient très parlante.

En février 2026, un utilisateur racontait qu’après un changement de fournisseur d’accès, WireGuard était devenu extrêmement lent alors qu’OpenVPN TCP retrouvait un débit beaucoup plus normal, avec en contrepartie davantage de latence.

Le VPN n’avait pas simplement cessé de fonctionner.

Le nouveau réseau réagissait différemment aux deux transports.

C’est exactement la nuance qui m’aurait évité de mauvais diagnostics auparavant.

Changer de protocole peut régler le problème.

Mais si je le fais avant de comprendre le symptôme, je ne sais pas vraiment ce que je viens de réparer.

Dans mon cas, le MTU avait déjà parlé.

Et si baisser le MTU ne change rien ?

C’est là que je regarderais la route.

Pas forcément avec une soirée entière de commandes réseau.

Je commencerais par une comparaison beaucoup plus simple.

Même ordinateur.

Même VPN.

Même serveur.

Autre accès Internet.

Par exemple un partage de connexion mobile pendant quelques minutes.

Si l’upload passe de presque zéro à normal sans autre changement, le serveur VPN ne s’est évidemment pas amélioré entre les deux tests.

C’est le chemin jusqu’à lui qui vient de changer.

Les problèmes de MTU sont eux-mêmes liés au chemin : la taille maximale utilisable peut varier selon les réseaux traversés. QUIC prévoit d’ailleurs explicitement que la taille utilisable des datagrammes dépend de ce chemin et peut évoluer lorsque le trajet change.

Une discussion publique de juillet 2026 autour d’un routeur de voyage connecté à une eSIM en itinérance montrait le même type de friction : upload faible, audio Teams instable et interrogations autour du MTU de WireGuard.

À partir de là, je ne déclarerais plus qu’un serveur ou un protocole est mauvais simplement parce qu’un seul réseau lui donne un résultat catastrophique.

Je chercherais d’abord où le comportement change.

Mon réglage MTU avait réparé le fichier, mais pas vraiment mon expérience

Le fichier était enfin parti.

J’aurais pu m’arrêter là.

Sauf que j’avais maintenant une nouvelle chose à retenir.

Sur ce réseau :

tel MTU.

Sur mon réseau habituel :

peut-être un autre.

Et si je changeais de Wi-Fi ?

Si je passais sur un hotspot ?

Si le chemin de l’opérateur changeait ?

J’avais résolu un problème concret, mais en devenant un peu plus administrateur réseau que je ne voulais l’être.

C’est à ce moment-là que OnlydogVPN est entré dans le test.

J’ai remis les réglages réseau que j’avais modifiés pour le diagnostic, coupé l’ancien tunnel et lancé la connexion rapide de la petite application.

Puis j’ai repris le même envoi.

Le fichier est reparti.

10 %.

28 %.

51 %.

Le débit n’était pas parfaitement plat — ce n’est jamais vraiment le cas sur un réseau réel — mais il restait suffisamment élevé pour que l’envoi continue sans retomber dans le quasi-zéro.

100 %.

Et surtout, je n’étais plus dans un menu à hésiter entre 1280, 1360 ou 1420.

C’était exactement ce que j’attendais d’un VPN à ce moment-là.

Pas un meilleur exercice de diagnostic.

Un fichier qui arrive.

Le choix technique allait dans le même sens que ce que j’observais

Le service utilise un transport basé sur HTTP/3, donc sur QUIC.

Et QUIC a été conçu en tenant compte de la taille réelle des datagrammes sur le chemin. Sa spécification prévoit une taille minimale de 1200 octets et des mécanismes permettant de découvrir des tailles plus importantes lorsque le réseau les supporte.

La conséquence pratique était beaucoup plus intéressante que le détail du protocole.

Le transport n’était pas construit autour de l’idée que je devais connaître à l’avance une valeur parfaite de MTU et la conserver partout.

Il était conçu pour mieux composer avec le chemin rencontré.

Pour un problème qui venait précisément de changer selon le réseau, c’était beaucoup plus proche de ce que je voulais.

Et, dans ce test, le résultat était visible sans terminal :

mon ancien tunnel m’avait obligé à diagnostiquer pourquoi le carton restait coincé à la porte.

Le second avait simplement terminé la livraison.

C’est là que j’ai changé l’ordre de mes vérifications

Avant, lorsqu’un VPN restait connecté mais devenait extrêmement lent, je procédais presque au hasard.

Serveur.

Autre serveur.

WireGuard.

OpenVPN.

Redémarrage.

MTU trouvé dans un forum.

Retour au serveur.

À la fin, j’avais souvent une configuration différente sans savoir laquelle des six modifications avait réellement compté.

Aujourd’hui, si les pages continuent à fonctionner mais que l’upload tombe presque à zéro, je regarde d’abord si la taille des paquets change le symptôme.

Si une baisse raisonnable du MTU fait revenir immédiatement l’envoi, j’ai un indice très fort.

Si elle ne change rien mais qu’un autre protocole fonctionne sur le même réseau, je regarde la manière dont ce réseau traite les différents transports.

Et si le même VPN retrouve son débit dès que je passe sur une autre connexion, je cesse d’accuser le serveur et je regarde le chemin.

La petite application a une limite claire dans cette histoire : elle offre moins de régions, moins de recul public et moins de possibilités de réglage manuel qu’un grand fournisseur.

Si mon objectif était précisément d’expérimenter avec les MTU, les ports et les protocoles, je choisirais volontiers un outil plus ouvert.

Mais ce soir-là, mon objectif n’était pas d’étudier le tunnel.

C’était d’envoyer un fichier.

Je pensais qu’un VPN connecté avec un upload presque nul me demandait de choisir entre MTU, protocole et route.

J’ai fini par comprendre que la meilleure solution était d’abord celle qui cessait de me transformer en technicien réseau au moment précis où j’avais simplement besoin que l’upload reparte.