Welchen Port nutzt WireGuard? Standardport, Änderung & Weiterleitung (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.

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.

Ü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.