Gameserver-Ports richtig freigeben

Wenn ein selbst gehosteter Gameserver im Heimnetz funktioniert, aber Freunde von außen nicht verbinden können, landet die Fehlersuche schnell bei „Ports freigeben“. Dabei gibt es mindestens zwei getrennte Hürden: die Firewall auf dem Server und – bei klassischem IPv4-NAT – die Weiterleitung im Router. Hinzu kommen Provider-NAT, DS-Lite und Spiele, die Relay- oder Peer-to-Peer-Technik nutzen und gar keine klassische manuelle Portweiterleitung voraussetzen.

Dieser Guide erklärt deshalb nicht einfach „TCP/UDP aufmachen“, sondern zeigt, welche Freigabe an welcher Stelle überhaupt nötig ist. Die konkreten Portnummern bleiben in den aktuellen spielspezifischen Server-Guides, weil sie sich je Spiel und Version unterscheiden können.

Datenstand: 5. September 2026.

Erst prüfen, ob euer Spiel überhaupt Portforwarding braucht

Öffnet keine Ports nur deshalb, weil ein alter Guide eine Liste nennt. Manche Spiele verwenden klassische direkt erreichbare Dedicated Server, andere vermitteln Verbindungen über Plattformdienste oder Relay-Netze. Valve beschreibt Steam Datagram Relay ausdrücklich als Relay-Infrastruktur für Peer-to-Peer- und Dedicated-Server-Verkehr; Teilnehmer müssen dabei nicht zwingend direkt über ihre öffentliche IP angesprochen werden.

Prüft deshalb zuerst die aktuelle Entwicklerdokumentation des Spiels:

1. Unterstützt das Spiel einen selbst gehosteten Dedicated Server?
2. Welche Ports und Protokolle nennt die aktuelle Serverdokumentation?
3. Werden Spiel-, Query-, RCON- oder Webinterface-Ports getrennt aufgeführt?
4. Ist direkte Erreichbarkeit aus dem Internet erforderlich oder übernimmt ein Plattform-/Relay-Dienst die Vermittlung?

Nur die dort bestätigten Freigaben gehören in eure Firewall und gegebenenfalls in den Router.

TCP und UDP sind nicht austauschbar

Eine Portnummer allein reicht nicht. TCP und UDP sind unterschiedliche Transportprotokolle; eine Regel für TCP öffnet nicht automatisch denselben UDP-Port. Microsoft verlangt bei einer Windows-Portregel ausdrücklich die Auswahl des Protokolls, siehe Microsoft Learn zur Windows-Firewall. Deshalb ist „TCP/UDP“ als pauschale Empfehlung nur dann korrekt, wenn die aktuelle Spieldokumentation tatsächlich beide Protokolle nennt.

Facepunch dokumentiert in der offiziellen Rust-Server-Dokumentation zum Beispiel unterschiedliche Aufgaben und Protokolle: Spiel- und Query-Port verwenden UDP, RCON verwendet TCP. Das ist ein gutes Beispiel dafür, warum ihr nicht einfach alle genannten Nummern für beide Protokolle freigeben solltet.

Die vier Ebenen einer Gameserver-Verbindung

Diese Reihenfolge spart Zeit: Wenn der Server bereits lokal oder im LAN nicht funktioniert, ist der Router beziehungsweise der Provider noch nicht die erste Fehlerquelle.

Windows-Firewall gezielt statt pauschal öffnen

Microsoft Learn beschreibt benutzerdefinierte Firewallregeln, die unter anderem Programm, Protokoll, lokalen Port, IP-Bereich und Netzwerkprofil kombinieren können. Für einen Gameserver bedeutet das: Öffnet nur das, was der Server tatsächlich benötigt.

1. Öffnet Windows-Firewall mit erweiterter Sicherheit.
2. Wählt Eingehende Regeln und Neue Regel.
3. Nutzt für maximale Kontrolle den Regeltyp Benutzerdefiniert.
4. Beschränkt die Regel nach Möglichkeit auf die konkrete Server-Anwendung.
5. Wählt das bestätigte Protokoll TCP oder UDP und den lokalen Port beziehungsweise Portbereich.
6. Beschränkt bei Bedarf den Bereich auf bekannte Remote-Adressen.
7. Aktiviert nur die Netzwerkprofile, für die der Server erreichbar sein soll.
8. Gebt der Regel einen eindeutigen Namen mit Spiel und Zweck.

Microsoft weist in seinen Hinweisen zu Firewall-Freigaben außerdem darauf hin, dass eine App-Freigabe im Allgemeinen weniger riskant ist als ein dauerhaft offener Port. Bei einem Dedicated Server kann eine kombinierte Programm-und-Port-Regel die Freigabe weiter einschränken.

Portweiterleitung im Router einrichten

Im typischen Heimnetz besitzt der Server-PC eine private LAN-Adresse. Soll ein klassisch erreichbarer IPv4-Gameserver aus dem Internet erreichbar sein, muss der Router eingehenden Verkehr für den bestätigten Port an genau dieses Gerät weiterleiten.

Bei einer FRITZ!Box findet ihr die Funktion laut FRITZ!-Anleitung zu statischen Portfreigaben unter Internet → Freigaben → Portfreigaben. Andere Router verwenden Bezeichnungen wie Port Forwarding, NAT-Regeln oder virtuelle Server.

1. Sorgt dafür, dass der Server-PC im Heimnetz dauerhaft dieselbe lokale Adresse erhält. FRITZ! dokumentiert dafür die Option, einem Gerät immer dieselbe IPv4-Adresse per DHCP zuzuweisen.
2. Wählt als Ziel genau diesen Server-PC.
3. Tragt externen und internen Port entsprechend der Spieldokumentation ein.
4. Wählt ausschließlich das benötigte Protokoll.
5. Speichert die Regel und prüft, ob sie auf das richtige Gerät zeigt.

FRITZ! weist in der Portfreigabe-Dokumentation darauf hin, dass eine von außen erreichbare IP-Konfiguration Voraussetzung für den Zugriff ist. Ob eine klassische IPv4-Weiterleitung funktioniert, hängt also auch vom Internetanschluss ab.

Erwartetes Ergebnis: Ein externer Verbindungsversuch für genau den freigegebenen Dienst erreicht den Server-PC. Falls der LAN-Test funktioniert, der externe Test aber weiterhin scheitert, prüft anschließend öffentliche IPv4, CGNAT beziehungsweise DS-Lite.

Exposed Host und „DMZ“ nicht als Abkürzung verwenden

Wenn eine einzelne Portregel nicht funktioniert, ist es keine gute Fehlersuche, den Server-PC pauschal als Exposed Host einzutragen. FRITZ! erklärt in der Dokumentation zum Exposed Host, dass dabei alle nicht anderweitig zugeordneten eingehenden IPv4-Anfragen an dieses Gerät weitergeleitet werden und es nicht mehr durch die FRITZ!Box-Firewall geschützt wird.

Für einen privaten Gameserver gilt deshalb: gezielte Freigabe vor Exposed Host. Entfernt alte Regeln, die ihr nicht mehr benötigt, und gebt Verwaltungsdienste wie RCON oder Webinterfaces nicht unnötig für das gesamte Internet frei.

Warum ein Portchecker bei UDP leicht falsch interpretiert wird

Ein Porttest ist nur dann aussagekräftig, wenn er dasselbe Transportprotokoll prüft, das euer Gameserver verwendet. Ein erfolgreicher oder fehlgeschlagener TCP-Verbindungsaufbau sagt nichts darüber aus, ob derselbe numerische Port für UDP korrekt erreichbar ist.

Prüft deshalb vor der Nutzung eines externen Portcheckers ausdrücklich, welches Protokoll der Dienst testet. Für UDP-Gameserver ist ein echter externer Verbindungsversuch über den vorgesehenen Spielclient beziehungsweise die vom Entwickler dokumentierte Serverabfrage oft die passendere Kontrolle – und zwar von einem Gerät außerhalb eures Heimnetzes.

So testet ihr ohne Chaos

1. Lokal: Läuft der Server und akzeptiert er eine lokale Verbindung?
2. LAN: Kann ein zweites Gerät im Heimnetz verbinden? Falls nein, Host-Firewall und Bind-Adresse prüfen.
3. WAN: Erst jetzt Portweiterleitung und öffentliche Erreichbarkeit testen.
4. Provider: Wenn LAN funktioniert und die Routerregel stimmt, öffentliche IPv4, CGNAT oder DS-Lite prüfen.
5. Logs: Prüfen, ob beim externen Verbindungsversuch überhaupt Pakete beziehungsweise Verbindungsversuche am Server ankommen.

Ändert immer nur eine Ebene gleichzeitig. Mehrere neue Firewall- und Routerregeln auf einmal erschweren die Ursachenanalyse.

Spielspezifische Portangaben bleiben separat

Die allgemeine Netzwerktechnik ist wiederverwendbar; die Portnummern sind es nicht. Für konkrete Werte nutzt ihr die jeweilige Spielseite, zum Beispiel Satisfactory Server-Ports und Einstellungen, ETS2 server_config.sii: Einstellungen und Ports oder Palworld Server-Einstellungen und Ports.

Quellen

• Microsoft Learn – Firewallregeln konfigurieren.
• Microsoft Support – Risiken von Firewall-Freigaben.
• FRITZ! – Statische Portfreigaben.
• FRITZ! – Gerät immer dieselbe lokale IPv4 zuweisen.
• FRITZ! – DS-Lite und PCP.
• FRITZ! – Exposed Host.
• Valve Steamworks – Steam Datagram Relay.
• Facepunch – Rust Server-Dokumentation.