Le ticket est classique : « le site marche au bureau, pas en 4G ». Vous inspectez les logs applicatifs — rien. Le certificat TLS est valide. Le TTFB est correct depuis votre monitoring. Puis un test depuis un téléphone révèle une page qui charge l'en-tête, freeze sur une image lourde ou un bundle JavaScript, et finit par timeout sans message utile.
Ce n'est pas toujours un bug front. C'est parfois un paquet trop gros pour un tunnel, et un pare-feu qui avale les ICMP nécessaires au redimensionnement automatique.
MTU, fragmentation et PMTUD en deux minutes
Le MTU (Maximum Transmission Unit) est la taille maximale d'un paquet IP sur un lien — souvent 1500 octets en Ethernet, moins sur VPN ou mobile.
Le PMTUD (Path MTU Discovery) permet aux hôtes de découvrir la taille utilisable en recevant des ICMP « Fragmentation Needed ». Si un pare-feu bloque ces ICMP, la connexion entre dans un blackhole : les petits paquets passent, les gros restent bloqués.
| Contexte | MTU typique | Risque |
|---|---|---|
| Ethernet datacenter | 1500 | Faible |
| PPPoE / DSL | 1492 | Moyen |
| WireGuard / OpenVPN | 1420–1450 | Élevé si non clampé |
| GRE / IPsec site-à-site | Variable | Élevé |
Un site « rapide » en labo peut échouer en production mobile parce que le chemin réseau, pas le code, limite la taille des paquets.
Symptômes qui doivent faire penser MTU
Chargement partiel (HTML oui, assets non). SSH ou HTTPS OK pour de petites requêtes, freeze sur transferts volumineux. Problème uniquement via VPN d'entreprise ou depuis certains FAI. API REST légère OK, upload ou download qui pend.
Corrélez avec où ça casse : client, VPN, CDN, load balancer, serveur.
Diagnostic pas à pas
Ping avec Don't Fragment
ping -M do -s 1472 votre-serveur.tld
Réduisez -s jusqu'à ce que ça repasse. La taille utile plus 28 octets (en-têtes IP/ICMP) ≈ MTU du chemin.
Utilisez mtr ou tracepath avec grandes tailles pour repérer le saut qui drop. Côté serveur, vérifiez ip link show sur les interfaces tunnel — un MTU explicite trop haut est suspect. CDN et WAF : certains tunnels entre edge et origin ont leur propre MTU ; un origin derrière VPN site-à-site est un cas fréquent.
Correctifs durables
MSS clamping sur le routeur ou le serveur VPN. MTU explicite sur l'interface tunnel (WireGuard : MTU = 1420 dans la config). Autoriser ICMP type 3 code 4 (fragmentation needed) sur les pare-feu — souvent oublié « pour la sécurité ». tcp_mtu_probing sur Linux en dernier recours.
Ne baissez pas aveuglément le MTU de toute l'interface publique sans mesurer — ciblez le tunnel ou le lien fautif.
Le sommet : votre monitoring ne verra pas le blackhole
Décider et avancer sans angle mort
Reproduisez depuis le réseau signalé (4G, VPN client, FAI concerné) avant de toucher au code applicatif. Testez ping DF et mtr pour localiser le saut fautif. Documentez le MTU de chaque tunnel entre vous et l'hébergeur. Choisissez un hébergeur avec support réseau réactif via notre comparateur si le problème persiste côté origin.
Questions fréquentes
Qu'est-ce qu'un problème de MTU en pratique ?
Paquets trop grands plus ICMP filtrés : connexion figée sans erreur claire côté navigateur. Les petites requêtes passent, les transferts volumineux échouent silencieusement.
Pourquoi le problème apparaît-il seulement sur certains réseaux ?
VPN, tunnels et opérateurs mobiles réduisent le MTU effectif. Sans PMTUD fonctionnel, les gros paquets ne passent pas sur ce chemin spécifique.
Comment confirmer un blackhole MTU ?
ping -M do avec tailles décroissantes, mtr, tracepath — jusqu'à identifier le saut qui drop les paquets oversized.
Que régler côté serveur ou hébergeur ?
MSS clamp, MTU explicite sur tunnel, autoriser ICMP fragmentation needed, tcp_mtu_probing en dernier recours.
Quand une page « échoue sans raison », demandez : les gros paquets passent-ils sur ce chemin ? — pas seulement si le serveur répond.