Ein Gameserver-Endpunkt besteht aus einer Zieladresse, einem Transportprotokoll und einem Port. 27100/TCP und 27100/UDP sind verschiedene Verbindungen, auch wenn die Zahl gleich ist. Darum reicht eine Portnummer allein nicht. Prüfe in der aktuellen Dokumentation deines Spiels, welche Rolle jeder Eintrag hat: Spielbeitritt, Serverabfrage oder Fernadministration. Ein erfolgreicher TCP-Test bestätigt nur den TCP-Weg; er beweist nicht, dass UDP-Spielverkehr funktioniert.
TCP baut vor dem Datenaustausch eine Verbindung auf. UDP versendet einzelne Datagramme und bietet selbst keinen TCP-Handshake. Eine allgemeine Portliste oder ein Status-Check kann deshalb die Antwort des eigentlichen Spiels nicht ersetzen. Die IANA-Registrierung ordnet Namen und Ports einem Transport zu; sie bestätigt weder, dass ein bestimmtes Spiel den Port nutzt, noch dass ein Server dort erreichbar ist.
Spiel, Query und RCON auseinanderhalten
Lies zuerst die Herstellerdokumentation für das konkrete Spiel und die eingesetzte Serverversion. Notiere nicht nur «Port offen», sondern Spiel, Rolle, Protokoll, Port und getestete Zieladresse. Prüfe für jeden Eintrag:
- Spielport: Der Spieleclient verbindet sich hierüber mit der laufenden Partie.
- Query-Port: Ein Serverbrowser oder Abfragewerkzeug fragt damit Statusdaten ab. Eine sichtbare Serverliste beweist nicht, dass der Spielbeitritt über seinen eigenen Port gelingt.
- RCON-Port: Ein Administrationswerkzeug steuert damit den Server. RCON ist kein Spielerzugang. Aktiviere den Zugang nur, wenn du ihn brauchst, und begrenze ihn auf den dokumentierten, vertrauenswürdigen Verwaltungsweg.
Auch Protokoll und Port können je Dienst abweichen. Die aktuelle Conan-Exiles-Dokumentation führt beispielsweise den Spielport 7777/UDP, den Query-Port 27015/UDP für PC sowie RCON 25575/TCP auf allen Plattformen getrennt auf. Das ist ein Beispiel für genau dieses Spiel, kein Portplan für andere Gameserver. Übernimm weder Zahlen noch Protokolle ungeprüft in eine andere Installation.
Listener und Netzwerkpfad gezielt prüfen
-
Vergleiche Soll und Ist. Nutze die Herstellerangaben, die aktuelle Serverkonfiguration und bei einem gehosteten Server die zugewiesene Adresse samt Port. Ein Anbieter kann einen öffentlichen Port auf einen anderen internen Listener abbilden.
server-portoder eine lokale Konfiguration allein sagt daher nicht zwingend, welchen öffentlichen Endpunkt Spieler verwenden sollen. -
Prüfe den lokalen Listener, falls du dafür Zugriff hast. Auf einem Linux-Server zeigt
ss -lntudie lauschenden TCP- und UDP-Sockets mit numerischen Ports. Die Ausgabe belegt nur, dass der lokale Host einen Socket meldet. Sie beweist weder eine funktionierende Weiterleitung noch eine erlaubende Firewall auf dem Weg. -
Teste nur einen dokumentierten TCP-Dienst. In Windows PowerShell kannst du eine bekannte, für deinen Zugriff vorgesehene TCP-Adresse und genau deren Port prüfen:
$ziel = Read-Host 'Freigegebene Serveradresse'
$port = [int](Read-Host 'Dokumentierter TCP-Port')
Test-NetConnection -ComputerName $ziel -Port $port
Microsoft beschreibt -Port bei Test-NetConnection ausdrücklich als TCP-Porttest. TcpTestSucceeded : True bedeutet also, dass dieser TCP-Verbindungsaufbau gelang. Verwende den Befehl nicht als UDP-Test. Richte RCON auch nicht eigens öffentlich ein, nur um von aussen einen TCP-Port zu prüfen; wenn es ein Verwaltungsdienst ist, teste ihn ausschliesslich über den vorgesehenen, geschützten Zugriff.
- Teste UDP mit dem passenden Dienst. Nutze den normalen Spieleclient für einen Beitritt oder das vom Spielehersteller dokumentierte Query-Werkzeug für eine Serverabfrage. UDP hat keinen allgemeinen Verbindungs-Handshake. Ein stilles Ergebnis lässt allein offen, ob Pakete unterwegs gefiltert oder verloren werden oder ob Dienst und Abfrage nicht zusammenpassen. Vergleiche die Rückmeldung des Spiels mit Serverkonsole oder freigegebenen Hosting-Paneldaten.
Wenn die dokumentierte Verbindung scheitert, prüfe nur den betroffenen Protokoll-Port auf dem Server, in der Hosting-Zuordnung und – bei einem selbst betriebenen Server – in der passenden Routerregel. Halte für einen Vergleich Uhrzeit, Netzweg, Zieladresse, Protokoll und Port fest. Öffne keine ganzen Portbereiche auf Verdacht und schalte Firewall oder Sicherheitssoftware nicht ab. Bei einem gehosteten Server ohne Shell-Zugriff kannst du dem Anbieter Spiel, Serverversion, zugewiesenen Endpunkt und das genaue Testergebnis nennen oder über /kontakt nachfragen.
Ein TCP-Test mit Erfolg bei gleichzeitig scheiterndem Beitritt kann auf einen anderen UDP-Spielport oder einen anderen Anwendungsschritt hinweisen. Bei einer konkreten Ablehnung oder einem Timeout hilft zusätzlich Minecraft: Connection refused und Timeout unterscheiden. Für die getrennte Prüfung beider IP-Familien lies Gameserver über IPv4 und IPv6 auf Erreichbarkeit prüfen; die Satisfactory-Anleitung behandelt ausschliesslich dessen konkrete Portzuordnung.