If Server Manager shows a name or ping but joining fails, distinguish the working query path from the management API and game connection. A visible entry is evidence about one part of the network, not proof that every required protocol reaches the server.
This sequence targets the PC dedicated server's Satisfactory 1.1 networking scheme with default ports. Linux commands assume a systemd service named satisfactory, as in the setup guide.
Start with the actual symptom#
| Symptom | Inspect first |
|---|---|
| Server appears offline | Address, process and UDP 7777 |
| Ping/name works; Server API fails | TCP 7777 and certificate error |
| Joining hangs or times out | TCP 8888, game traffic and matching builds |
These are diagnostic starting points. A timeout does not identify a single failing rule.
Confirm the process is listening#
On the server:
sudo systemctl status satisfactory --no-pager
sudo journalctl -u satisfactory -n 100 --no-pager
sudo ss -lntup
Inspect the owning process and listener address, not just the green service status. A listener on 127.0.0.1 alone cannot receive remote connections. Look for TCP and UDP 7777, plus TCP 8888.
The API/query channels are described in the dedicated-server API document; Coffee Stain introduced the reliable channel in its 1.1 announcement. Server Manager uses 7777, not 8888. Older tutorials opening 15000 and 15777 do not describe this scheme.
Read the actual port selection in the startup log. -Port=7777 -ReliablePort=8888 fixes the intended ports; an explicitly selected reliable port fails if unavailable, while automatic selection can choose another. If the log reports a conflict, identify the other process before editing firewall rules.
Separate local API health from external access#
On the VPS, send a read-only health check:
curl --insecure --connect-timeout 5 --max-time 10 \
-H 'Content-Type: application/json' \
--data '{"function":"HealthCheck","data":{"ClientCustomData":""}}' \
https://127.0.0.1:7777/api/v1
HealthCheck needs no authentication. The single local --insecure request tolerates a self-signed certificate; it does not fix trust. Wait until save loading or a map change finishes before treating API unavailability as a fault.
From a different network, use a Linux machine with netcat. Replace 203.0.113.10 with the real public address:
nc -vz -w 5 203.0.113.10 7777
nc -vz -w 5 203.0.113.10 8888
| Result | What it narrows down |
|---|---|
| Local health check fails | Startup, loading, binding or API/TLS; read the server log |
| Local API works; external TCP fails | Provider rules, host firewall, forwarding or address |
| TCP 7777 works; TCP 8888 fails | Reliable channel rule or listener |
| Both TCP probes work; game still fails | UDP path, client error, certificate or build mismatch |
For a VPS, check the public address assigned to this machine and both firewall layers. For home hosting, verify forwarding to the current LAN address and whether the connection has a publicly reachable address. Carrier-grade NAT cannot be fixed with a router forwarding rule alone.
A TCP probe says nothing about UDP 7777. Repeat the original join from the game after changing one setting.
Use an address appropriate to the network#
Inside your home LAN, test the private server address first. Outside it, use the public one. Public-address tests made inside the LAN also depend on router NAT loopback, so an external hotspot provides a different, useful test path.
For a VPS, an external client test matters more than connecting from the VPS to its own public address. Record which path worked instead of reporting only “the port is open.”
Act on certificate and version errors directly#
For Certificate is not yet valid, check automatic time on the gaming PC and timedatectl status on the server. Certificate validity dates are defined by TLS certificate validation rules; extra port rules will not change them.
Do not delete server identity as a first troubleshooting step. Resetting
ServerSettings.PORT.savalso resets passwords, name and certificate, according to the server reset reference. Back up persistent data and plan to reclaim the server if a certificate reset is actually necessary.
Accept a changed certificate only when you expected the identity change. For a build mismatch, compare client and server branch/build, save and back up, stop, update with the original installation method and reconnect with the updated client. If a temporary new session works but the original factory does not, preserve its save and investigate that load failure separately.
Keep evidence of the failed attempt#
Record the exact client error and time, server/client builds, address type, actual listeners and LAN/external results. Keep the corresponding journal and installation-directory game log under FactoryGame/Saved/Logs; the service guide describes both locations. Remove credentials before sharing logs.
If you organise supported instances through a panel for your own VPS, keep this network evidence with the instance notes. Instance controls do not replace provider rules or certificate diagnosis.
