Porta WireGuard: UDP 51820 di default, cambiala in 3 passi

WireGuard usa la porta UDP 51820 per impostazione predefinita, fissata dalla riga ListenPort della configurazione del server (wg0.conf). Non usa mai TCP, e 51820 è solo una convenzione: puoi scegliere qualsiasi porta UDP libera. Quasi ogni problema di "la mia VPN self-hosted non si connette" si riduce a quella porta non aperta, non inoltrata o diversa dall'Endpoint del client. Questa guida copre il valore predefinito, come cambiarlo e come aprirlo e inoltrarlo correttamente.

Controlla la tua configurazione: il verificatore di porta WireGuard confronta l'indirizzo WAN del router con il tuo IP pubblico per individuare il CGNAT (dove nessun port forwarding può funzionare), poi scrive la regola di inoltro e i comandi firewall per ufw, firewalld, nftables, iptables, Windows o OpenWrt.

Se il verificatore trova il CGNAT, nessun inoltro funzionerà da casa: la soluzione è ospitare il server su un VPS con un proprio IPv4 pubblico, per esempio un Cloud VPS Contabo (link di affiliazione), da 5,50 € al mese con durata di 24 mesi (prezzo rilevato il 17 ottobre 2026).

Le porte di WireGuard in sintesi

La risposta breve: WireGuard usa la porta UDP 51820 per impostazione predefinita - è la sua porta standard, impostata dalla riga ListenPort. Non esiste alcuna modalità TCP. Le porte che contano:

L'Endpoint = <public-ip>:<port> del client deve usare esattamente la stessa porta del ListenPort del server - questa discrepanza è di gran lunga il motivo più comune per cui un tunnel WireGuard self-hosted non si connette.

La maggior parte dei problemi nasce da un ListenPort e un Endpoint che non coincidono, o da un router su cui non puoi inoltrare porte (CGNAT). Il nostro generatore di configurazione WireGuard gratuito scrive configurazioni server e client coerenti nel tuo browser. Un VPS con un proprio IPv4 pubblico elimina del tutto l'inoltro delle porte: un Cloud VPS 4 di Contabo è indicato da 5,50 €/mese su contabo.com (verificato il 17/10/2026), e un VPS Basic di Ultahost con IPv4 dedicato a 5,52 $/mese con impegno di 24 mesi su ultahost.com (verificato il 21/10/2026).

La tua porta è davvero raggiungibile? Uno scanner di porte online non può dirlo: WireGuard non risponde mai a pacchetti non autenticati, quindi ogni scansione dice "open|filtered". La nostra verifica porta WireGuard gratuita confronta l'indirizzo WAN del router con il tuo IP pubblico per individuare CGNAT e doppio NAT, poi fornisce la regola firewall per il tuo sistema e il test dall'esterno che prova davvero che la porta è aperta.

Il predefinito: UDP 51820

WireGuard ascolta su porta UDP 51820 per convenzione, impostata dalla linea ListenPort nella sezione [Interface] del server. Due cose sono importanti qui:

• È UDP, non TCP. WireGuard non ha alcuna modalità TCP. I firewall o le reti che bloccano UDP lo fermeranno completamente.
• 51820 è solo il predefinito, non una regola - puoi usare qualsiasi porta UDP libera da 1 a 65535.

I client raggiungono il server usando la linea Endpoint = <public-ip>:51820 nella loro configurazione. Quella porta deve corrispondere esattamente al ListenPort del server.

Scegliere una porta: vale la pena usare 443/UDP?

Qualsiasi porta UDP libera da 1 a 65535 funziona, ma alcune scelte sono più intelligenti di altre:

• Mantieni 51820 per semplicità se la tua rete non filtra UDP - è il predefinito documentato e il più facile da supportare.
• Usa UDP 443 se sei su una rete restrittiva. La porta 443 è la porta HTTPS, e il traffico web moderno (HTTP/3 / QUIC) già funziona su UDP 443, quindi un tunnel WireGuard lì si mescola con il traffico crittografato dall'aspetto normale e sfugge a molti blocchi basati sulle porte. È il singolo cambiamento di porta più utile. Nota che questo è solo un camuffamento a livello di porta - l'ispezione approfondita dei pacchetti può ancora identificare la stretta di mano (vedi la sezione stealth sotto).
• Evita le porte sotto 1024 a meno che tu non abbia una ragione; sono "privilegiate" e richiedono root, senza alcun vantaggio qui.

Aprire la porta nel firewall

Sul server, la porta deve essere consentita per UDP. Con UFW:

sudo ufw allow 51820/udp
sudo ufw reload

Con iptables è -A INPUT -p udp --dport 51820 -j ACCEPT. Questa è la causa più comune di un server che "funziona" ma non accetta mai connessioni: il servizio WireGuard è attivo, ma il firewall lascia cadere silenziosamente i pacchetti.

Inoltrare la porta attraverso un router

Dove si trova il tuo server decide se hai anche bisogno di inoltro porta:

• Su un VPS (un server noleggiato con un IP pubblico): non è necessario l'inoltro - la regola del firewall è sufficiente, perché l'IP pubblico punta direttamente alla macchina.
• Su un server domestico dietro un router: aggiungi una regola di inoltro porta nell'amministrazione del router - inoltra UDP 51820 (esterno) all'IP locale del server su UDP 51820 (interno). Senza di esso, i pacchetti da internet non raggiungono mai il server.

Testa da fuori la tua rete (ad esempio, un telefono con dati mobili, Wi-Fi spento): un client dovrebbe raggiungere server-public-ip:51820. Se funziona sulla tua LAN ma non dall'esterno, l'inoltro è il pezzo mancante.

Cambiare la porta

Per usare una porta diversa, impostala nella [Interface] del server:

[Interface]
ListenPort = 51821

Poi riavvia il tunnel (systemctl restart wg-quick@wg0) e aggiorna tutto ciò che faceva riferimento alla vecchia porta:

1. la regola del firewall (consenti la nuova porta UDP),
2. l'inoltro del router (se applicabile),
3. la linea Endpoint in ogni configurazione client.

Se ne manca uno, i client non si connetteranno. Un VPS self-hosted rende tutto questo semplice perché controlli direttamente il firewall e l'IP pubblico. Se modifichi la configurazione da zero, i nostri modelli di configurazione WireGuard pronti all'uso ti forniscono uno scheletro [Interface]/[Peer] corretto con le righe ListenPort ed Endpoint già al posto giusto.

Verifica che la porta stia effettivamente ascoltando

Prima di incolpare il client, conferma che il server stia davvero ascoltando sulla porta che pensi:

sudo wg show              # mostra l'interfaccia e la sua porta di ascolto
sudo ss -lunp | grep 51820   # qualcosa è legato a UDP 51820?

wg show elenca la porta di ascolto attiva; ss -lunp (nota la u per UDP) dimostra che un processo è legato ad essa. Se wg show riporta una porta diversa dalla tua configurazione, il servizio non si è ricaricato dopo la tua modifica - riavvialo. Da un'altra macchina puoi testare la raggiungibilità con nc -uvz server-ip 51820, anche se i test UDP sono inaffidabili, quindi una vera stretta di mano del client è il test definitivo.

Eseguire più di un tunnel

Ogni interfaccia WireGuard ha bisogno della propria ListenPort. Se esegui, ad esempio, wg0 per il traffico generale e wg1 per un gruppo separato di peer, assegna loro porte distinte (ad esempio 51820 e 51821), apri e inoltra entrambe, e punta ogni client a quella giusta. Due interfacce che condividono una porta non riescono ad avviarsi.

Cambiare la porta nasconde la tua VPN?

Una porta non predefinita riduce il rumore dai bot che scansionano 51820, ma non è stealth. L'ispezione approfondita dei pacchetti identifica la stretta di mano distintiva di WireGuard su UDP indipendentemente dal numero di porta. Se hai bisogno di superare un firewall che blocca o rileva attivamente le VPN, hai bisogno di offuscamento (incapsulando il tunnel), non solo di una porta diversa - vedi WireGuard con port knocking / stealth. Per instradare traffico specifico o inoltrare servizi attraverso il tunnel, vedi port forwarding.

Nessun server, solo una rete che blocca? Se vuoi far passare il tuo portatile attraverso il Wi-Fi di un hotel, di un ufficio o di un campus che blocca WireGuard, un'app VPN con una modalità di offuscamento integrata fa l'incapsulamento per te: Proton VPN offre Stealth, un tunnel TLS offuscato disponibile su tutti i piani compreso quello gratuito, e NordVPN offre NordWhisper, che fa sembrare il traffico VPN normale traffico web e ora fa girare i suoi server offuscati (link di affiliazione). Contro una DPI di Stato, un server privato incapsulato con Xray REALITY regge meglio; la nostra guida anti-DPI confronta le due strade.

In sintesi

WireGuard usa UDP 51820 per impostazione predefinita - solo UDP, niente TCP. Per rendere un server self-hosted raggiungibile: apri la porta per UDP nel firewall, inoltrala sul router se il server è dietro uno (un VPS con un IP pubblico salta questo passaggio), e assicurati che ogni Endpoint del client corrisponda. Cambia la porta se vuoi per ridurre il rumore delle scansioni, ma consideralo un leggero indurimento, non un vero stealth.

Una volta scelta la porta, il nostro generatore di configurazione WireGuard gratuito crea una configurazione server e client coerente nel tuo browser, con ListenPort ed Endpoint gia allineati.

Quando nessuna impostazione di porta servira

Aprire la UDP 51820 serve solo se qualcosa può davvero raggiungere il tuo server. Dietro un CGNAT, o su un router che non controlli, non c'è alcuna porta da inoltrare né regola di firewall che lo risolva. Un VPS con il proprio IPv4 pubblico elimina la questione: la porta che apri è quella che vede internet. Un Cloud VPS 4 di Contabo a 5,50 €/mese ti dà root completo e un IP pubblico, e la guida passo passo Contabo + WireGuard copre il resto.

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.

Guide correlate

• MikroTik CVE-2026-14227: la tua chiave privata WireGuard è leggibile, e disattivare l'API non lo annulla

Su un telefono valgono gli stessi controlli di porta e firewall, ma i guasti si presentano in modo diverso e gli strumenti sono meno: vedete WireGuard su iPhone per i tre che spiegano quasi tutti i tunnel iOS rotti.