Most VPN problems come down to a handful of causes, and checking them in the right order saves an evening. Run the commands on the server unless a step says otherwise. The examples use WireGuard on its default port 51820/udp; for OpenVPN or Xray, substitute your service name and port.
Last verified 2026-11-13.
1. Is the server on a plan with its own IPv4?
A VPN client connects in to your server. A NAT plan lets only one port in from outside, your personal SSH port, so no VPN can work on it. If the dashboard shows an address with a port like 20xxx, you're on NAT. Switching to your own IPv4 keeps your data and doesn't require a reinstall; see Changing your IP address.
2. Is the service running?
systemctl status wg-quick@wg0
journalctl -u wg-quick@wg0 -n 30 --no-pager
For OpenVPN the unit is usually openvpn-server@server; for Xray, xray. A service that failed to start almost always names the reason in the last lines of its log: a typo in the config, a missing key file, a port already in use.
3. Is it listening on the port you expect?
ss -ulpn | grep 51820 # UDP: WireGuard, OpenVPN over UDP
ss -tlpn | grep 443 # TCP: Xray / VLESS, OpenVPN over TCP
No output means the service isn't listening there, whatever the config says. Compare the port with the one in your client.
4. Does the firewall let it in?
ufw status verbose
If the firewall is active and your port isn't listed, open it:
ufw allow 51820/udp
Pay attention to the protocol: WireGuard needs UDP, and a 51820/tcp rule does nothing for it. Leave your SSH rule in place before you enable or reload the firewall, or you'll lock yourself out. If that happens anyway, the browser console in the dashboard gets you back in.
5. Does the client actually reach the server?
For WireGuard, the handshake tells you:
wg show
latest handshake: N seconds ago for a peer means the client reached the server and the keys match. No handshake line at all means it never did. Then check, in this order: the endpoint IP and port in the client config, the firewall from step 4, and whether the client's public key is in the server's [Peer] block (and the other way round).
6. Connected, but nothing opens?
The tunnel works, but the server doesn't pass traffic out to the internet. Check forwarding:
sysctl net.ipv4.ip_forward
It must print 1. If it doesn't, enable it permanently:
echo 'net.ipv4.ip_forward=1' > /etc/sysctl.d/99-vpn.conf
sysctl --system
Then check the NAT rule. In a WireGuard config it is the PostUp line with MASQUERADE, and the interface name in it must be your server's real one:
ip -br addr
If the line says -o eth0 but your interface is called something else, fix the config and restart the service.
7. Test from another network
Connect from mobile data instead of home Wi-Fi, or ask someone in another country to try. If the VPN works there but not from your usual network, the server is fine and something in between is blocking the connection.
- To see whether your server is reachable from a particular country at all: How to check if your VPS IP is reachable from Russia and Iran.
- Where WireGuard and OpenVPN get recognised and blocked, VLESS + Reality looks like ordinary HTTPS and is much harder to block.
8. Still stuck?
Open a ticket and include what you checked: the output of steps 2–5 and the name of your VPN client. With that we can usually tell where it breaks in one reply.
Comments
No comments yet. Be the first.