WireGuard «Handshake did not complete after 5 seconds»: 8 cause

Scrivi wg show, vedi il tuo peer, e proprio sotto c'è la riga che ti rovina la serata: latest handshake è vuota, o wg-quick ti avverte handshake did not complete. Il tuo tunnel è su sulla carta ma non passa traffico. La buona notizia: WireGuard fallisce per un elenco breve e finito di ragioni, e arrivano in un ordine prevedibile. Questa guida percorre quell'ordine dal più comune al più raro, per smettere di indovinare e risolvere in minuti.

WireGuard è silenzioso per scelta - non invia nulla finché non ci sono dati da trasportare, e non registra mai un gentile «connection refused». Questo silenzio rende misterioso un handshake fallito. Quasi sempre è un problema di raggiungibilità di rete (firewall, porta, NAT, routing), non di crittografia. Percorri l'elenco dall'alto in basso e lo prenderai.

Poco tempo? Due cause spiegano la maggior parte degli handshake falliti: una porta UDP che non raggiunge mai il server (firewall chiuso, inoltro mancante o CGNAT sulla linea di casa) e poi, a tunnel attivo, un MTU troppo alto. Il verificatore di porta WireGuard indica se sei dietro CGNAT e scrive le regole di inoltro e firewall per il tuo sistema; il calcolatore MTU dà il valore da impostare quando l'handshake funziona.

Non sai quale dei due? Il nostro verificatore di porta WireGuard gratuito confronta l'indirizzo WAN del router con il tuo IP pubblico: in meno di un minuto ti dice se sei dietro CGNAT (nessun port forwarding funzionerà) o se bastano un inoltro e una regola del firewall.

Dietro CGNAT? Nessun port forwarding né regola firewall dalla tua parte può aprire una strada verso un server di casa. La via d'uscita abituale è far girare il server WireGuard su un VPS con un proprio IPv4 pubblico, come un Cloud VPS Contabo (link di affiliazione), da 5,50 € al mese con durata di 24 mesi (prezzo rilevato il 17 ottobre 2026). Se preferisci un provider statunitense con 30 giorni soddisfatti o rimborsati, il VPS Basic di Ultahost costa 5,52 $ al mese su 24 mesi (1 GB di RAM, IPv4 dedicato, letto il 21 ottobre 2026), sufficiente per un server WireGuard con pochi dispositivi. Provider ancora da scegliere? Confronti: miglior VPS per una VPN e Contabo vs Hetzner vs OVH, al prezzo realmente fatturato. Un'altra opzione: HostPapa Unmanaged VPS Lite (link affiliato) a 2,95 $ al mese con un impegno di 3 anni, poi a tariffa normale (1 core, 1 GB di RAM, 25 GB NVMe, accesso root via SSH, rimborso entro 30 giorni, rilevato il 28 ottobre 2026).

Non hai ancora scelto il server? La nostra classifica dei VPS più economici per WireGuard confronta quanto fattura davvero ogni fornitore per un server utilizzabile.

La riga di log esatta: "Handshake for peer 1 did not complete after 5 seconds"

Se hai cercato l'errore parola per parola, è questo il messaggio che hai davanti. Lo stampa il modulo del kernel Linux (una volta attivato il log di debug), e wireguard-go, l'implementazione in userspace dietro le app per Windows, macOS e Android, ne stampa una versione quasi identica:

wireguard: wg0: Handshake for peer 1 (203.0.113.10:51820) did not complete after 5 seconds, retrying (try 2)
wireguard: wg0: Handshake for peer 1 (203.0.113.10:51820) did not complete after 20 attempts, giving up

Come leggerla:

• "after 5 seconds" non è un parametro che puoi regolare. È il timeout fisso di ritrasmissione di WireGuard (REKEY_TIMEOUT, 5 s nel sorgente). Il tuo peer ha inviato un'iniziazione di handshake e non ha ricevuto alcuna risposta valida entro quella finestra.
• "retrying (try 2)" significa che sta ancora provando. WireGuard continua a ritrasmettere per circa 90 secondi in totale.
• "did not complete after 20 attempts, giving up" è la fine di quel ciclo. Il peer resta in silenzio finché nuovo traffico non prova ad attraversare il tunnel, il che avvia un nuovo giro.
• Failed to send handshake initiation: no known endpoint for peer è un caso diverso: quel lato non ha un Endpoint = per il peer, quindi non può avviare nulla e può solo aspettare di essere contattato. Normale su un server; un errore di configurazione su un client.

Su Linux il modulo del kernel non registra nulla di default. Per vedere queste righe:

echo module wireguard +p | sudo tee /sys/kernel/debug/dynamic_debug/control
sudo dmesg -w | grep wireguard

Il messaggio dimostra una sola cosa: l'iniziazione è partita e non è tornato nulla di valido. Non dice perché. Le cause qui sotto, in ordine, sono il perché.

Prima, leggi lo stato reale con wg show

Prima di cambiare qualsiasi cosa, guarda cosa WireGuard ti dice già. Su entrambi i lati:

sudo wg show

Stai leggendo tre cose:

• latest handshake - vuoto o più vecchio di ~2 minuti = tunnel giù. Sano = negli ultimi 120 secondi.
• transfer - 0 B received significa che i tuoi pacchetti non sono mai tornati. Inviato-ma-niente-ricevuto è la firma di un firewall o NAT a senso unico.
• endpoint - sul server, deve mostrare l'IP:porta pubblico attuale del client appena arriva un pacchetto. Se non si popola mai, l'iniziazione del client non ti ha raggiunto.

Tieni aperto questo terminale. Dopo ogni soluzione qui sotto, riesegui wg show e osserva la riga latest handshake. È la tua unica fonte di verità - non l'icona di connessione, non l'app.

wg show latest-handshakes - la forma leggibile da una macchina

Un wg show da solo stampa un latest handshake: 1 minute, 12 seconds ago pensato per l'occhio umano. Comodo da leggere, inutilizzabile in uno script. Il manuale wg(8) permette di aggiungere un attributo per restringere l'output:

show { <interface> | all | interfaces } [public-key | private-key | listen-port |
      fwmark | peers | preshared-keys | endpoints | allowed-ips |
      latest-handshakes | persistent-keepalive | transfer | dump]

La forma di riferimento è quindi:

sudo wg show wg0 latest-handshakes

Stampa una riga per peer: la chiave pubblica in base64 del peer, una tabulazione, poi l'ultimo handshake in secondi dall'epoch Unix. È letteralmente ciò che fa lo strumento: in wireguard-tools, src/show.c contiene printf("%s\t%llu\n", key(peer->public_key), peer->last_handshake_time.tv_sec);:

xTIBd0Kx3Hs9tPmVvQ4ZlLxYcE8nRr2A6WKsPqUvT1s=	1750684173
9QzrN7bLyF0mXaHcJdSoEuIgYkTvW3pB5nRfZ1AhQ0M=	0

Due cose da sapere su quel numero:

• 0 significa che quel peer non ha mai completato un handshake da quando l'interfaccia è salita. Non un timestamp scaduto: un timestamp assente. È esattamente lo stato che stai debuggando su questa pagina.
• È un tempo epoch assoluto, non un'età. Sottrailo a date +%s per ottenere i secondi trascorsi dall'ultimo handshake:

now=$(date +%s)
sudo wg show wg0 latest-handshakes | while read -r peer ts; do
  if [ "$ts" -eq 0 ]; then
    echo "$peer mai"
  else
    echo "$peer $((now - ts))s fa"
  fi
done

Due dettagli che mordono quando lo si mette in uno script. wg show all latest-handshakes antepone il nome dell'interfaccia come prima colonna separata da tabulazione, quindi il tuo read ha bisogno di una terza variabile. E wg show wg0 dump restituisce lo stesso timestamp insieme a endpoint, allowed-ips e contatori di trasferimento, in una riga per peer separata da tabulazioni: è la forma da parsare se stai costruendo un monitor vero e non una one-liner.

Oltre i ~180 secondi su un peer che dovrebbe essere attivo, il tunnel è caduto. È la soglia su cui allertare, e il resto di questa pagina è l'elenco ordinato dei motivi.

Causa 1 - La porta UDP è bloccata (il colpevole n.1)

WireGuard parla UDP su una singola porta - 51820 di default. Se quella porta è filtrata da qualche parte sul percorso, il pacchetto di iniziazione muore e ottieni esattamente il tuo sintomo. Per capire questo default, come cambiarlo e aprirlo correttamente, vedi quale porta usa WireGuard e come aprirla. Di solito ci sono due firewall da controllare, e si dimentica il primo:

Firewall del provider cloud (il più spesso dimenticato). Contabo, Hetzner, OVH, AWS - hanno tutti un firewall di rete o security group davanti al tuo VPS. Una regola che consenta UDP 51820 da ovunque deve esistere lì, separata dal firewall di sistema. Sulla maggior parte delle immagini VPS Contabo non c'è un firewall del provider di default (bene), ma se ne hai attivato uno, aggiungi la regola UDP.

Firewall di sistema sul server. Controlla e consenti:

# ufw (Debian/Ubuntu)
sudo ufw allow 51820/udp
sudo ufw reload

# firewalld (Rocky/Alma/Fedora)
sudo firewall-cmd --add-port=51820/udp --permanent
sudo firewall-cmd --reload

Prova rapida che la porta sia raggiungibile dall'esterno - dalla tua macchina client:

# invia una sonda UDP; "open|filtered" senza risposta non è conclusivo,
# ma "open" o un pacchetto restituito conferma la raggiungibilità
nc -u -z -v IP_DEL_TUO_SERVER 51820

Test più pulito: esegui sudo tcpdump -n -i eth0 udp port 51820 sul server, poi connettiti dal client. Se vedi pacchetti in entrata, la porta è aperta e passi alla causa successiva. Se non vedi nulla, il pacchetto viene scartato prima di raggiungere WireGuard - resta su questa causa.

Non arriva nulla e il server è a casa? Controlla il CGNAT

Se il «server» è un Raspberry Pi, un NAS o un PC sulla tua connessione di casa, un tcpdump vuoto spesso non c'entra nulla con il firewall. Molti operatori (quasi tutti i router 4G/5G e sempre più offerte FTTH e FWA) mettono i clienti dietro CGNAT: il tuo router condivide un solo IPv4 pubblico con altri abbonati, quindi nessun port forwarding potrà mai far arrivare un pacchetto UDP in entrata alla tua macchina. Confronta l'indirizzo WAN mostrato dal router con quello restituito da curl -4 ifconfig.me. Se sono diversi, o se il router mostra un indirizzo in 100.64.0.0/10, sei dietro CGNAT e l'handshake non può completarsi con questa configurazione.

Hai tre vie d'uscita: chiedere un IPv4 pubblico al tuo operatore (alcuni lo danno gratis, altri a pagamento, molti rifiutano), usare IPv6 da un capo all'altro se entrambi i lati lo hanno, oppure mettere il server WireGuard su un piccolo VPS con il suo IPv4 pubblico e, se devi ancora raggiungere la macchina di casa, collegarla al VPS come client. La guida CGNAT spiega il tunnel inverso, e il nostro generatore di config WireGuard gratuito scrive i file server e client con chiavi che corrispondono.

Non sai se un port forwarding può funzionare sulla tua connessione? Il nostro verificatore di porta WireGuard gratuito confronta l'indirizzo WAN del router con il tuo IP pubblico, rileva il CGNAT, scrive le regole di inoltro e di firewall per la tua configurazione e fornisce il test tcpdump che dimostra che i pacchetti arrivano al server.

Funziona a casa ma non sul Wi-Fi di un hotel, un ufficio o un campus?

Allora il server va bene e la rete su cui ti trovi blocca l'UDP, oppure riconosce WireGuard e lo taglia. Il test con tcpdump qui sopra resta vuoto solo mentre sei su quella rete. Se il server è tuo, sposta ListenPort (e l'Endpoint del client) su UDP 443, la porta già usata da HTTP/3, che supera la maggior parte dei filtri per porta; la nostra guida alla porta di WireGuard spiega il cambio. Se ti serve solo una VPN funzionante su quella rete e non gestisci un server, un'app VPN con modalità di offuscamento incapsula il tunnel per te: Proton VPN offre Stealth, su tutti i piani compreso quello gratuito, e NordVPN offre NordWhisper, che fa sembrare il traffico VPN normale traffico web (link di affiliazione). Contro l'ispezione approfondita dei pacchetti, vedi la guida anti-DPI.

Piano a pagamento, Black Friday 2026: l'offerta partner di Proton, verificata il 28 ottobre 2026, è VPN Plus a 2,49 $/mese per 2 anni (59,76 $ per i primi 24 mesi, poi 83,88 $ all'anno), con garanzia di rimborso di 30 giorni e 10 dispositivi. La pagina d'ordine mostra il prezzo del tuo paese, e Proton non indica una data di fine.

Causa 2 - Endpoint errato sul client

Il blocco [Peer] del client ha bisogno dell'IP pubblico reale del server (o del nome DNS) e del ListenPort esatto:

[Peer]
PublicKey = CHIAVE_PUBBLICA_SERVER
Endpoint = 203.0.113.10:51820
AllowedIPs = 0.0.0.0/0

Errori comuni che producono un handshake morto:

• L'Endpoint punta all'IP LAN privato del server (10.x / 192.168.x) invece di quello pubblico.
• Un refuso nella porta, o il server in realtà ascolta su un altro ListenPort.
• L'IP pubblico del server è cambiato (alcune reinstallazioni di VPS lo riassegnano). Conferma con curl -4 ifconfig.co sul server, poi confronta con l'Endpoint del client.

Il blocco peer sul server non ha la riga Endpoint (il server la impara quando arriva il pacchetto del client) - aggiungerne una lì è un errore di copia-incolla frequente.

Causa 3 - AllowedIPs errati

AllowedIPs è una tabella di routing crittografica, non un elenco di permessi, e un errore rompe in silenzio il traffico di ritorno:

• Sul server, l'AllowedIPs del peer deve elencare solo l'indirizzo tunnel di quel client, es. 10.66.66.2/32. Se due peer condividono un intervallo che si sovrappone, il server invia le risposte a quello sbagliato e l'handshake «si completa» e poi muore.
• Sul client, AllowedIPs = 0.0.0.0/0 instrada tutto nel tunnel (VPN completa). Per lo split tunneling, elenca solo le subnet che instradi davvero - vedi la nostra guida al routing in split-tunnel.

Un handshake che riesce brevemente e poi si blocca è la firma classica di AllowedIPs sovrapposti lato server. Rendi unico l'intervallo di ogni peer.

Devi escludere la tua LAN o un singolo indirizzo da un tunnel completo? AllowedIPs non ha una sintassi "tranne", quindi il nostro calcolatore AllowedIPs gratuito trasforma "tutto tranne X" nell'elenco minimo di intervalli IPv4 e IPv6 da incollare.

Causa 4 - Timeout NAT (funziona 2 minuti, poi muore)

Se il tuo client è dietro NAT (router di casa, 4G/5G, Wi-Fi d'hotel) e il collegamento diventa inattivo, il router elimina il mapping UDP. Il server non ha più un percorso di ritorno verso il client e l'handshake scade in silenzio. La soluzione vive sul peer dietro il NAT:

[Peer]
PublicKey = CHIAVE_PUBBLICA_SERVER
Endpoint = 203.0.113.10:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

PersistentKeepalive = 25 invia un pacchetto minuscolo ogni 25 secondi, tenendo aperto il mapping NAT. Venticinque secondi sono sotto ogni timeout NAT comune. Aggiungilo sui client nomadi e su qualsiasi peer dietro un router restrittivo. Il peer lato server di solito non ne ha bisogno.

Causa 5 - L'inoltro IP è spento sul server

Se l'handshake si completa ma non raggiungi Internet attraverso il tunnel, il server non inoltra i pacchetti tra l'interfaccia WireGuard ed eth0. Abilitalo:

echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system

Conferma: sysctl net.ipv4.ip_forward deve restituire 1. Abbinalo alla regola di masquerade nel tuo PostUp (i modelli di configurazione pronti all'uso includono queste righe correttamente):

PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

Causa 6 - Sfasamento dell'orologio

L'handshake di WireGuard usa timestamp per bloccare gli attacchi di replay. Se l'orologio del server devia di più di un paio di minuti - comune su immagini VPS fresche o VM messe in pausa - gli handshake vengono rifiutati come scaduti. Correggi l'orologio:

sudo timedatectl set-ntp true
timedatectl status   # System clock synchronized: yes

Questa è subdola perché tutto il resto sembra perfetto. Se hai triplo-controllato porta, chiavi e routing e ancora non ottieni nulla, controlla l'orologio prima di disperare.

Causa 7 - Chiavi non corrispondenti (controlla questo per ultimo)

Si va prima sulle chiavi; controllale per ultime, perché un errore di chiave è più raro delle sei cause sopra e produce lo stesso sintomo. La regola è semplice:

• La [Peer] PublicKey del server = la chiave pubblica derivata dalla PrivateKey del client.
• La [Peer] PublicKey del client = la chiave pubblica derivata dalla PrivateKey del server.

Rigenera e ri-deriva per essere certo:

# su ogni macchina, deriva la chiave pubblica dalla propria chiave privata
echo "CHIAVE_PRIVATA_DI_QUESTO_HOST" | wg pubkey

Confronta quell'output con la PublicKey che l'altro lato ha per te. Una sola chiave scambiata o troncata rompe completamente l'handshake. Già che ci sei, una PresharedKey (se usata) deve essere identica su entrambi i peer - una differenza lì uccide anch'essa l'handshake. Cosa protegge davvero la chiave precondivisa, e come aggiungerla senza interrompere un tunnel attivo, è nella guida alla chiave precondivisa di WireGuard.

Per escludere le chiavi in un colpo solo, il nostro generatore di configurazione WireGuard gratuito crea nel browser una nuova coppia di chiavi per ogni lato e inserisce ogni chiave pubblica nel blocco [Peer] dell'altro, con una PresharedKey identica su entrambi i lati.

Causa 8 - L'MTU rompe il tunnel subito dopo l'handshake

A rigore, l'MTU blocca raramente l'handshake (i suoi pacchetti sono piccoli). Ma rompe spesso le cose appena scorre traffico reale: l'handshake si completa, il ping funziona, poi le pagine web si bloccano per sempre. È frammentazione. Abbassa l'MTU del client:

[Interface]
MTU = 1380

Trova il valore giusto con un ping «do-not-fragment» verso l'IP tunnel del server, riducendolo finché passa:

ping -M do -s 1372 10.66.66.1

1420 va bene per la maggior parte dei collegamenti in fibra; 1380 è un default sicuro; PPPoE e alcuni operatori mobili richiedono 1280. La nostra guida ai modelli di configurazione spiega la regolazione dell'MTU per tipo di collegamento. Se il tunnel si connette ma si blocca sui trasferimenti grandi, la guida dedicata riparare l'MTU di WireGuard mostra come misurare il valore esatto con un ping senza frammentazione e impostarlo per tipo di collegamento.

Per ottenere il valore invece di indovinarlo, il calcolatore MTU WireGuard gratuito parte dal payload più grande passato dal tuo ping senza frammentazione (o solo dal tipo di collegamento) e scrive la riga MTU = della tua configurazione.

L'ordine di diagnosi in 60 secondi

Quando un handshake fallisce, esegui questa sequenza esatta e fermati alla prima cosa sbagliata:

1. wg show su entrambi i lati - c'è un qualsiasi latest handshake, qualche byte received?
2. tcpdump udp port 51820 sul server mentre il client si connette - arrivano pacchetti?
3. Se non arriva nessun pacchetto → firewall / porta / Endpoint (cause 1-2).
4. Se arrivano pacchetti ma nessuna risposta torna → AllowedIPs lato server, NAT, rotta di ritorno (cause 3-4).
5. Se l'handshake si completa ma niente Internet → ip_forward + masquerade (causa 5).
6. Se tutto sembra giusto e ancora niente → sfasamento orologio, poi chiavi, poi MTU (cause 6-8).

Quest'ordine segue il percorso del pacchetto, dalla raggiungibilità al routing fino alle cause meno evidenti - percorrilo dall'alto in basso e non perderai tempo.

Costruiscilo bene dall'inizio

La maggior parte degli handshake falliti nasce da una config cucita a mano da tre tutorial contraddittori. Partire da una base nota e buona su un VPS pulito elimina la maggior parte delle sorprese. Un Contabo Cloud VPS 4 a 5,50 €/mese ti dà un IPv4 pubblico, root completo, e nessun firewall del provider da combattere - esattamente le condizioni in cui WireGuard «funziona e basta». Segui il setup Contabo + WireGuard passo passo e incolla una config verificata dalla guida ai modelli, e parti da righe che si sa funzionare insieme.

Se preferisci ricostruire entrambi i lati da zero, il nostro generatore di configurazione WireGuard gratuito crea le chiavi nel browser e scrive configurazioni server e client coerenti: chiavi pubbliche, AllowedIPs ed Endpoint combaciano al primo colpo.

Per avere l'essenziale a portata di mano: la WireGuard Cheat Sheet gratuita (PDF di 5 pagine in inglese, download diretto, senza registrazione) raccoglie le tabelle di keepalive e MTU, i comandi wg genkey/wg pubkey/wg genpsk e i quattro controlli del server in una riga da lanciare per primi quando un tunnel non fa passare traffico. Il WireGuard Self-Hosting Kit a pagamento (9 USD, in inglese) aggiunge una checklist di diagnosi con 12 cause e 11 modelli di configurazione.

Una VPN cambia il tuo IP. Non cambia il tuo browser.

Un tunnel sostituisce l'indirizzo che un servizio vede. Non cambia nulla di ciò che il tuo browser dichiara da solo - caratteri, schermo, fuso orario, stack grafico - e quella combinazione basta spesso a riconoscerti da una sessione all'altra.

Misura la tua impronta del browser - misurazione passiva, senza domande, senza account, senza email.

Per approfondire

• PersistentKeepalive: cosa fa davvero l'impostazione a 25 secondi
• WireGuard multihop: concatenare due server autogestiti
• WireGuard dietro CGNAT: perché l'handshake non arriva mai
• WireGuard su Windows: configurazione passo passo
• WireGuard su iPhone e iPad: la configurazione iOS completa
• VPN autogestito su Contabo: guida completa a WireGuard 2026
• Modelli di configurazione WireGuard pronti all'uso 2026
• Fughe DNS in WireGuard: rilevare, diagnosticare, eliminare
• Kill-switch WireGuard su Linux: iptables + systemd
• VPN in split-tunnel con tabelle di routing
• Glossario VPN self-hosted - AllowedIPs, MTU, NAT spiegati
• PiVPN nel 2026: il modo più semplice per ospitare WireGuard o OpenVPN

Fonti e riferimenti:

• Whitepaper di WireGuard - Jason A. Donenfeld
• Quickstart di WireGuard e docs di wg-quick
• Pagine di manuale wg(8) e wg-quick(8)
• Arch Wiki - risoluzione problemi WireGuard

Pubblicato il 2026-06-23. Comandi scritti per server Debian 12 e Ubuntu 24.04 a partire dalla documentazione ufficiale di WireGuard; non abbiamo un banco di prova con più client. Le tue condizioni di collegamento possono variare - conferma sempre con wg show e tcpdump prima di considerare definitiva una soluzione.

Promemoria: eseguire WireGuard e auto-ospitare una VPN è legale nell'UE, negli USA, in Canada. VPNSmith pubblica questo contenuto a scopo educativo.

Vale anche la pena verificare dove risiedono le chiavi: un avviso CISA del luglio 2026 riguarda un difetto di RouterOS che consente di leggere una chiave privata WireGuard statica dal router stesso. Vedi perché disattivare l'API non lo annulla.