Quale Porta Usa WireGuard? Porta Predefinita, Modifica e Inoltro (2026)

La rete di WireGuard è sorprendentemente semplice — ma il numero che spesso confonde le persone è la porta. Di default, WireGuard ascolta su UDP 51820, e quasi ogni problema di "la mia VPN self-hosted non si connette" si riduce a quella porta che non è aperta, non è inoltrata o non corrisponde alla configurazione del client. Questa guida copre il valore predefinito, come cambiarlo e come aprirlo e inoltrarlo correttamente.

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.

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.

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.