VPN connecté mais certains sites ne chargent pas : j’ai testé le MTU avant de changer de serveur — et c’était le test qui manquait

Au début, j’ai pris le fait que Google fonctionnait comme une bonne nouvelle.

Le VPN était connecté. Wikipédia s’ouvrait. Ma messagerie synchronisait. Un test de débit donnait un résultat tout à fait normal.

Puis j’ai ouvert le portail client dont j’avais réellement besoin.
Le haut de la page est apparu.
Le menu aussi.

Et le contenu est resté sur son cercle de chargement.

J’ai essayé un second site, sans rapport avec le premier. Même comportement : quelques éléments arrivaient, puis plus rien. Une petite page statique fonctionnait. Une page plus lourde se figeait.

Sans VPN, tout s’ouvrait immédiatement.
Mon premier réflexe a été de regarder la liste des serveurs.
Paris 1.

Paris 2.
Belgique.
Pays-Bas.

J’étais déjà en train de transformer le problème en loterie géographique lorsque quelque chose m’a gêné : si l’adresse IP de mon serveur était simplement refusée par le portail client, pourquoi un deuxième site totalement différent se bloquait-il presque de la même façon ?

J’ai laissé le serveur tranquille.

C’est le genre de panne qu’une icône verte cache très bien

Les VPN sont devenus beaucoup plus visibles auprès d’utilisateurs français qui n’avaient aucune envie d’apprendre ce qu’étaient un MSS, un PMTU ou un paquet ICMP.

Lorsque plusieurs grands sites pour adultes ont suspendu leur accès en France le 4 juin 2025, l’observatoire de Proton a enregistré une hausse de plus de 400 % de la demande VPN par rapport à son niveau habituel, avec un pic horaire d’inscriptions supérieur à 1 000 %.

Le sujet est resté très actuel : le 16 juin 2026, la justice européenne a confirmé que la France pouvait imposer ses exigences de vérification d’âge à certains sites établis dans d’autres États membres.

Ce contexte n’était pas la cause de mon portail bloqué. Il explique surtout pourquoi davantage de gens utilisent désormais un VPN sans avoir la moindre raison de connaître les détails du réseau qui se cache derrière le bouton « Connecté ».

Et c’est précisément ce qui rend cette panne trompeuse : le tunnel est là, une partie d’Internet fonctionne, mais quelques pages donnent l’impression d’être cassées.

Dans ce cas, changer immédiatement de serveur peut faire disparaître le symptôme sans apprendre grand-chose sur sa cause.

Le MTU est devenu intéressant précisément parce que tout n’était pas cassé

Quelques mois plus tôt, j’aurais associé un problème de MTU à une connexion totalement morte.

C’était faux.

Le MTU désigne simplement la taille maximale d’un paquet capable de passer sur un chemin réseau sans être découpé ou rejeté.

J’ai fini par me le représenter comme une valise : ma connexion normale acceptait une certaine taille, puis le VPN ajoutait son propre emballage autour. La valise qui passait juste avant pouvait soudain devenir quelques centimètres trop grosse pour le tunnel.

En principe, les machines découvrent qu’elles doivent envoyer plus petit.
Parfois, ce message se perd.

L’IETF décrit depuis longtemps ces « black holes » de Path MTU : le paquet trop gros disparaît, mais l’information qui devrait prévenir l’expéditeur ne revient pas correctement. La connexion ne tombe donc pas forcément avec une erreur claire. Elle peut simplement attendre indéfiniment.

Cloudflare a encore travaillé sur ce problème dans son client en mars 2026. Son équipe décrit le même genre de panne déroutante : DNS et les petits échanges fonctionnent, puis un transfert plus important, SSH ou un appel vidéo se bloque lorsque le chemin ne supporte pas la taille utilisée par le tunnel.

Là, mon écran commençait enfin à avoir du sens.

« Mauvais serveur français » expliquait mal pourquoi plusieurs petits échanges passaient alors que certaines pages s’arrêtaient en plein milieu.

Un paquet devenu trop gros l’expliquait beaucoup mieux.

J’ai changé une seule valeur au lieu de changer de pays

Le VPN que j’utilisais permettait de régler manuellement le MTU.
Je n’ai pas cherché sur Internet un nombre présenté comme magique.
J’ai gardé :

le même ordinateur,
le même Wi-Fi,
le même navigateur,

le même protocole,
le même serveur.
Puis j’ai temporairement réduit le MTU du tunnel.

J’ai rouvert le portail.
Le tableau qui tournait dans le vide depuis plusieurs minutes est apparu.
J’ai rechargé le second site.

Lui aussi.
J’ai remis l’ancienne valeur.
Le blocage est revenu.

À ce stade, changer de serveur aurait été une expérience beaucoup moins utile. Si Paris 2 avait fonctionné, j’aurais probablement conclu : « Paris 1 est mauvais, Paris 2 est bon. »

Sauf qu’en changeant de serveur, j’aurais également changé le chemin emprunté par les paquets — et donc potentiellement la taille que ce chemin acceptait.

Le serveur aurait eu l’air d’être la solution alors qu’il n’aurait peut-être été qu’un détour autour du problème.

Ce symptôme n’a rien de théorique. Dans une discussion publique sur WireGuard, un utilisateur décrivait des pages qui commençaient à charger avant de rester bloquées, ainsi que des connexions SSH qui expiraient ; réduire le MTU à 1280 a rétabli le fonctionnement dans son cas.

C’était presque exactement la partie qui m’avait trompé : presque tout marchait.

Mais je n’avais pas envie de régler manuellement le tunnel à chaque réseau

Le diagnostic avait répondu à ma première question.
Il en avait créé une autre.
La valeur qui fonctionnait ici devait-elle devenir mon réglage permanent ?

Pas vraiment.

Le MTU dépend du chemin emprunté. Celui-ci peut changer avec le fournisseur d’accès, le réseau intermédiaire, le tunnel ou la destination.

Je pouvais choisir une valeur volontairement basse et éviter davantage de chemins trop étroits, mais cela revenait un peu à envoyer tous mes colis dans de petites boîtes parce qu’un seul couloir avait une porte étroite. Ça fonctionne, mais ce n’est pas forcément ce que j’avais envie de régler moi-même à chaque fois.

Je venais de prouver qu’un ajustement de taille réparait mon problème.

Je venais aussi de découvrir que je n’avais aucune envie de devenir responsable de cet ajustement.

C’est là que j’ai essayé le deuxième service.

Cette fois, je n’ai touché ni au serveur ni au MTU

J’avais installé la petite application auparavant sans vraiment l’utiliser. Elle avait moins de recul public et moins de régions disponibles qu’un grand fournisseur.

Pour quelqu’un qui doit absolument sélectionner une ville précise parmi des dizaines de destinations, le grand service conserve un avantage évident.

Mais mon problème du jour n’était plus géographique.

J’ai ouvert l’application, choisi le mode correspondant à une connexion problématique et laissé les réglages réseau tels quels. Cette approche par situation, plutôt que par réglage manuel de chaque paramètre, fait partie du fonctionnement présenté par le service.

Connexion.
Retour au portail client.
Le menu est apparu.

Puis le tableau.
Les lignes se sont remplies.

J’ai ouvert la fiche que je devais vérifier, téléchargé le PDF joint et renvoyé le document corrigé.

Ensuite, j’ai repris le deuxième site qui s’était figé auparavant.
Il s’est chargé jusqu’en bas.
C’était le résultat que je cherchais depuis le début.

Pas une autre IP affichée dans un onglet.
Pas un serveur marqué « faible charge ».

Les deux pages qui avaient déclenché mon dépannage étaient utilisables, et je n’avais pas eu à choisir moi-même une valeur de MTU pour y arriver.

Après les essais de la demi-heure précédente, cette absence de réglage ressemblait soudain beaucoup moins à un détail.

HTTP/3 m’a intéressé seulement après que les pages avaient chargé

La petite application utilise un transport basé sur HTTP/3.

HTTP/3 repose sur QUIC, dont la spécification prévoit justement des mécanismes permettant de découvrir la taille des datagrammes qu’un chemin accepte et d’éviter de dépendre de la fragmentation IP pour les faire passer.

Autrement dit, le protocole possède déjà des outils pour comprendre la largeur de la porte au lieu de continuer à y pousser la même grosse valise.

Ce n’est pas une formule magique contre chaque panne de MTU. Le réseau réel comporte trop d’autres variables pour réduire chaque page bloquée à un seul mécanisme.

Mais ici, la comparaison était difficile à ignorer.

Avec le premier tunnel, ces deux pages ne terminaient leur chargement qu’après mon ajustement manuel du MTU.

Avec le second, elles sont passées sans que je touche à cette valeur.

Je n’avais plus besoin de transformer le diagnostic que je venais d’apprendre en nouvelle tâche permanente.

Après avoir passé vingt minutes à isoler une taille de paquet, cette différence avait beaucoup plus de valeur pour moi qu’un serveur supplémentaire dans une autre ville.

Quand je testerais le MTU avant de toucher au serveur

Je ne commencerais toujours pas par le MTU devant n’importe quel échec.

Si une plateforme affiche clairement « proxy ou VPN détecté », renvoie un refus d’accès ou multiplie les CAPTCHA sur une adresse particulière, le serveur et la réputation de son IP restent des suspects beaucoup plus naturels.

Et si absolument plus rien ne passe sous VPN, je regarderais d’abord le tunnel lui-même, le DNS, le protocole ou le portail captif.

Mon problème avait une signature différente :
le VPN était établi ;
plusieurs services fonctionnaient ;

des sites sans rapport entre eux se bloquaient ;
certaines pages commençaient même à charger ;
désactiver le VPN les réparait immédiatement.

Dans cette situation, réduire temporairement le MTU sans changer le serveur m’a donné une information que la roulette Paris–Belgique–Pays-Bas ne pouvait pas me donner.

Si le changement n’avait rien produit, j’aurais remis la valeur d’origine et testé autre chose.

Mais il a produit quelque chose immédiatement.

Et à partir de là, ma comparaison entre les deux VPN n’avait plus grand-chose à voir avec le nombre de pays affichés dans leur interface.

Le grand fournisseur m’offrait davantage de destinations, davantage de réglages et beaucoup plus de recul indépendant. Une fois le MTU ajusté, il pouvait faire fonctionner les pages qui me posaient problème.

La petite application avait moins de choix géographiques et une histoire publique plus courte.

Mais elle m’a ramené beaucoup plus vite à ce que j’essayais réellement de faire : ouvrir le portail, récupérer le document et le renvoyer, sans transformer la taille de mes paquets en réglage quotidien.

Avant cet incident, j’aurais changé de serveur jusqu’à tomber sur celui qui fonctionnait.

Maintenant, quand le VPN reste vert, que Google fonctionne et que seules certaines pages meurent à mi-chemin, je préfère d’abord vérifier si le problème tient simplement à une valise devenue trop grosse pour le tunnel.