Satisfactory Dedicated Server Not Responding: Checks

First separate a crashed process from a connection failure

The 12 October v1.2.4.1 patch names a dedicated-server crash when placing a Conveyor Throughput Monitor. If the server process has exited, no forwarding or password change can make that stopped process answer. Preserve the log and save backup, then have the administrator complete the available server update and compare client/server versions before retesting.

If the process stays running, distinguish loading from readiness and use the discovery/API/join branches below. The patch does not establish a fix for every Server API error, CGNAT tunnel, TLS prompt or join timeout. Do not change ports, disable the firewall or recreate a persistent container merely because the server is labelled “not responding.”

Confirm this is a dedicated-server problem

Use this guide when a separately running PC server appears unavailable, stays unnamed, fails Authenticate, reports a Server API error, or times out while joining. If a friend opened a factory from the normal game client, use the player-hosted loading guide instead. Console players cannot use PC dedicated servers according to the current official FAQ.

Write down the client launcher, client version and branch, server version and branch, host type, and the exact message. Do not assume they match because both updated recently. This guide was researched from documentation and reports; we did not operate your server or verify a current universal port layout.

Protect the server before changing its network setup

Stop the server using its normal host or container controls before copying saves or configuration. Make a dated copy of its persistent save/configuration location outside the active container or install directory. If you cannot identify which volume or folder is persistent, consult that image or host’s current documentation before recreating anything.

Record existing address, port mappings, firewall rules, tunnel settings and launch arguments. Do not publish public IPs, passwords, API tokens, player IDs or complete logs. Avoid deleting configuration, claiming the server again, disabling TLS, or turning off the firewall as a diagnostic shortcut.

Identify the last stage that works

Discovery, management and joining are related but not interchangeable.

The documented HTTPS API is not continuously available while a save is loading or the map is changing. Wait for the server log to show that startup/loading completed before interpreting a brief API failure as a permanent network fault.

Run one controlled local-to-remote comparison

First, have the administrator test from the same local network using the address and method documented for that deployment. Then repeat once from a genuinely separate network with the same client version. Keep the server configuration unchanged between those two attempts and record timestamps so the administrator can match each attempt to the log.

If local access fails, changing public forwarding or a CGNAT tunnel is premature. Confirm the process is listening where the deployment says it should, the container exposes the same interfaces its configuration expects, and the API is no longer busy loading. If local works but remote fails, compare the listening address, container-published address and public/tunnel address as three distinct values.

Treat authentication, TLS and tunnels separately

A self-signed certificate can be normal for the documented HTTPS API; the game client is expected to present a trust confirmation for that server. A missing prompt or an API error is not permission to disable encryption. Record the certificate/API wording and whether it occurs before or after entering a password.

For Docker, managed hosting or a tunnel, follow that exact provider or image’s current variables. In maintainer discussion #455, a server worked locally but a CGNAT tunnel mapped internal and external reliable-messaging ports differently; the log later showed a handshake timeout. The maintainer and user did not confirm a final repair. This is evidence to compare bind, published and advertised endpoints—not a port recipe for every server.

Separate player checks from administrator checks

A joining player can confirm their version/branch, capture the exact stage and time, and try a second known-working server if available. They should not alter the host firewall or ask for admin secrets. The administrator can correlate logs, verify readiness, compare LAN/WAN routes, and review the chosen host/container documentation.

If only one player fails while others join, preserve that difference. If everyone fails at the same stage, avoid asking every player to reinstall; investigate the shared server path first. Back up before updating or changing the server branch.

Stop with a useful report

Stop repeating authentication or random port changes when the same stage fails. Report the client and server version/branch, deployment type, last working stage, local-versus-remote results, exact timestamp/time zone, and a short redacted log window around that attempt. State whether a save was loading and whether other players could join.

Use the documentation or issue tracker for the exact host/image, or the official Satisfactory Q&A route for game-server behavior. Keep the original configuration and saves available for rollback. A visible ping or one successful API request is useful evidence, but recovery is only confirmed when the original join path works again.