WireGuard „Handshake did not complete after 5 seconds“: 8 Ursachen

Du tippst wg show, du siehst deinen Peer, und direkt darunter steht die Zeile, die deinen Abend ruiniert: latest handshake ist leer, oder wg-quick warnt handshake did not complete. Dein Tunnel steht auf dem Papier, aber kein Verkehr fließt. Die gute Nachricht: WireGuard scheitert aus einer kurzen, endlichen Liste von Gründen, und sie treten in vorhersehbarer Reihenfolge auf. Dieser Leitfaden geht diese Reihenfolge vom häufigsten zum seltensten durch, damit du aufhörst zu raten und es in Minuten behebst.

WireGuard ist absichtlich stumm - es sendet nichts, solange keine Daten zu transportieren sind, und protokolliert nie ein freundliches „connection refused“. Diese Stille lässt einen fehlgeschlagenen Handshake mysteriös wirken. Fast immer ist es ein Problem der Netzwerk-Erreichbarkeit (Firewall, Port, NAT, Routing), keine Kryptografie. Arbeite die Liste von oben nach unten ab und du erwischst es.

Wenig Zeit? Zwei Ursachen erklären die meisten fehlgeschlagenen Handshakes: ein UDP-Port, der den Server nie erreicht (geschlossene Firewall, fehlende Weiterleitung oder CGNAT am Heimanschluss), und danach, sobald der Tunnel steht, eine zu hohe MTU. Der WireGuard-Port-Checker zeigt, ob Sie hinter CGNAT sitzen, und schreibt die Weiterleitungs- und Firewall-Regeln für Ihr System; der MTU-Rechner liefert den Wert, sobald der Handshake klappt.

Unsicher, was bei dir vorliegt? Unser kostenloser WireGuard-Port-Checker vergleicht die WAN-Adresse deines Routers mit deiner öffentlichen IP: In unter einer Minute siehst du, ob du hinter CGNAT sitzen (keine Portweiterleitung kann funktionieren) oder ob Weiterleitung plus Firewall-Regel reichen.

Hinter CGNAT? Dann kann keine Portweiterleitung und keine Firewall-Regel auf Ihrer Seite einen Weg zu einem Server zu Hause öffnen. Der übliche Ausweg ist, den WireGuard-Server auf einem VPS mit eigener öffentlicher IPv4 zu betreiben, etwa einem HostPapa Unmanaged VPS Lite (Affiliate-Link, 2,95 $ im Monat bei 3 Jahren Laufzeit, danach zum regulären Preis) oder einem Contabo Cloud VPS (Affiliate-Link), ab 5,50 € pro Monat bei 24 Monaten Laufzeit (Preis abgelesen am 17. Oktober 2026). Lieber ein US-Anbieter mit 30 Tagen Geld-zurück-Garantie? Ultahost VPS Basic kostet 5,52 $ im Monat bei 24 Monaten Laufzeit (1 GB RAM, dedizierte IPv4, gelesen am 21. Oktober 2026), genug für einen WireGuard-Server mit wenigen Geräten. Anbieter noch offen? Im Vergleich: bester VPS für ein VPN und Contabo vs Hetzner vs OVH, zum tatsächlich berechneten Preis. Der Lite-Tarif von HostPapa ist hier der kleinste: 1 Kern, 1 GB RAM, 25 GB NVMe und 4 TB Datenvolumen, nicht verwaltet (Root-Zugang per SSH unter Ubuntu oder Debian, kein Control Panel, WireGuard installieren Sie selbst), genug für einen WireGuard-Server mit wenigen Geräten, 30 Tage Geld-zurück-Garantie, Stand 28. Oktober 2026.

Noch keinen Server gewählt? Unser Preisvergleich der günstigsten VPS für WireGuard zeigt, was jeder Anbieter für einen brauchbaren Endpunkt wirklich berechnet.

Die exakte Logzeile: "Handshake for peer 1 did not complete after 5 seconds"

Wenn du die Fehlermeldung Wort für Wort gesucht hast, ist das die Meldung, die du vor dir hast. Das Linux-Kernelmodul gibt sie aus (sobald das Debug-Logging aktiv ist), und wireguard-go, die Userspace-Implementierung hinter den Apps für Windows, macOS und Android, gibt eine nahezu identische Version aus:

wireguard: wg0: Handshake for peer 1 (203.0.113.10:51820) did not complete after 5 seconds, retrying (try 2)
wireguard: wg0: Handshake for peer 1 (203.0.113.10:51820) did not complete after 20 attempts, giving up

So liest du sie:

• "after 5 seconds" ist keine Einstellung, die du anpassen kannst. Es ist das feste Retry-Timeout von WireGuard (REKEY_TIMEOUT, 5 s im Quellcode). Dein Peer hat eine Handshake-Initiierung gesendet und in diesem Zeitfenster keine gültige Antwort erhalten.
• "retrying (try 2)" bedeutet, dass er es weiter versucht. WireGuard sendet insgesamt etwa 90 Sekunden lang erneut.
• "did not complete after 20 attempts, giving up" ist das Ende dieser Schleife. Der Peer bleibt still, bis neuer Verkehr versucht, den Tunnel zu passieren, was eine neue Runde startet.
• Failed to send handshake initiation: no known endpoint for peer ist ein anderer Fall: Diese Seite hat kein Endpoint = für den Peer, kann also gar nicht initiieren und nur darauf warten, kontaktiert zu werden. Auf einem Server normal, auf einem Client ein Konfigurationsfehler.

Unter Linux protokolliert das Kernelmodul standardmäßig nichts. Um diese Zeilen zu sehen:

echo module wireguard +p | sudo tee /sys/kernel/debug/dynamic_debug/control
sudo dmesg -w | grep wireguard

Die Meldung beweist nur eines: Die Initiierung ging raus und nichts Gültiges kam zurück. Sie sagt nicht, warum. Die Ursachen unten, in dieser Reihenfolge, sind das Warum.

Lies zuerst den echten Zustand mit wg show

Bevor du etwas änderst, schau, was WireGuard dir bereits sagt. Auf beiden Seiten:

sudo wg show

Du liest drei Dinge:

• latest handshake - leer oder älter als ~2 Minuten = Tunnel down. Gesund = in den letzten 120 Sekunden.
• transfer - 0 B received heißt, deine Pakete kamen nie zurück. Gesendet-aber-nichts-empfangen ist die Signatur einer einseitigen Firewall oder NAT-Blockade.
• endpoint - auf dem Server sollte hier die aktuelle öffentliche IP:Port des Clients erscheinen, sobald ein Paket ankommt. Füllt sie sich nie, hat die Initiierung des Clients dich nicht erreicht.

Lass dieses Terminal offen. Führe nach jedem Fix unten erneut wg show aus und beobachte die Zeile latest handshake. Das ist deine einzige Wahrheit - nicht das Verbindungssymbol, nicht die App.

wg show latest-handshakes - die maschinenlesbare Form

Ein blankes wg show gibt ein menschenfreundliches latest handshake: 1 minute, 12 seconds ago aus. Gut zum Hinschauen, unbrauchbar für Skripte. Das wg(8)-Handbuch erlaubt, ein Attribut anzuhängen und die Ausgabe einzugrenzen:

show { <interface> | all | interfaces } [public-key | private-key | listen-port |
      fwmark | peers | preshared-keys | endpoints | allowed-ips |
      latest-handshakes | persistent-keepalive | transfer | dump]

Die Referenzform lautet also:

sudo wg show wg0 latest-handshakes

Sie gibt eine Zeile pro Peer aus: den Base64-Public-Key des Peers, einen Tabulator, dann den letzten Handshake in Sekunden seit der Unix-Epoche. Genau das tut das Werkzeug: In wireguard-tools steht in src/show.c printf("%s\t%llu\n", key(peer->public_key), peer->last_handshake_time.tv_sec);:

xTIBd0Kx3Hs9tPmVvQ4ZlLxYcE8nRr2A6WKsPqUvT1s=	1750684173
9QzrN7bLyF0mXaHcJdSoEuIgYkTvW3pB5nRfZ1AhQ0M=	0

Zwei Dinge zu dieser Zahl:

• 0 heißt, dieser Peer hat seit dem Hochfahren der Schnittstelle nie einen Handshake abgeschlossen. Kein veralteter Zeitstempel, sondern ein fehlender. Genau dieser Zustand wird auf dieser Seite behandelt.
• Es ist eine absolute Epochenzeit, kein Alter. Ziehe sie von date +%s ab, um die Sekunden seit dem letzten Handshake zu erhalten:

now=$(date +%s)
sudo wg show wg0 latest-handshakes | while read -r peer ts; do
  if [ "$ts" -eq 0 ]; then
    echo "$peer nie"
  else
    echo "$peer $((now - ts))s her"
  fi
done

Zwei Details, die beim Skripten beißen. wg show all latest-handshakes stellt den Schnittstellennamen als erste tabulatorgetrennte Spalte voran, dein read braucht also eine dritte Variable. Und wg show wg0 dump liefert denselben Zeitstempel zusammen mit Endpoint, AllowedIPs und den Transferzählern in einer tabulatorgetrennten Zeile pro Peer - das ist die Form, die man parst, wenn man einen echten Monitor baut statt eines Einzeilers.

Alles jenseits von ~180 Sekunden bei einem Peer, der aktiv sein sollte, bedeutet: Der Tunnel ist unten. Das ist die Alarmschwelle, und der Rest dieser Seite ist die geordnete Liste der Gründe.

Ursache 1 - Der UDP-Port ist blockiert (der Hauptverdächtige)

WireGuard spricht UDP auf einem einzigen Port - standardmäßig 51820. Ist dieser Port irgendwo auf dem Pfad gefiltert, stirbt das Initiierungspaket und du bekommst genau dein Symptom. Was dieser Standard bedeutet, wie du ihn änderst und korrekt öffnest, zeigt welchen Port WireGuard nutzt und wie du ihn öffnest. Meist sind zwei Firewalls zu prüfen, und man vergisst die erste:

Cloud-Provider-Firewall (die am häufigsten übersehene). Contabo, Hetzner, OVH, AWS - alle haben eine Netzwerk-Firewall oder Security Group vor deinem VPS. Eine Regel, die UDP 51820 von überall erlaubt, muss dort existieren, getrennt von der OS-Firewall. Bei den meisten Contabo-VPS-Images gibt es standardmäßig keine Provider-Firewall (gut), aber wenn du eine aktiviert hast, füge die UDP-Regel hinzu.

OS-Firewall auf dem Server. Prüfe und erlaube:

# ufw (Debian/Ubuntu)
sudo ufw allow 51820/udp
sudo ufw reload

# firewalld (Rocky/Alma/Fedora)
sudo firewall-cmd --add-port=51820/udp --permanent
sudo firewall-cmd --reload

Schneller Nachweis, dass der Port von außen erreichbar ist - von deinem Client-Rechner:

# sendet eine UDP-Sonde; "open|filtered" ohne Antwort ist nicht eindeutig,
# aber "open" oder ein zurückgegebenes Paket bestätigt die Erreichbarkeit
nc -u -z -v DEINE_SERVER_IP 51820

Sauberer Test: Führe sudo tcpdump -n -i eth0 udp port 51820 auf dem Server aus, dann verbinde vom Client. Siehst du eingehende Pakete, ist der Port offen und du gehst zur nächsten Ursache. Siehst du nichts, wird das Paket verworfen, bevor es WireGuard erreicht - bleib bei dieser Ursache.

Nichts kommt an und der Server läuft zu Hause? Prüfe auf CGNAT

Ist der „Server“ ein Raspberry Pi, ein NAS oder ein PC an deinem Heimanschluss, hat ein leeres tcpdump oft nichts mit deiner Firewall zu tun. Viele Provider (fast alle 4G/5G-Router, immer mehr Glasfaser- und Kabeltarife, oft als DS-Lite) setzen Kunden hinter CGNAT: Dein Router teilt sich eine öffentliche IPv4 mit anderen Kunden, also kann keine Portweiterleitung ein eingehendes UDP-Paket je zu deinem Gerät bringen. Vergleiche die WAN-Adresse im Router mit der Ausgabe von curl -4 ifconfig.me. Weichen sie ab oder zeigt der Router eine Adresse aus 100.64.0.0/10, sitzt du hinter CGNAT und der Handshake kann so nicht zustande kommen.

Es gibt drei Auswege: beim Provider eine öffentliche IPv4 anfragen (manche geben sie kostenlos, manche gegen Aufpreis, viele gar nicht), durchgehend IPv6 nutzen, wenn beide Seiten es haben, oder den WireGuard-Server auf einen kleinen VPS mit eigener öffentlicher IPv4 legen und das Heimgerät, falls du es weiter erreichen musst, als Client mit dem VPS verbinden. Die CGNAT-Anleitung zeigt den Reverse-Tunnel, und unser kostenloser WireGuard-Konfigurationsgenerator schreibt Server- und Client-Dateien mit passenden Schlüsseln.

Unsicher, ob eine Portweiterleitung an deinem Anschluss überhaupt funktionieren kann? Unser kostenloser WireGuard-Port-Checker vergleicht die WAN-Adresse deines Routers mit deiner öffentlichen IP, erkennt CGNAT, schreibt die Weiterleitungs- und Firewall-Regeln für dein Setup und liefert den tcpdump-Test, der beweist, dass Pakete den Server erreichen.

Zu Hause klappt es, im WLAN von Hotel, Büro oder Campus nicht?

Dann ist der Server in Ordnung und das Netz, in dem Sie gerade sind, verwirft UDP oder erkennt WireGuard und blockiert es. Der tcpdump-Test oben bleibt nur leer, solange Sie in diesem Netz sind. Betreiben Sie den Server selbst, legen Sie ListenPort (und den Endpoint des Clients) auf UDP 443, den Port, den HTTP/3 bereits nutzt und der die meisten portbasierten Filter passiert; unser WireGuard-Port-Ratgeber beschreibt die Umstellung. Brauchen Sie in diesem Netz nur ein funktionierendes VPN und betreiben keinen Server, verpackt eine VPN-App mit Verschleierungsmodus den Tunnel für Sie: Proton VPN bietet Stealth in jedem Tarif einschließlich Free, und NordVPN bietet NordWhisper, das VPN-Verkehr wie normalen Webverkehr aussehen lässt (Affiliate-Links). Gegen Deep Packet Inspection siehe den Anti-DPI-Ratgeber.

Bezahltarif, Black Friday 2026: Protons Partnerangebot, geprüft am 28. Oktober 2026, ist VPN Plus für 2,49 $/Monat über 2 Jahre (59,76 $ für die ersten 24 Monate, danach 83,88 $ pro Jahr), mit 30 Tagen Geld-zurück-Garantie und 10 Geräten. Die Bestellseite zeigt den Preis für Ihr Land, ein Enddatum nennt Proton nicht.

Ursache 2 - Falscher Endpoint auf dem Client

Der [Peer]-Block des Clients braucht die echte öffentliche IP des Servers (oder den DNS-Namen) und den exakten ListenPort:

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = 203.0.113.10:51820
AllowedIPs = 0.0.0.0/0

Häufige Fehler, die einen toten Handshake erzeugen:

• Der Endpoint zeigt auf die private LAN-IP des Servers (10.x / 192.168.x) statt auf die öffentliche.
• Ein Tippfehler im Port, oder der Server lauscht tatsächlich auf einem anderen ListenPort.
• Die öffentliche IP des Servers hat sich geändert (manche VPS-Neuinstallationen vergeben sie neu). Bestätige mit curl -4 ifconfig.co auf dem Server, dann vergleiche mit dem Endpoint des Clients.

Der Peer-Block auf dem Server hat keine Endpoint-Zeile (der Server lernt sie, wenn das Paket des Clients ankommt) - dort eine hinzuzufügen ist ein häufiger Copy-Paste-Fehler.

Ursache 3 - Falsche AllowedIPs

AllowedIPs ist eine kryptografische Routing-Tabelle, keine Erlaubnisliste, und ein Fehler bricht den Rückverkehr still:

• Auf dem Server muss AllowedIPs des Peers nur die Tunneladresse dieses Clients listen, z. B. 10.66.66.2/32. Teilen sich zwei Peers einen überlappenden Bereich, schickt der Server Antworten an den falschen und der Handshake „schließt ab“ und stirbt dann.
• Auf dem Client routet AllowedIPs = 0.0.0.0/0 alles durch den Tunnel (Voll-VPN). Für Split-Tunneling liste nur die Subnetze, die du wirklich routest - siehe unseren Split-Tunnel-Routing-Leitfaden.

Ein Handshake, der kurz gelingt und dann stockt, ist die klassische Signatur überlappender serverseitiger AllowedIPs. Mach den Bereich jedes Peers eindeutig.

Willst du dein LAN oder eine einzelne Adresse aus einem Volltunnel ausnehmen? AllowedIPs kennt keine "außer"-Syntax, deshalb rechnet unser kostenloser AllowedIPs-Rechner "alles außer X" in die kürzeste Liste von IPv4- und IPv6-Bereichen zum Einfügen um.

Ursache 4 - NAT-Timeout (läuft 2 Minuten, dann stirbt es)

Steht dein Client hinter NAT (Heim-Router, 4G/5G, Hotel-WLAN) und die Verbindung wird untätig, verwirft der Router das UDP-Mapping. Der Server hat dann keinen Rückweg zum Client und der Handshake läuft still ab. Der Fix liegt auf dem Peer hinter dem NAT:

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = 203.0.113.10:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

PersistentKeepalive = 25 sendet alle 25 Sekunden ein winziges Paket und hält das NAT-Mapping offen. 25 Sekunden liegen unter jedem üblichen NAT-Timeout. Füge es auf Roadwarrior-Clients und jedem Peer hinter einem restriktiven Router hinzu. Der serverseitige Peer braucht es meist nicht.

Ursache 5 - IP-Forwarding ist auf dem Server aus

Schließt der Handshake ab, aber du erreichst kein Internet durch den Tunnel, leitet der Server keine Pakete zwischen dem WireGuard-Interface und eth0 weiter. Aktiviere es:

echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system

Bestätige: sysctl net.ipv4.ip_forward muss 1 zurückgeben. Kombiniere es mit der Masquerade-Regel in deinem PostUp (die gebrauchsfertigen Konfigurationsvorlagen liefern diese Zeilen korrekt):

PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

Ursache 6 - Uhren-Abweichung

Der Handshake von WireGuard nutzt Zeitstempel, um Replay-Angriffe zu blockieren. Weicht die Server-Uhr um mehr als ein paar Minuten ab - häufig bei frischen VPS-Images oder pausierten VMs - werden Handshakes als veraltet abgelehnt. Korrigiere die Uhr:

sudo timedatectl set-ntp true
timedatectl status   # System clock synchronized: yes

Diese ist heimtückisch, weil alles andere perfekt aussieht. Hast du Port, Schlüssel und Routing dreifach geprüft und bekommst immer noch nichts, prüfe die Uhr, bevor du verzweifelst.

Ursache 7 - Schlüssel passen nicht zusammen (prüfe das zuletzt)

Man greift zuerst zu den Schlüsseln; prüfe sie zuletzt, denn ein Schlüsselfehler ist seltener als die sechs Ursachen oben und erzeugt dasselbe Symptom. Die Regel ist einfach:

• Die [Peer] PublicKey des Servers = der öffentliche Schlüssel, abgeleitet aus der PrivateKey des Clients.
• Die [Peer] PublicKey des Clients = der öffentliche Schlüssel, abgeleitet aus der PrivateKey des Servers.

Erzeuge und leite neu ab, um sicherzugehen:

# auf jeder Maschine den öffentlichen Schlüssel aus ihrem eigenen privaten ableiten
echo "PRIVATE_KEY_DIESES_HOSTS" | wg pubkey

Vergleiche diese Ausgabe mit der PublicKey, die die andere Seite für dich hat. Ein einziger vertauschter oder abgeschnittener Schlüssel bricht den Handshake komplett. Und ein PresharedKey (falls genutzt) muss auf beiden Peers identisch sein - eine Abweichung dort tötet den Handshake ebenfalls. Was der Preshared Key tatsächlich schützt und wie du ihn ohne Abbruch eines laufenden Tunnels ergänzt, steht im Leitfaden zum WireGuard Preshared Key.

Um die Schlüssel in einem Schritt auszuschließen, erzeugt der kostenlose WireGuard-Konfigurationsgenerator von VPNSmith im Browser für jede Seite ein neues Schlüsselpaar und trägt jeden öffentlichen Schlüssel in den [Peer]-Block der Gegenseite ein, samt identischem PresharedKey.

Ursache 8 - MTU bricht den Tunnel direkt nach dem Handshake

Streng genommen blockiert die MTU selten den Handshake (dessen Pakete sind klein). Aber sie zerstört regelmäßig Dinge, sobald echter Verkehr fließt: Handshake schließt ab, Ping funktioniert, dann hängen Webseiten ewig. Das ist Fragmentierung. Senke die Client-MTU:

[Interface]
MTU = 1380

Finde den richtigen Wert mit einem Do-not-fragment-Ping an die Tunnel-IP des Servers und verkleinere, bis er durchgeht:

ping -M do -s 1372 10.66.66.1

1420 passt für die meisten Glasfaser-Verbindungen; 1380 ist ein sicherer Standard; PPPoE und manche Mobilfunkanbieter brauchen 1280. Unser Leitfaden zu Konfigurationsvorlagen erklärt die MTU-Abstimmung je Verbindungstyp. Verbindet der Tunnel, hängt aber bei allem Großen, zeigt der eigene Leitfaden WireGuard-MTU reparieren, wie du den genauen Wert mit einem Do-not-fragment-Ping misst und je Verbindungstyp setzt.

Um den Wert zu berechnen statt zu raten, nimmt der kostenlose WireGuard-MTU-Rechner die größte Nutzlast, die dein Ping ohne Fragmentierung geschafft hat (oder einfach deinen Verbindungstyp), und schreibt die Zeile MTU = für deine Konfiguration.

Die 60-Sekunden-Diagnosereihenfolge

Wenn ein Handshake scheitert, führe genau diese Folge aus und stoppe beim ersten Fehler:

1. wg show auf beiden Seiten - gibt es irgendeinen latest handshake, irgendwelche received-Bytes?
2. tcpdump udp port 51820 auf dem Server, während der Client verbindet - kommen Pakete an?
3. Kommt kein Paket an → Firewall / Port / Endpoint (Ursachen 1-2).
4. Kommen Pakete an, aber keine Antwort zurück → serverseitige AllowedIPs, NAT, Rückroute (Ursachen 3-4).
5. Handshake schließt ab, aber kein Internet → ip_forward + Masquerade (Ursache 5).
6. Alles sieht richtig aus und trotzdem nichts → Uhren-Abweichung, dann Schlüssel, dann MTU (Ursachen 6-8).

Diese Reihenfolge folgt dem Weg des Pakets, von der Erreichbarkeit über das Routing bis zu den weniger offensichtlichen Ursachen - arbeite sie von oben nach unten ab und du verschwendest keine Zeit.

Diese Reihenfolge auf einer druckbaren Seite? Die Fehlersuche-Checkliste in unserem kostenpflichtigen WireGuard Self-Hosting Kit (9 USD, auf Englisch) erweitert sie auf 12 Ursachen, jeweils mit dem Befehl, der sie bestätigt, und der Lösung, dazu eine Tabelle zum Lesen der tcpdump-Ausgabe. Die Schritte oben bleiben für die 8 hier behandelten Ursachen kostenlos und vollständig.

Bau es von Anfang an richtig

Die meisten fehlgeschlagenen Handshakes entstehen aus einer Konfiguration, die aus drei widersprüchlichen Tutorials zusammengeflickt wurde. Von einer bekannt-guten Basis auf einem sauberen VPS zu starten entfernt die meisten Überraschungen. Ein Contabo Cloud VPS 4 für 5,50 €/Monat gibt dir eine öffentliche IPv4, vollen Root und keine Provider-Firewall zum Bekämpfen - genau die Bedingungen, unter denen WireGuard „einfach funktioniert“. Folge dem Schritt-für-Schritt-Setup Contabo + WireGuard und füge eine geprüfte Konfiguration aus dem Vorlagen-Leitfaden ein, und du startest mit Zeilen, die bekanntermaßen zusammenpassen.

Wer beide Seiten neu aufsetzen möchte: Der kostenlose WireGuard-Konfigurationsgenerator erzeugt die Schlüssel im Browser und schreibt passende Server- und Client-Konfigurationen, sodass öffentliche Schlüssel, AllowedIPs und Endpoint auf Anhieb zusammenpassen.

Ein VPN ändert Ihre IP. Nicht Ihren Browser.

Ein Tunnel ersetzt die Adresse, die ein Dienst sieht. An dem, was Ihr Browser von sich aus preisgibt, ändert er nichts - Schriften, Bildschirm, Zeitzone, Grafik-Stack. Diese Kombination reicht oft aus, um Sie über Sitzungen hinweg wiederzuerkennen.

Messen Sie Ihren Browser-Fingerabdruck - passiv, ohne Fragen, ohne Konto, ohne E-Mail-Adresse.

Weiterführend

• PersistentKeepalive: was die 25-Sekunden-Einstellung wirklich tut
• WireGuard-Multihop: zwei selbstgehostete Server verketten
• WireGuard hinter CGNAT: warum der Handshake nie ankommt
• WireGuard unter Windows: Schritt-für-Schritt einrichten
• WireGuard auf iPhone und iPad: die vollständige iOS-Einrichtung
• Eigenes VPN auf Contabo: vollständiger WireGuard-Leitfaden 2026
• Gebrauchsfertige WireGuard-Konfigurationsvorlagen 2026
• WireGuard-DNS-Lecks: erkennen, diagnostizieren, beseitigen
• WireGuard-Kill-Switch unter Linux: iptables + systemd
• Split-Tunnel-VPN mit Routing-Tabellen
• Glossar für selbstgehostete VPNs - AllowedIPs, MTU, NAT erklärt
• PiVPN im Jahr 2026: Der einfachste Weg, WireGuard oder OpenVPN selbst zu hosten

Quellen und Referenzen:

• WireGuard-Whitepaper - Jason A. Donenfeld
• WireGuard-Quickstart und wg-quick-Doku
• Manpages wg(8) und wg-quick(8)
• Arch Wiki - WireGuard-Fehlerbehebung

Veröffentlicht am 2026-06-23. Befehle geschrieben für Debian-12- und Ubuntu-24.04-Server auf Basis der offiziellen WireGuard-Dokumentation; wir haben keinen Prüfstand mit mehreren Clients. Deine Verbindungsbedingungen können abweichen - bestätige immer mit wg show und tcpdump, bevor du einen Fix als endgültig betrachtest.

Hinweis: WireGuard zu betreiben und ein VPN selbst zu hosten ist in der EU, den USA, Kanada legal. VPNSmith veröffentlicht diesen Inhalt zu Bildungszwecken.

Es lohnt sich auch zu prüfen, wo die Schlüssel liegen: Eine CISA-Meldung vom Juli 2026 betrifft eine RouterOS-Lücke, über die ein statischer privater WireGuard-Schlüssel direkt am Router lesbar ist. Siehe warum das Abschalten der API das nicht rückgängig macht.