Die meisten VPN-Probleme haben eine Handvoll Ursachen, und wer sie in der richtigen Reihenfolge prüft, spart sich einen Abend. Führen Sie die Befehle auf dem Server aus, sofern ein Schritt nichts anderes sagt. Die Beispiele verwenden WireGuard auf seinem Standardport 51820/udp; für OpenVPN oder Xray setzen Sie Ihren Dienstnamen und Port ein.
Zuletzt geprüft am 2026-11-13.
1. Läuft der Server auf einem Tarif mit eigener IPv4?
Ein VPN-Client verbindet sich zu Ihrem Server. Ein NAT-Tarif lässt von außen nur einen Port durch, Ihren persönlichen SSH-Port, daher kann dort kein VPN funktionieren. Zeigt das Dashboard eine Adresse mit einem Port wie 20xxx, sind Sie auf NAT. Der Wechsel auf eine eigene IPv4 behält Ihre Daten und erfordert keine Neuinstallation; siehe IP-Adresse ändern.
2. Läuft der Dienst?
systemctl status wg-quick@wg0
journalctl -u wg-quick@wg0 -n 30 --no-pager
Bei OpenVPN heißt die Unit meist openvpn-server@server, bei Xray xray. Ein Dienst, der nicht starten konnte, nennt den Grund fast immer in den letzten Zeilen seines Logs: ein Tippfehler in der Konfiguration, eine fehlende Schlüsseldatei, ein bereits belegter Port.
3. Lauscht er auf dem erwarteten Port?
ss -ulpn | grep 51820 # UDP: WireGuard, OpenVPN über UDP
ss -tlpn | grep 443 # TCP: Xray / VLESS, OpenVPN über TCP
Keine Ausgabe heißt: Der Dienst lauscht dort nicht, egal was in der Konfiguration steht. Vergleichen Sie den Port mit dem in Ihrem Client.
4. Lässt die Firewall ihn durch?
ufw status verbose
Ist die Firewall aktiv und Ihr Port nicht aufgeführt, öffnen Sie ihn:
ufw allow 51820/udp
Achten Sie auf das Protokoll: WireGuard braucht UDP, eine Regel für 51820/tcp nützt ihm nichts. Lassen Sie Ihre SSH-Regel stehen, bevor Sie die Firewall aktivieren oder neu laden, sonst sperren Sie sich selbst aus. Passiert es trotzdem, bringt Sie die Browser-Konsole im Dashboard wieder hinein.
5. Erreicht der Client den Server überhaupt?
Bei WireGuard verrät es der Handshake:
wg show
latest handshake: N seconds ago bei einem Peer bedeutet, dass der Client den Server erreicht hat und die Schlüssel passen. Fehlt die Handshake-Zeile ganz, ist er nie angekommen. Prüfen Sie dann in dieser Reihenfolge: Endpoint-IP und Port in der Client-Konfiguration, die Firewall aus Schritt 4 und ob der öffentliche Schlüssel des Clients im [Peer]-Block des Servers steht (und umgekehrt).
6. Verbunden, aber nichts öffnet sich?
Der Tunnel funktioniert, aber der Server leitet den Verkehr nicht ins Internet weiter. Prüfen Sie die Weiterleitung:
sysctl net.ipv4.ip_forward
Die Ausgabe muss 1 sein. Falls nicht, aktivieren Sie sie dauerhaft:
echo 'net.ipv4.ip_forward=1' > /etc/sysctl.d/99-vpn.conf
sysctl --system
Prüfen Sie dann die NAT-Regel. In einer WireGuard-Konfiguration ist das die PostUp-Zeile mit MASQUERADE, und der Schnittstellenname darin muss der echte Ihres Servers sein:
ip -br addr
Steht in der Zeile -o eth0, Ihre Schnittstelle heißt aber anders, korrigieren Sie die Konfiguration und starten Sie den Dienst neu.
7. Aus einem anderen Netz testen
Verbinden Sie sich über mobile Daten statt über das WLAN zu Hause, oder bitten Sie jemanden in einem anderen Land, es zu versuchen. Funktioniert das VPN dort, aber nicht aus Ihrem üblichen Netz, ist der Server in Ordnung, und etwas dazwischen blockiert die Verbindung.
- Ob Ihr Server aus einem bestimmten Land überhaupt erreichbar ist: So prüfen Sie, ob die IP Ihres VPS aus Russland und dem Iran erreichbar ist.
- Wo WireGuard und OpenVPN erkannt und gesperrt werden, sieht VLESS + Reality wie gewöhnliches HTTPS aus und ist viel schwerer zu blockieren.
8. Immer noch nicht?
Eröffnen Sie ein Ticket und schreiben Sie dazu, was Sie geprüft haben: die Ausgabe der Schritte 2–5 und den Namen Ihres VPN-Clients. Damit können wir meist schon in der ersten Antwort sagen, wo es hakt.
Kommentare
Noch keine Kommentare. Sei der Erste.