De flesta VPN-problem beror på en handfull orsaker, och kontrollerar du dem i rätt ordning sparar du en kväll. Kör kommandona på servern om inte ett steg säger något annat. Exemplen använder WireGuard på standardporten 51820/udp; för OpenVPN eller Xray byter du till ditt eget tjänstenamn och din port.
Senast kontrollerad 2026-11-13.
1. Ligger servern på ett paket med egen IPv4?
En VPN-klient ansluter till din server utifrån. Ett NAT-paket släpper bara in en port utifrån, din personliga SSH-port, så inget VPN kan fungera där. Om kontrollpanelen visar en adress med en port som 20xxx har du NAT. Att byta till en egen IPv4 behåller dina data och kräver ingen ominstallation; se Byta IP-adress.
2. Körs tjänsten?
systemctl status wg-quick@wg0
journalctl -u wg-quick@wg0 -n 30 --no-pager
För OpenVPN heter enheten oftast openvpn-server@server, för Xray xray. En tjänst som inte startade anger nästan alltid orsaken i de sista raderna av sin logg: ett stavfel i konfigurationen, en saknad nyckelfil, en port som redan används.
3. Lyssnar den på porten du förväntar dig?
ss -ulpn | grep 51820 # UDP: WireGuard, OpenVPN över UDP
ss -tlpn | grep 443 # TCP: Xray / VLESS, OpenVPN över TCP
Ingen utdata betyder att tjänsten inte lyssnar där, vad konfigurationen än säger. Jämför porten med den i din klient.
4. Släpper brandväggen in den?
ufw status verbose
Om brandväggen är aktiv och din port inte finns i listan, öppna den:
ufw allow 51820/udp
Tänk på protokollet: WireGuard behöver UDP, och en regel för 51820/tcp gör ingenting för den. Låt din SSH-regel ligga kvar innan du aktiverar eller laddar om brandväggen, annars stänger du ute dig själv. Händer det ändå tar webbläsarkonsolen i kontrollpanelen dig in igen.
5. Når klienten verkligen servern?
För WireGuard är det handshake som avslöjar det:
wg show
latest handshake: N seconds ago för en peer betyder att klienten har nått servern och att nycklarna stämmer. Ingen handshake-rad alls betyder att den aldrig kom fram. Kontrollera då i den här ordningen: endpoint-IP och port i klientkonfigurationen, brandväggen från steg 4 och om klientens publika nyckel finns i serverns [Peer]-block (och tvärtom).
6. Ansluten, men inget öppnas?
Tunneln fungerar, men servern skickar inte ut trafiken på internet. Kontrollera vidarebefordran:
sysctl net.ipv4.ip_forward
Det måste stå 1. Om inte, slå på det permanent:
echo 'net.ipv4.ip_forward=1' > /etc/sysctl.d/99-vpn.conf
sysctl --system
Kontrollera sedan NAT-regeln. I en WireGuard-konfiguration är det PostUp-raden med MASQUERADE, och gränssnittsnamnet i den måste vara serverns riktiga:
ip -br addr
Om raden säger -o eth0 men ditt gränssnitt heter något annat, rätta konfigurationen och starta om tjänsten.
7. Testa från ett annat nät
Anslut via mobildata i stället för wifi hemma, eller be någon i ett annat land att prova. Om VPN:et fungerar där men inte från ditt vanliga nät är servern i ordning, och något däremellan blockerar anslutningen.
- För att se om din server alls nås från ett visst land: Så kontrollerar du om din VPS IP-adress går att nå från Ryssland och Iran.
- Där WireGuard och OpenVPN känns igen och blockeras ser VLESS + Reality ut som vanlig HTTPS och är mycket svårare att blockera.
8. Fortfarande fast?
Öppna ett ärende och skriv vad du har kontrollerat: utdata från steg 2–5 och namnet på din VPN-klient. Med det kan vi oftast säga var det fallerar redan i första svaret.
Kommentarer
Inga kommentarer än. Bli först.