Satisfactory-Server antwortet nicht: gezielte Prüfungen

Zuerst abgestürzten Prozess von Verbindungsfehler trennen

Der Patch v1.2.4.1 vom 12. Oktober nennt einen Dedicated-Server-Absturz beim Platzieren eines Conveyor Throughput Monitor. Ist der Prozess beendet, kann ihn keine Portweiterleitung oder Passwortänderung erreichbar machen. Sichere Log und Spielstand; der Administrator sollte verfügbare Serverupdates abschließen und Client-/Serverversionen vor dem erneuten Test vergleichen.

Läuft der Prozess weiter, unterscheide Laden von Bereitschaft und nutze unten Erkennungs-, API- und Beitrittsprüfungen. Der Patch bestätigt keine Lösung jedes API-Fehlers, CGNAT-Tunnels, TLS-Dialogs oder Timeouts. Ändere keine Ports, deaktiviere nicht die Firewall und erstelle keinen persistenten Container allein wegen „not responding“ neu.

Prüfe, ob es wirklich um einen Dedicated Server geht

Nutze diese Anleitung, wenn ein separat laufender PC-Server nicht erreichbar ist, ohne Namen bleibt, bei Authenticate scheitert, einen Server-API-Fehler meldet oder beim Beitritt abläuft. Öffnet ein Freund seine Fabrik im normalen Spielclient, nutze stattdessen die Anleitung für spielergehostete Sitzungen. Laut aktuellem offiziellen FAQ können Konsolen keine PC-Dedicated-Server nutzen.

Notiere Launcher, Clientversion und -zweig, Serverversion und -zweig, Hosttyp und exakte Meldung. Nimm nicht an, dass beide Seiten übereinstimmen, nur weil sie kürzlich aktualisiert wurden. Wir haben Dokumentation und Berichte geprüft, aber weder deinen Server betrieben noch ein allgemeingültiges Portlayout bestätigt.

Schütze den Server vor Netzwerkänderungen

Beende den Server mit den normalen Host- oder Containerfunktionen, bevor du Spielstände oder Konfiguration kopierst. Erstelle außerhalb des aktiven Containers oder Installationsordners eine datierte Kopie des dauerhaften Speicher- und Konfigurationsorts. Ist das persistente Volume unbekannt, lies zuerst die aktuelle Dokumentation genau dieses Images oder Hosters.

Notiere Adresse, Portzuordnungen, Firewallregeln, Tunneleinstellungen und Startargumente. Veröffentliche keine öffentlichen IPs, Passwörter, API-Tokens, Spieler-IDs oder vollständigen Protokolle. Lösche keine Konfiguration, beanspruche den Server nicht neu und deaktiviere weder TLS noch Firewall als Diagnoseabkürzung.

Bestimme die letzte funktionierende Stufe

Erkennung, Verwaltung und Beitritt hängen zusammen, sind aber nicht dasselbe.

Die dokumentierte HTTPS-API ist beim Laden eines Spielstands oder Kartenwechsel vorübergehend nicht verfügbar. Warte im Log auf das Ende von Start und Laden, bevor du einen kurzen API-Ausfall als dauerhaften Netzwerkfehler wertest.

Vergleiche lokalen und externen Zugriff kontrolliert

Zuerst testet der Administrator aus demselben lokalen Netz mit der für dieses Deployment dokumentierten Adresse. Danach folgt genau ein Test aus einem wirklich anderen Netz mit derselben Clientversion. Ändere die Serverkonfiguration dazwischen nicht und notiere Zeitstempel, damit jeder Versuch zum Log passt.

Scheitert der lokale Zugriff, sind öffentliche Weiterleitung oder CGNAT-Tunnel noch nicht der richtige Ansatz. Prüfe, ob der Prozess am erwarteten Interface lauscht, der Container die erwarteten Interfaces veröffentlicht und die API nicht mehr lädt. Funktioniert lokal, aber nicht extern, behandle Bind-Adresse, veröffentlichte Containeradresse und öffentliche Tunneladresse als drei getrennte Werte.

Trenne Authentifizierung, TLS und Tunnel

Ein selbstsigniertes Zertifikat kann bei der dokumentierten HTTPS-API normal sein; der Spielclient soll eine Vertrauensabfrage für diesen Server zeigen. Ein fehlender Dialog oder API-Fehler ist kein Grund, Verschlüsselung abzuschalten. Notiere den Zertifikat-/API-Text und ob er vor oder nach der Passworteingabe erscheint.

Bei Docker, Managed Hosting oder Tunnel gelten die aktuellen Variablen genau dieses Anbieters oder Images. In Diskussion #455 arbeitete ein Server lokal, doch ein CGNAT-Tunnel ordnete interne und externe Reliable-Messaging-Ports unterschiedlich zu; das Log zeigte später einen Handshake-Timeout. Maintainer und Nutzer bestätigten keine endgültige Lösung. Das ist ein Anlass, Bind-, veröffentlichte und angekündigte Endpunkte zu vergleichen, kein Portrezept für alle Server.

Trenne Spieler- und Administratoraufgaben

Ein Spieler kann Version/Zweig prüfen, Stufe und Zeitpunkt festhalten und, falls verfügbar, einen anderen bekannten Server testen. Er sollte weder die Host-Firewall ändern noch Administratorgeheimnisse anfordern. Der Administrator kann Logs zuordnen, Bereitschaft prüfen, LAN/WAN vergleichen und die gewählte Host-/Containerdokumentation lesen.

Scheitert nur ein Spieler, während andere beitreten, bewahre diesen Unterschied. Scheitern alle an derselben Stufe, verlange nicht von jedem eine Neuinstallation; untersuche zuerst den gemeinsamen Serverweg. Sichere vor Update oder Zweigwechsel.

Höre mit einem brauchbaren Bericht auf

Wiederhole nicht ständig Authentifizierung oder zufällige Portänderungen. Melde Client-/Serverversion und -zweig, Deploymenttyp, letzte funktionierende Stufe, lokale/externe Ergebnisse, genaue Zeit mit Zeitzone und einen kurzen bereinigten Logabschnitt. Nenne, ob ein Spielstand lud und ob andere Spieler beitreten konnten.

Nutze Dokumentation oder Tracker genau deines Hosts/Images beziehungsweise die offizielle Satisfactory-Q&A-Seite für Spielserververhalten. Bewahre Originalkonfiguration und Spielstände für eine Rückkehr auf. Ein sichtbarer Ping oder eine erfolgreiche API-Anfrage ist nützlich; bestätigt ist die Wiederherstellung erst, wenn der ursprüngliche Beitrittsweg erneut funktioniert.