De fleste VPN-problemer skyldes en håndfuld årsager, og tjekker du dem i den rigtige rækkefølge, sparer du en aften. Kør kommandoerne på serveren, medmindre et trin siger noget andet. Eksemplerne bruger WireGuard på standardporten 51820/udp; til OpenVPN eller Xray skifter du til dit eget tjenestenavn og din port.
Sidst kontrolleret 2026-11-13.
1. Er serveren på en pakke med egen IPv4?
En VPN-klient forbinder til din server udefra. En NAT-pakke lukker kun én port ind udefra, din personlige SSH-port, så ingen VPN kan virke på den. Viser kontrolpanelet en adresse med en port som 20xxx, er du på NAT. At skifte til egen IPv4 bevarer dine data og kræver ingen geninstallation; se Skift af IP-adresse.
2. Kører tjenesten?
systemctl status wg-quick@wg0
journalctl -u wg-quick@wg0 -n 30 --no-pager
For OpenVPN hedder enheden som regel openvpn-server@server, for Xray xray. En tjeneste, der ikke startede, angiver næsten altid årsagen i de sidste linjer af sin log: en tastefejl i konfigurationen, en manglende nøglefil, en port, der allerede er i brug.
3. Lytter den på den port, du forventer?
ss -ulpn | grep 51820 # UDP: WireGuard, OpenVPN over UDP
ss -tlpn | grep 443 # TCP: Xray / VLESS, OpenVPN over TCP
Intet output betyder, at tjenesten ikke lytter der, uanset hvad konfigurationen siger. Sammenlign porten med den i din klient.
4. Lukker firewallen den ind?
ufw status verbose
Hvis firewallen er aktiv, og din port ikke står på listen, så åbn den:
ufw allow 51820/udp
Læg mærke til protokollen: WireGuard skal bruge UDP, og en regel for 51820/tcp gør intet for den. Lad din SSH-regel blive stående, før du aktiverer eller genindlæser firewallen, ellers lukker du dig selv ude. Sker det alligevel, får browserkonsollen i kontrolpanelet dig ind igen.
5. Når klienten overhovedet frem til serveren?
For WireGuard er det handshaken, der fortæller det:
wg show
latest handshake: N seconds ago for en peer betyder, at klienten nåede serveren, og at nøglerne passer. Ingen handshake-linje overhovedet betyder, at den aldrig nåede frem. Tjek så i denne rækkefølge: endpoint-IP og port i klientkonfigurationen, firewallen fra trin 4, og om klientens offentlige nøgle står i serverens [Peer]-blok (og omvendt).
6. Forbundet, men intet åbner?
Tunnelen virker, men serveren sender ikke trafikken ud på internettet. Tjek videresendelsen:
sysctl net.ipv4.ip_forward
Den skal vise 1. Hvis ikke, så slå den permanent til:
echo 'net.ipv4.ip_forward=1' > /etc/sysctl.d/99-vpn.conf
sysctl --system
Tjek derefter NAT-reglen. I en WireGuard-konfiguration er det PostUp-linjen med MASQUERADE, og interfacenavnet i den skal være serverens rigtige:
ip -br addr
Hvis linjen siger -o eth0, men dit interface hedder noget andet, så ret konfigurationen og genstart tjenesten.
7. Test fra et andet netværk
Forbind via mobildata i stedet for wifi derhjemme, eller bed nogen i et andet land om at prøve. Virker VPN'en der, men ikke fra dit sædvanlige netværk, er serveren i orden, og noget imellem blokerer forbindelsen.
- For at se, om din server overhovedet kan nås fra et bestemt land: Sådan tjekker du, om din VPS' IP kan nås fra Rusland og Iran.
- Hvor WireGuard og OpenVPN bliver genkendt og blokeret, ligner VLESS + Reality almindelig HTTPS og er langt sværere at blokere.
8. Stadig problemer?
Opret en ticket, og skriv, hvad du har tjekket: outputtet fra trin 2–5 og navnet på din VPN-klient. Med det kan vi som regel sige, hvor det går galt, allerede i første svar.
Kommentarer
Ingen kommentarer endnu. Vær den første.