MTU WireGuard : la bonne valeur et comment réparer le tunnel bloqué (2026)

Transparence affiliation — Cet article contient des liens affiliés Contabo. Si vous prenez un VPS via eux, nous touchons une commission sans surcoût pour vous. Chaque commande et valeur ci-dessous est documentée à partir des sources officielles WireGuard et écrite pour être reproductible sur votre machine.

Votre tunnel WireGuard indique « connecté ». wg show montre un handshake récent, le ping vers le serveur répond instantanément — et pourtant les pages web tournent sans fin, SSH gèle en plein transfert, et les gros téléchargements meurent au bout de quelques kilooctets. Neuf fois sur dix, le coupable est le MTU : la taille maximale de paquet que votre tunnel peut transporter. Ce guide explique pourquoi le MTU casse un tunnel qui paraît parfaitement sain, comment mesurer la bonne valeur pour votre lien, et exactement quoi régler.

Si votre handshake n'aboutit jamais au départ, le MTU n'est pas encore votre problème — commencez par la liste complète des correctifs du handshake WireGuard et revenez ici une fois le tunnel monté mais bloqué.

Ce qu'est le MTU et pourquoi WireGuard s'en soucie

Le MTU (Maximum Transmission Unit) est le plus gros paquet, en octets, qu'une interface envoie sans le fragmenter. Sur un lien Ethernet ou fibre normal, c'est 1500 octets. WireGuard enveloppe chacun de vos paquets dans son propre paquet UDP, et cette enveloppe coûte de la place :

• En-tête externe IPv4 : 20 octets
• En-tête externe IPv6 : 40 octets
• En-tête UDP : 8 octets
• En-tête de données WireGuard : 32 octets

Un paquet WireGuard sur IPv6 a donc besoin d'environ 80 octets de surcharge. Retirez-les d'un chemin de 1500 octets et il vous reste environ 1420 octets dans le tunnel — c'est exactement pourquoi WireGuard met son interface à 1420 par défaut. Vérifiez la valeur par défaut sur n'importe quel tunnel actif :

ip link show wg0
# ... mtu 1420 ...

Le problème commence quand le chemin entre vous et votre serveur transporte moins de 1500 octets. Alors 1420 est trop gros, votre vrai trafic déborde, et les paquets en trop disparaissent silencieusement.

Pourquoi le tunnel répond au ping mais les pages bloquent

C'est le symptôme caractéristique, et il déroute tout le monde la première fois :

• Un ping est minuscule — il tient dans n'importe quel MTU, donc il réussit et vous convainc que le tunnel fonctionne.
• Une requête DNS et le handshake TCP en trois temps sont minuscules aussi, donc les connexions démarrent.
• Le premier paquet pleine taille — une page web, une image, un bloc de fichier — dépasse le MTU du chemin et est rejeté.

Normalement un routeur renverrait un message ICMP « fragmentation nécessaire » indiquant à l'émetteur d'utiliser des paquets plus petits (c'est la découverte du MTU de chemin, PMTUD). Mais l'ICMP est filtré sur une énorme partie d'internet, donc ce message n'arrive jamais. L'émetteur continue d'envoyer des paquets surdimensionnés dans le vide. C'est un trou noir PMTU, et voilà pourquoi un tunnel peut paraître vivant tout en étant inutilisable pour le vrai travail.

La même logique explique les rapports « connecté mais sans internet » : le petit trafic de contrôle passe, les grosses données non. Si vous avez écarté le transfert IP et la règle de masquerade (couverts dans le guide d'installation Contabo + WireGuard), le MTU est le suspect suivant.

Mesurer le bon MTU pour votre lien

Ne copiez pas un nombre trouvé sur un forum. Mesurez votre propre chemin avec un ping sans fragmentation vers l'IP publique réelle du serveur (pas son IP de tunnel), en réduisant la charge utile jusqu'à ce que les paquets passent :

# -M do = ne pas fragmenter, -s = taille de charge utile
ping -M do -s 1472 IP_PUBLIQUE_SERVEUR

La charge utile -s 1472 plus 28 octets d'en-tête ICMP+IP égale 1500. Si cela échoue avec « message too long » ou sans réponse, descendez et réessayez :

ping -M do -s 1464 IP_PUBLIQUE_SERVEUR
ping -M do -s 1400 IP_PUBLIQUE_SERVEUR
ping -M do -s 1372 IP_PUBLIQUE_SERVEUR

Sous Windows, l'équivalent est ping -f -l 1472 IP_PUBLIQUE_SERVEUR ; sous macOS, ping -D -s 1472 IP_PUBLIQUE_SERVEUR.

Prenez la plus grande charge utile qui passe, puis faites le calcul :

1. Plus grande charge utile qui passe + 28 = votre MTU de chemin.
2. MTU de chemin − 80 = un MTU WireGuard sûr (utilisez 80 pour le cas IPv6 ; les chemins IPv4 uniquement peuvent utiliser −60, mais −80 est le choix universel sûr).

Exemple chiffré. Supposons que -s 1400 soit le plus grand qui réponde et que -s 1408 échoue. MTU de chemin = 1400 + 28 = 1428. MTU WireGuard = 1428 − 80 = 1348 → arrondi à un 1340 propre.

Régler le MTU WireGuard

Ajoutez une ligne au bloc [Interface] du côté contraint (généralement le client) et redémarrez le tunnel :

[Interface]
PrivateKey = ...
Address = 10.66.66.2/32
MTU = 1340

sudo wg-quick down wg0 && sudo wg-quick up wg0
# ou, sans redémarrage complet :
sudo ip link set dev wg0 mtu 1340

Re-testez aussitôt : chargez une page lourde, lancez un transfert de fichier, ou faites un ping sans fragmentation à travers le tunnel vers l'IP de tunnel du serveur. Si le gros trafic passe désormais, vous tenez votre valeur. Si vous construisez des configs de zéro, les modèles de configuration prêts à l'emploi incluent la ligne MTU au bon endroit pour chaque plateforme.

Valeurs raisonnables par type de lien

Quand vous ne pouvez pas mesurer — ou voulez un point de départ sûr — ces repères documentés couvrent la plupart des liens réels :

1280 est la valeur que tout chemin IPv6 est tenu de transporter, donc c'est le repli sûr quand rien d'autre ne marche : vous perdez un peu d'efficacité mais le blocage disparaît. Préférez toujours une valeur mesurée quand vous pouvez en obtenir une — 1280 laisse de la performance de côté sur un chemin propre de 1500 octets.

Quand le MTU n'est pas la réponse

Abaisser le MTU est le correctif quand les petits paquets passent et les gros non. Si rien ne passe après le handshake, le problème est ailleurs — vérifiez, dans l'ordre :

• net.ipv4.ip_forward = 1 et la règle MASQUERADE sur le serveur.
• Les AllowedIPs côté serveur sans chevauchement entre pairs.
• Un PersistentKeepalive = 25 sur tout pair derrière du NAT.

Les trois sont détaillés dans le guide de dépannage du handshake. Et si vous ne voulez que certaines applis dans le tunnel, abaisser le MTU se marie naturellement avec un routage en split-tunnel pour que l'essentiel de votre trafic évite la surcharge du tunnel.

Un lien propre rend le MTU prévisible

La moitié des soucis de MTU vient d'un chemin désordonné : double NAT, routeur maison capricieux, tunnel empilé sur un tunnel. Un VPS avec une IPv4 publique propre vous offre un seul saut bien élevé, où le défaut standard de 1420 fonctionne généralement tout seul. Un Contabo VPS S à 4,99 €/mois vous donne un root complet et une IP publique sans pare-feu fournisseur à combattre — exactement les conditions où la découverte du MTU de chemin se comporte bien. Suivez l'installation pas à pas Contabo + WireGuard, et si vous hésitez encore sur l'hébergeur, comparez les options dans le guide Contabo vs Hetzner vs OVH.

Pour aller plus loin

• Handshake WireGuard qui n'aboutit pas : la liste complète des correctifs
• Quel port WireGuard utilise et comment l'ouvrir
• Modèles de configuration WireGuard prêts à l'emploi 2026
• VPN auto-hébergé sur Contabo : guide WireGuard complet 2026
• VPN en split-tunnel avec tables de routage
• Glossaire VPN auto-hébergé — AllowedIPs, MTU, NAT expliqués

Sources et références :

• Livre blanc WireGuard — Jason A. Donenfeld
• Quickstart WireGuard et docs wg-quick
• Arch Wiki — WireGuard (notes MTU)
• RFC 8200 — MTU minimum IPv6 de 1280

Publié le 2026-06-24. Les chiffres de surcharge proviennent des en-têtes du protocole WireGuard ; la méthode de mesure est la découverte standard du MTU de chemin. Vos conditions de lien diffèrent — confirmez toujours avec un ping sans fragmentation avant de figer une valeur.

Rappel : faire tourner WireGuard et auto-héberger un VPN est légal dans l'UE, aux États-Unis, au Canada et dans la plupart des pays démocratiques. VPNSmith publie ce contenu à des fins éducatives.