MTU di WireGuard: il valore giusto e come riparare il tunnel bloccato (2026)

Informativa affiliazione — Questo articolo contiene link di affiliazione Contabo. Se prendi un VPS tramite loro, guadagniamo una commissione senza costi extra per te. Ogni comando e valore qui sotto è documentato da fonti ufficiali WireGuard e scritto per essere riproducibile sulla tua macchina.

Il tuo tunnel WireGuard dice «connesso». wg show mostra un handshake recente, il ping al server risponde all'istante — eppure le pagine web girano all'infinito, SSH si congela a metà trasferimento, e i download grandi muoiono dopo pochi kilobyte. Nove volte su dieci il colpevole è l'MTU: la dimensione massima di pacchetto che il tuo tunnel può trasportare. Questa guida spiega perché l'MTU rompe un tunnel altrimenti perfettamente sano, come misurare il valore giusto per il tuo collegamento, ed esattamente cosa impostare.

Se l'handshake non si completa mai in partenza, l'MTU non è ancora il tuo problema — inizia con la lista completa delle correzioni dell'handshake di WireGuard e torna qui una volta che il tunnel è su ma si blocca.

Cos'è l'MTU e perché WireGuard se ne preoccupa

L'MTU (Maximum Transmission Unit) è il pacchetto più grande, in byte, che un'interfaccia invierà senza frammentarlo. Su un normale collegamento Ethernet o in fibra sono 1500 byte. WireGuard avvolge ognuno dei tuoi pacchetti dentro il suo pacchetto UDP, e questo involucro costa spazio:

• Header esterno IPv4: 20 byte
• Header esterno IPv6: 40 byte
• Header UDP: 8 byte
• Header dati di WireGuard: 32 byte

Quindi un pacchetto WireGuard su IPv6 ha bisogno di circa 80 byte di overhead. Toglili da un percorso di 1500 byte e ti restano circa 1420 byte dentro il tunnel — ecco perché WireGuard imposta la sua interfaccia a 1420 per impostazione predefinita. Conferma il valore predefinito su qualsiasi tunnel attivo:

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

I guai iniziano quando il percorso tra te e il tuo server trasporta meno di 1500 byte. Allora 1420 è troppo grande, il tuo traffico reale trabocca, e i pacchetti in eccesso spariscono silenziosamente.

Perché il tunnel risponde al ping ma le pagine si bloccano

È il sintomo caratteristico, e confonde tutti la prima volta:

• Un ping è minuscolo — entra in qualsiasi MTU, quindi riesce e ti convince che il tunnel funziona.
• Una query DNS e l'handshake TCP a tre vie sono minuscoli anch'essi, quindi le connessioni partono.
• Il primo pacchetto a piena dimensione — una pagina web, un'immagine, un pezzo di file — supera l'MTU del percorso e viene scartato.

Normalmente un router rispedirebbe un messaggio ICMP «frammentazione necessaria» dicendo al mittente di usare pacchetti più piccoli (è la scoperta dell'MTU di percorso, PMTUD). Ma l'ICMP è filtrato su una fetta enorme di internet, quindi quel messaggio non arriva mai. Il mittente continua a sparare pacchetti sovradimensionati in un buco nero. È un buco nero PMTU, ed ecco perché un tunnel può sembrare vivo ed essere comunque inutile per il lavoro reale.

La stessa logica spiega le segnalazioni «connesso ma senza internet»: il piccolo traffico di controllo passa, i dati grandi no. Se hai escluso l'inoltro IP e la regola di masquerade (trattati nella guida all'installazione Contabo + WireGuard), l'MTU è il sospetto successivo.

Misura l'MTU giusto per il tuo collegamento

Non copiare un numero da un forum. Misura il tuo percorso con un ping senza frammentazione verso l'IP pubblico reale del server (non il suo IP di tunnel), riducendo il payload finché i pacchetti passano:

# -M do = non frammentare, -s = dimensione del payload
ping -M do -s 1472 IP_PUBBLICO_SERVER

Il payload -s 1472 più 28 byte di header ICMP+IP fa 1500. Se fallisce con «message too long» o senza risposta, scendi e riprova:

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

Su Windows l'equivalente è ping -f -l 1472 IP_PUBBLICO_SERVER; su macOS, ping -D -s 1472 IP_PUBBLICO_SERVER.

Prendi il payload più grande che passa, e fai il conto:

1. Payload più grande che passa + 28 = il tuo MTU di percorso.
2. MTU di percorso − 80 = un MTU di WireGuard sicuro (usa 80 per il caso IPv6; i percorsi solo IPv4 possono usare −60, ma −80 è la scelta universale sicura).

Esempio risolto. Supponi che -s 1400 sia il più grande che risponde e -s 1408 fallisca. MTU di percorso = 1400 + 28 = 1428. MTU di WireGuard = 1428 − 80 = 1348 → arrotonda a un pulito 1340.

Imposta l'MTU di WireGuard

Aggiungi una riga al blocco [Interface] sul lato limitato (di solito il client) e riavvia il tunnel:

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

sudo wg-quick down wg0 && sudo wg-quick up wg0
# oppure, senza un riavvio completo:
sudo ip link set dev wg0 mtu 1340

Riprova subito: carica una pagina pesante, lancia un trasferimento di file, o fai un ping senza frammentazione attraverso il tunnel verso l'IP di tunnel del server. Se il traffico grande ora scorre, hai il tuo valore. Se costruisci configurazioni da zero, i modelli di configurazione pronti all'uso includono la riga MTU nel posto giusto per ogni piattaforma.

Valori sensati per tipo di collegamento

Quando non puoi misurare — o vuoi un punto di partenza sicuro — questi valori di riferimento documentati coprono la maggior parte dei collegamenti reali:

1280 è il valore che ogni percorso IPv6 è tenuto a trasportare, quindi è il ripiego sicuro quando nient'altro funziona: perdi un po' di efficienza ma il blocco sparisce. Preferisci sempre un valore misurato quando puoi ottenerne uno — 1280 lascia prestazioni sul tavolo su un percorso pulito di 1500 byte.

Quando l'MTU non è la risposta

Abbassare l'MTU è la correzione quando i pacchetti piccoli passano e quelli grandi no. Se niente scorre dopo l'handshake, il problema è altrove — controlla, nell'ordine:

• net.ipv4.ip_forward = 1 e la regola MASQUERADE sul server.
• Gli AllowedIPs lato server senza sovrapposizioni tra peer.
• Un PersistentKeepalive = 25 su ogni peer dietro NAT.

Tutti e tre sono percorsi nella guida alla risoluzione dei problemi dell'handshake. E se ti servono solo certe app nel tunnel, abbassare l'MTU si sposa naturalmente con un routing in split-tunnel così che il grosso del tuo traffico eviti del tutto l'overhead del tunnel.

Un collegamento pulito rende l'MTU prevedibile

Metà del dolore da MTU viene da un percorso disordinato: doppio NAT, un router di casa instabile, un tunnel impilato su un tunnel. Un VPS con un IPv4 pubblico pulito ti dà un singolo salto ben educato, dove il valore predefinito standard di 1420 di solito funziona da solo. Un Contabo VPS S a 4,99 €/mese ti dà root completo e un IP pubblico senza firewall del provider da combattere — esattamente le condizioni in cui la scoperta dell'MTU di percorso si comporta bene. Segui l'installazione passo passo Contabo + WireGuard, e se stai ancora scegliendo un provider, confronta le opzioni nella guida Contabo vs Hetzner vs OVH.

Per approfondire

• Handshake di WireGuard che non si completa: la lista completa delle correzioni
• Quale porta usa WireGuard e come aprirla
• Modelli di configurazione WireGuard pronti all'uso 2026
• VPN autogestito su Contabo: guida completa a WireGuard 2026
• VPN in split-tunnel con tabelle di routing
• Glossario VPN self-hosted — AllowedIPs, MTU, NAT spiegati

Fonti e riferimenti:

• Whitepaper di WireGuard — Jason A. Donenfeld
• Quickstart di WireGuard e documentazione wg-quick
• Arch Wiki — WireGuard (note MTU)
• RFC 8200 — MTU minimo IPv6 di 1280

Pubblicato il 2026-06-24. Le cifre di overhead provengono dagli header del protocollo WireGuard; il metodo di misurazione è la scoperta standard dell'MTU di percorso. Le tue condizioni di collegamento differiscono — conferma sempre con un ping senza frammentazione prima di fissare un valore.

Promemoria: eseguire WireGuard e autogestire una VPN è legale nell'UE, negli USA, in Canada e nella maggior parte dei paesi democratici. VPNSmith pubblica questi contenuti a scopo educativo.