La maggior parte dei problemi con una VPN si riduce a poche cause, e controllarle nell'ordine giusto ti fa risparmiare una serata. Esegui i comandi sul server, salvo dove un passo dice diversamente. Gli esempi usano WireGuard sulla porta predefinita 51820/udp; per OpenVPN o Xray sostituisci il nome del tuo servizio e la tua porta.
Ultima verifica il 2026-11-13.
1. Il server è su un piano con IPv4 dedicato?
Un client VPN si connette verso il tuo server. Un piano NAT lascia entrare dall'esterno una sola porta, la tua porta SSH personale, quindi nessuna VPN può funzionarci. Se la dashboard mostra un indirizzo con una porta tipo 20xxx, sei su NAT. Passare a un IPv4 dedicato mantiene i tuoi dati e non richiede reinstallazione; vedi Cambiare indirizzo IP.
2. Il servizio è in esecuzione?
systemctl status wg-quick@wg0
journalctl -u wg-quick@wg0 -n 30 --no-pager
Per OpenVPN l'unità di solito è openvpn-server@server; per Xray, xray. Un servizio che non è partito indica quasi sempre il motivo nelle ultime righe del log: un refuso nella configurazione, un file di chiave mancante, una porta già in uso.
3. È in ascolto sulla porta che ti aspetti?
ss -ulpn | grep 51820 # UDP: WireGuard, OpenVPN su UDP
ss -tlpn | grep 443 # TCP: Xray / VLESS, OpenVPN su TCP
Nessun output significa che il servizio non è in ascolto lì, qualunque cosa dica la configurazione. Confronta la porta con quella del tuo client.
4. Il firewall lo lascia passare?
ufw status verbose
Se il firewall è attivo e la tua porta non è elencata, aprila:
ufw allow 51820/udp
Fai attenzione al protocollo: WireGuard ha bisogno di UDP, e una regola 51820/tcp non gli serve a nulla. Lascia al suo posto la regola per SSH prima di attivare o ricaricare il firewall, altrimenti resterai chiuso fuori. Se succede comunque, la console nel browser della dashboard ti fa rientrare.
5. Il client raggiunge davvero il server?
Per WireGuard te lo dice l'handshake:
wg show
latest handshake: N seconds ago su un peer significa che il client ha raggiunto il server e le chiavi corrispondono. Nessuna riga di handshake significa che non ci è mai arrivato. Allora controlla, in quest'ordine: IP e porta dell'endpoint nella configurazione del client, il firewall del passo 4 e se la chiave pubblica del client è nel blocco [Peer] del server (e viceversa).
6. Connesso, ma non si apre niente?
Il tunnel funziona, ma il server non fa uscire il traffico verso internet. Controlla l'inoltro:
sysctl net.ipv4.ip_forward
Deve stampare 1. Altrimenti attivalo in modo permanente:
echo 'net.ipv4.ip_forward=1' > /etc/sysctl.d/99-vpn.conf
sysctl --system
Poi controlla la regola NAT. In una configurazione WireGuard è la riga PostUp con MASQUERADE, e il nome dell'interfaccia al suo interno deve essere quello reale del tuo server:
ip -br addr
Se la riga dice -o eth0 ma la tua interfaccia si chiama in un altro modo, correggi la configurazione e riavvia il servizio.
7. Prova da un'altra rete
Connettiti con la rete mobile invece del Wi-Fi di casa, oppure chiedi a qualcuno in un altro paese di provare. Se lì la VPN funziona ma dalla tua rete abituale no, il server è a posto e qualcosa nel mezzo blocca la connessione.
- Per vedere se il tuo server è raggiungibile da un certo paese: Come verificare se l'IP del tuo VPS è raggiungibile dalla Russia e dall'Iran.
- Dove WireGuard e OpenVPN vengono riconosciuti e bloccati, VLESS + Reality sembra normale HTTPS ed è molto più difficile da bloccare.
8. Ancora niente?
Apri un ticket e indica cosa hai controllato: l'output dei passi 2–5 e il nome del tuo client VPN. Con queste informazioni di solito riusciamo a dirti dove si blocca già alla prima risposta.
Commenti
Ancora nessun commento. Sii il primo.