WireGuard Port: Standard, ändern und öffnen (2026)

Die Netzwerkkonfiguration von WireGuard ist erfrischend einfach - aber die eine Zahl, die viele verwirrt, ist der Port. Standardmäßig hört WireGuard auf UDP 51820, und fast jedes Problem mit "mein selbstgehostetes VPN verbindet sich nicht" liegt daran, dass dieser Port nicht offen ist, nicht weitergeleitet wird oder nicht mit der Client-Konfiguration übereinstimmt. Dieser Leitfaden behandelt den Standard, wie man ihn ändert und wie man ihn korrekt öffnet und weiterleitet.

WireGuard-Ports auf einen Blick

Die kurze Antwort: WireGuard verwendet standardmäßig UDP-Port 51820 - das ist sein Standard-Port, festgelegt durch die ListenPort-Zeile. Es gibt überhaupt keinen TCP-Modus. Die Ports, auf die es ankommt:

Der Endpoint = <public-ip>:<port> des Clients muss exakt denselben Port verwenden wie der ListenPort des Servers - diese Diskrepanz ist der mit Abstand häufigste Grund, warum sich ein selbstgehosteter WireGuard-Tunnel nicht verbindet.

Ihr VPN verbirgt Ihre IP. Nicht Ihren Browser.

Ein korrekt eingerichteter WireGuard-Tunnel ersetzt die Adresse, die eine Website 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.

Der Standard: UDP 51820

WireGuard hört konventionell auf UDP-Port 51820, festgelegt durch die ListenPort-Zeile im [Interface]-Abschnitt des Servers. Zwei Dinge sind hier wichtig:

• Es ist UDP, nicht TCP. WireGuard hat keinen TCP-Modus. Firewalls oder Netzwerke, die UDP blockieren, werden es vollständig stoppen.
• 51820 ist nur der Standard, keine Regel - Sie können jeden freien UDP-Port von 1 bis 65535 verwenden.

Clients erreichen den Server über die Zeile Endpoint = <public-ip>:51820 in ihrer eigenen Konfiguration. Dieser Port muss exakt mit dem ListenPort des Servers übereinstimmen.

Einen Port wählen: Ist 443/UDP sinnvoll?

Jeder freie UDP-Port von 1-65535 funktioniert, aber einige Optionen sind klüger als andere:

• Behalten Sie 51820 bei, wenn Ihr Netzwerk UDP nicht filtert - es ist der dokumentierte Standard und am einfachsten zu unterstützen.
• Verwenden Sie UDP 443, wenn Sie in einem restriktiven Netzwerk sind. Port 443 ist der HTTPS-Port, und moderner Webverkehr (HTTP/3 / QUIC) läuft bereits über UDP 443, sodass ein WireGuard-Tunnel dort in normal aussehenden verschlüsselten Verkehr übergeht und viele portbasierte Sperren umgeht. Es ist die nützlichste Portänderung. Beachten Sie, dass dies nur eine Port-Ebene-Tarnung ist - Deep Packet Inspection kann dennoch den Handshake erkennen (siehe den Abschnitt zur Tarnung unten).
• Vermeiden Sie Ports unter 1024, es sei denn, Sie haben einen Grund; sie sind "privilegiert" und erfordern Root-Rechte, ohne hier einen Vorteil zu bieten.

Den Port in der Firewall öffnen

Auf dem Server muss der Port für UDP erlaubt sein. Mit UFW:

sudo ufw allow 51820/udp
sudo ufw reload

Mit iptables ist es -A INPUT -p udp --dport 51820 -j ACCEPT. Dies ist die häufigste Ursache für einen Server, der "läuft", aber nie Verbindungen akzeptiert: Der WireGuard-Dienst ist aktiv, aber die Firewall lässt die Pakete stillschweigend fallen.

Den Port durch einen Router weiterleiten

Wo Ihr Server sich befindet, entscheidet, ob Sie auch Portweiterleitung benötigen:

• Auf einem VPS (ein gemieteter Server mit öffentlicher IP): keine Weiterleitung nötig - die Firewallregel reicht aus, da die öffentliche IP direkt auf die Maschine zeigt.
• Auf einem Heimserver hinter einem Router: Fügen Sie eine Portweiterleitungsregel im Router-Admin hinzu - leiten Sie UDP 51820 (extern) an die lokale IP des Servers auf UDP 51820 (intern) weiter. Ohne diese Regel erreichen Pakete aus dem Internet nie den Server.

Testen Sie von außerhalb Ihres Netzwerks (z.B. ein Telefon mit mobilen Daten, WLAN aus): Ein Client sollte server-public-ip:51820 erreichen. Wenn es in Ihrem LAN funktioniert, aber nicht von außen, fehlt die Weiterleitung.

Den Port ändern

Um einen anderen Port zu verwenden, setzen Sie ihn im [Interface] des Servers:

[Interface]
ListenPort = 51821

Starten Sie dann den Tunnel neu (systemctl restart wg-quick@wg0) und aktualisieren Sie alles, was den alten Port referenzierte:

1. die Firewallregel (den neuen UDP-Port erlauben),
2. die Routerweiterleitung (falls zutreffend),
3. die Endpoint-Zeile in jeder Client-Konfiguration.

Wenn Sie einen Punkt übersehen, werden sich die Clients nicht verbinden. Ein selbstgehosteter VPS macht all dies einfach, da Sie die Firewall und die öffentliche IP direkt kontrollieren. Wenn Sie die Konfiguration von Grund auf bearbeiten, liefern unsere gebrauchsfertigen WireGuard-Konfigurationsvorlagen ein korrektes [Interface]/[Peer]-Grundgerüst, in dem die Zeilen ListenPort und Endpoint bereits an der richtigen Stelle stehen.

Überprüfen, ob der Port tatsächlich lauscht

Bevor Sie den Client beschuldigen, bestätigen Sie, dass der Server wirklich auf dem Port lauscht, den Sie denken:

sudo wg show              # zeigt die Schnittstelle und ihren Lauschport
sudo ss -lunp | grep 51820   # ist etwas an UDP 51820 gebunden?

wg show listet den aktiven listening port; ss -lunp (beachten Sie das u für UDP) beweist, dass ein Prozess daran gebunden ist. Wenn wg show einen anderen Port als Ihre Konfiguration meldet, hat der Dienst nach Ihrer Bearbeitung nicht neu geladen - starten Sie ihn neu. Von einer anderen Maschine aus können Sie die Erreichbarkeit mit nc -uvz server-ip 51820 testen, obwohl UDP-Tests unzuverlässig sind, daher ist ein echter Client-Handshake der endgültige Test.

Mehr als einen Tunnel betreiben

Jede WireGuard-Schnittstelle benötigt ihren eigenen ListenPort. Wenn Sie beispielsweise wg0 für allgemeinen Verkehr und wg1 für eine separate Gruppe von Peers betreiben, geben Sie ihnen unterschiedliche Ports (z.B. 51820 und 51821), öffnen und leiten Sie beide weiter und richten Sie jeden Client auf den richtigen ein. Zwei Schnittstellen, die sich einen Port teilen, starten stillschweigend nicht.

Verbirgt das Ändern des Ports Ihr VPN?

Ein nicht standardmäßiger Port reduziert das Rauschen von Bots, die 51820 scannen, aber es ist keine Tarnung. Deep Packet Inspection erkennt den charakteristischen UDP-Handshake von WireGuard unabhängig von der Portnummer. Wenn Sie eine Firewall umgehen müssen, die aktiv VPNs blockiert oder erkennt, benötigen Sie Verschleierung (Einwickeln des Tunnels), nicht nur einen anderen Port - siehe WireGuard mit Port-Klopfen / Tarn-VPN. Für das Routing spezifischer Daten oder das Weiterleiten von Diensten durch den Tunnel siehe Portweiterleitung.

Fazit

WireGuard verwendet standardmäßig UDP 51820 - nur UDP, kein TCP. Um einen selbstgehosteten Server erreichbar zu machen: Öffnen Sie den Port für UDP in der Firewall, leiten Sie ihn auf dem Router weiter, wenn der Server hinter einem steht (ein VPS mit öffentlicher IP überspringt das), und stellen Sie sicher, dass jeder Client Endpoint übereinstimmt. Ändern Sie den Port, wenn Sie möchten, um weniger Scan-Rauschen zu haben, aber betrachten Sie es als leichte Härtung, nicht als echte Tarnung.

Sobald der Port feststeht, erstellt unser kostenloser WireGuard-Konfigurationsgenerator eine passende Server- und Client-Konfiguration in Ihrem Browser, mit bereits abgestimmtem ListenPort und Endpoint.

Wenn keine Port-Einstellung mehr hilft

UDP 51820 zu oeffnen nuetzt nur, wenn Ihren Server ueberhaupt jemand erreichen kann. Hinter einem Carrier-Grade-NAT oder an einem Router, den Sie nicht kontrollieren, gibt es keinen Port zum Weiterleiten und keine Firewall-Regel, die das behebt. Ein VPS mit eigener oeffentlicher IPv4 loest die Frage vollstaendig: Der Port, den Sie oeffnen, ist der Port, den das Internet sieht. Ein Contabo Cloud VPS 10 fuer 5,50 EUR/Monat gibt Ihnen vollen Root-Zugriff und eine oeffentliche IP; die Schritt-fuer-Schritt-Einrichtung Contabo + WireGuard deckt den Rest ab.

Weiterführende Artikel

• MikroTik CVE-2026-14227: Ihr privater WireGuard-Schlüssel ist lesbar, und das Abschalten der API macht das nicht rückgängig

Einen anderen Port zu wählen hilft nur, wenn der Anbieter ihn nicht selbst filtert. Unser Preisvergleich der günstigsten VPS für WireGuard zeigt, wer UDP unangetastet lässt.

Bleibt der Tunnel trotz korrekt geöffnetem Port ohne Handshake, liegt es meist am Netzwerk und nicht am Port: warum WireGuard je nach Netzwerk aus einem anderen Grund nicht funktioniert sortiert die Fälle nach Hotel-WLAN, mobilen Daten, FritzBox und Ausland.

Auf einem Telefon gelten dieselben Port- und Firewall-Prüfungen, aber die Fehler zeigen sich anders und es gibt weniger Werkzeuge: siehe WireGuard auf dem iPhone für die drei, die fast alle kaputten iOS-Tunnel erklären.