Fixing a laggy or unreachable Satisfactory server starts with identifying the failure layer. Rubber-banding during play is usually a simulation, host, save, or client-quality problem; a failed join is more often a branch, firewall, NAT, or port problem; and a dedicated server that reaches a loading screen but never finishes commonly lacks its reliable-messaging path. Separate peer-hosted sessions from dedicated servers, match every player’s branch and version, then test one variable at a time. The workflow below covers both deployments, including the documented ports, NAT checks, save and mod isolation, and performance settings that can help only after basic reachability works.
Why is my Satisfactory server lagging?
“Lag” describes several different failures. Decide whether the problem is delayed movement and actions after joining, a join timeout, an endless loading screen, or a problem limited to one save or mod set. The scope of the symptom—one player, one host, one save, the LAN, or every internet connection—usually tells you which test to run first.
| What you see | Most useful first checks | What the result means |
|---|---|---|
| Rubber-banding, delayed actions, or players snapping back while connected | Change the host, set every player to Network Quality Ultra, and test another save | If the problem follows one host or save, investigate that host or save rather than opening ports |
| Join fails, times out, or never reaches the world | Match branch and exact version, correct computer time zones, check firewall and NAT, then verify the relevant ports | The failure is in the handshake or route until proven otherwise |
| Dedicated server reaches loading and never completes | Check the standard server port and the reliable-messaging port, then test from LAN and internet separately | An initial connection may work even when the reliable path is blocked |
| Only one save has the problem | Load a fresh save and have another player test the affected save | A save-specific result points away from a general network outage |
| The issue began after a mod install or update | Update or disable the mod and test a no-mod session | Mod effects can remain embedded in a save after the mod is removed |
There is no authoritative percentage showing that most Satisfactory lag comes from bandwidth, CPU limits, NAT, saves, or mods. Treat each claim as a hypothesis and use controlled comparisons instead of assuming the cause.
Is the session peer-hosted or running on a dedicated server?
The two deployments use different port models. A player-hosted session relies on the host’s game client and network path; a dedicated server is a separate process that must listen on known sockets and be reachable through the host firewall and router. Do not combine both port lists into one universal rule.
Peer-hosted multiplayer
For the current support guidance, allow the host’s game traffic through its operating-system firewall and any router rules that apply to that host. The documented peer set is:
| Protocol | Ports | Applies to |
|---|---|---|
| TCP | 5222 and 6666 | Peer-hosted multiplayer |
| UDP | 5222, 6666, and 7777–7827 | Peer-hosted multiplayer |
Dedicated server
Patch 1.1 dedicated-server guidance uses standard port 7777 on both TCP and UDP, plus reliable-messaging port 8888 on TCP. The external and internal standard port numbers should match. If you configure a custom reliable port, set the corresponding external mapping parameter and forward that port instead of assuming 8888 remains correct.
How do I isolate the cause before changing settings?
Use low-risk comparisons first. Each test should change one condition and record whether the symptom changes; otherwise it is easy to “fix” a problem accidentally while leaving the real cause unknown.
- Record the symptom and scope. Note whether the delay affects everyone, one client, one host, one save, or only internet players. Record whether you can reach the server list, begin loading, and enter the world.
- Confirm the deployment. Identify the player who is hosting or the machine running the dedicated-server process. Use the matching port model from the tables above.
- Match branch and exact version. Every player must be on the same Release or Experimental branch and the same version number. Check the launcher and the in-game version display on every computer.
- Correct computer time zones. An incorrect system time zone can contribute to failed joins even when the displayed clock appears close. Correct it on all participating machines and retry.
- Change the host. Have another player host the same activity. If the lag follows the original host, inspect that computer, its firewall, and its route. If it disappears, the original host is the meaningful variable.
- Set Network Quality to Ultra for a controlled test. Apply the same setting to all players, then compare load time and in-session behavior. Ultra can improve client loading and network performance but may reduce server framerate, so watch the host or server’s frame behavior as well.
- Test a fresh save. Keep the original save backed up, create or load a clean world, and repeat the same actions. Ask another player to load the suspect save if possible; a problem that follows the save needs save or mod investigation.
- Run without mods. Disable or update every mod and test a copy of the save. Removing a mod does not guarantee that its effects have disappeared from an existing save, so a clean test world is the safer comparison.
These tests separate a game-state problem from a route or handshake problem without risking irreversible changes. Only after a basic connection works should you tune timeouts, tick rate, autosave, or player count.
How do I fix a failed join or Strict NAT in a peer-hosted game?
Start with the host’s firewall and router, then check NAT behavior. A Strict or TBD NAT result is a connectivity fault; changing simulation settings will not repair a blocked route.
Allow the host through the firewall
- Allow the Satisfactory executable on the host through the operating-system firewall for the network profiles you actually use.
- Check antivirus or security-suite network controls separately; an operating-system rule can be correct while a second product still blocks the process.
- If rules have become contradictory after updates, back up any custom policy and reset the game’s firewall entries, then create a fresh allow rule.
Apply only the peer port rules
Use TCP 5222 and 6666, and UDP 5222, 6666, and 7777–7827 for the player who is hosting. Forwarding dedicated-server port 8888 will not substitute for the peer-hosted model, and opening every port “just in case” makes troubleshooting harder and increases exposure.
Check NAT and router behavior
Verify the router’s NAT status, UPnP or manual-forwarding state, and the LAN address assigned to the host. Reserve the host’s address in DHCP if you use manual rules, because a changed address silently sends forwarding to the wrong computer. If you use pfSense, the documented workaround for some NAT paths is Hybrid or Manual outbound NAT with an outbound mapping for the host IP.
Use the DNS workaround only as an advanced test
Coffee Stain’s support guidance documents a STUN/TURN workaround that begins with nslookup turn.rtcp.on.epicgames.com and hosts-file entries. Treat this as an advanced route test: back up the hosts file first, use the addresses provided by the support procedure, document every line you add, and remove the changes when testing is complete. A hosts-file edit is reversible, but an incorrect entry can affect other applications.
How do I fix a dedicated server that times out or stays on loading?
Diagnose a dedicated server in layers. First prove that the process is alive and listening; then prove LAN access; only then troubleshoot the public route. This order prevents you from blaming the router for a server that never bound its socket.
- Confirm the process is running. Check the service, console, or task manager on the server machine. Review its startup output for configuration errors or a second instance using the same port.
- Inspect actual listening sockets. Use the operating system’s TCP and UDP socket tools to see which process owns the ports. Do not assume the configured number is the bound number when multiple instances or custom parameters are present.
- Permit inbound traffic on the host firewall. Create rules for every protocol and port used by the running instance. A rule for TCP alone cannot carry the UDP portion of the standard port.
- Verify router forwarding. Forward standard port 7777 on TCP and UDP, and reliable-messaging port 8888 on TCP under Patch 1.1 guidance. Ensure the external and internal standard ports match, and target the server’s current LAN address.
- Stabilize the LAN address. Create a DHCP reservation or static assignment so a reboot does not move the server and invalidate the forwarding rule.
- Test from another device on the same LAN. A LAN failure points to the process, listening sockets, host firewall, or local addressing.
- Test from outside the LAN. Use a genuinely external connection and the public address. LAN success with internet failure points to forwarding, upstream NAT, or an ISP restriction rather than the game simulation.
- Check the reliable path when loading never completes. An initial handshake can succeed while the reliable-messaging port is blocked, producing an apparently frozen loading screen. Confirm that the reliable port is listening, allowed, and forwarded with the correct protocol.
If you run more than one instance, inspect each process-to-port mapping and give each instance a distinct configuration. Testing the public address from inside the same LAN can be misleading on routers without NAT loopback, so use a device that is truly outside the network for the final check.
What should I check when the branch, version, or time zone is wrong?
Version mismatch can look like a network timeout even when every port is open. Set every participant to the same Release or Experimental branch and exact version, then restart the launcher and game before testing again.
- Compare the branch selector in each launcher.
- Compare the version shown in-game, not just the launcher’s download status.
- Correct the operating system’s time-zone setting on every machine.
- Back up saves before switching branches. The Experimental branch is intended to test features before they reach the main branch, and a save created or changed there may not behave safely when moved between versions.
- After switching, allow any update to finish completely before launching the server or client.
Do not use a port change to compensate for mismatched binaries. Resolve the version state first, then return to network diagnostics if the same symptom remains.
Can Engine.ini timeout values fix a connection timeout?
They can help a genuinely slow handshake, but they cannot repair a blocked port, wrong branch, or unreachable server. The configuration reference lists a 30-second default for both InitialConnectTimeout and ConnectionTimeout.
- Back up the relevant configuration file before editing it.
- Change one timeout conservatively, using the documented key name and syntax in
Engine.ini. - Restart the affected client or server and repeat the same join test.
- If the result does not change, restore the backup and continue with branch, firewall, NAT, and port checks rather than increasing the value indefinitely.
A higher timeout can make a slow connection wait longer; it does not increase bandwidth or make a non-listening process answer. Document the old and new values so another administrator can undo the experiment.
Which server settings affect performance after connections work?
Performance settings are useful only after LAN and internet reachability are proven. They trade responsiveness, server framerate, save stalls, and resource use; none is a substitute for correct routing.
| Setting | Documented value or guidance | Trade-off and test method |
|---|---|---|
| Server tick rate | Default 30; the value is an upper limit | Raising it cannot help hardware that cannot reach the default. Increase only while monitoring server frame time; lower it again if side effects appear. |
| Autosave interval | Default 300 seconds (5 minutes) | Shorter intervals can cause a performance drop during saving. Compare a normal play period with save events visible in the server behavior. |
| Player limit | Dedicated-server tuning assumes a default cap of four | Increasing the limit is a capacity change that can hurt stability, performance, and resource use. Measure CPU, memory, and frame behavior before adding players. |
| Network Quality | Ultra is available as a client setting | It may improve client loading and network performance while costing server framerate. Compare both client experience and server frame behavior. |
Tick rate is not a magic lag switch
Tick rate limits how often the server attempts simulation updates. If the machine cannot sustain the documented default of 30, raising the limit only increases the work it is being asked to do. Use a lower value as a diagnostic if raising it introduces instability, then keep the setting that the hardware can sustain.
Autosave creates a distinct kind of hitch
A short, repeatable stall at the save interval is different from constant rubber-banding or a failed join. The documented default is 300 seconds; shortening it increases how often the server performs the potentially expensive save operation. Keep reliable backups, but do not mistake a save-time pause for a NAT fault.
Player count changes capacity, not connectivity
The default dedicated-server cap is four players because the server is tuned around that load. A larger cap can consume more CPU, memory, and simulation time even when the network path is healthy. Increase it only after measuring a stable baseline and retain a rollback value.
How can I tell whether a save or mod is responsible?
A controlled save test is safer than repeatedly modifying the only copy of a world. Preserve the original, then compare a fresh world, the suspect world, and—when possible—the same world loaded by another player.
Fresh-save test
- Back up the affected save before opening it on another branch or with different mods.
- Create a new world with the same host and client settings.
- Repeat the action that causes delay or loading failure.
- Have another player test the original save if the fresh world is healthy.
If only the original world fails, focus on its state, build complexity, or mod history. If both worlds fail for the same host, return to host, firewall, NAT, and performance checks.
No-mod test
Disable or update mods before testing, and use a copy of the save. Mod effects can persist in saved data after a mod is removed, so a no-mod launch of the old world is not the same as a clean-world test. A clean world that works while the old world fails is evidence for save or mod state, not proof that the network is broken.
What does each test result tell me?
| Test result | Most likely scope | Next action |
|---|---|---|
| Another player can host the same activity without lag | Original host computer, route, firewall, or NAT | Compare host settings and test the original host’s firewall and public route |
| Every host has the same delay in one save | Save or mod state | Use a backed-up copy, update or disable mods, and compare a fresh world |
| LAN clients cannot join the dedicated server | Process, listening socket, host firewall, or LAN address | Inspect actual sockets and local firewall rules before router changes |
| LAN clients join but internet clients cannot | Forwarding, upstream NAT, or ISP restriction | Verify target address, protocols, public address, and external test path |
| Join begins but loading never completes | Reliable-messaging path or server-side process state | Check the reliable port’s listener, firewall rule, and forwarding |
| Only Experimental or only Release fails | Branch or exact-version mismatch | Align branch and version, then restart and retest |
How do I roll back changes safely?
Network and configuration edits can outlive the original troubleshooting session. Keep a short change log with the old value, new value, date, and machine affected.
- Back up saves before changing branches, testing mods, or opening a world with a different configuration.
- Export or record firewall rules before resetting them.
- Back up the hosts file before any STUN/TURN workaround and remove temporary entries after testing.
- Record router forwarding rules, the reserved LAN address, and the public address used for the test.
- Back up
Engine.inibefore changing timeout values, tick rate, or autosave-related settings. - After a successful test, undo unrelated experiments one at a time to identify which change mattered.
Reversibility is part of diagnosis: host changes and fresh-save tests are low risk, while hosts-file edits, firewall resets, and configuration changes deserve explicit backups.
Frequently Asked Questions
Can players join over the LAN but not from the internet?
Yes. That pattern means the server process and local firewall are probably working, while router forwarding, upstream NAT, or an ISP restriction still blocks the public route. Verify the forwarding target after every DHCP change and test from a genuinely external connection.
Does changing the NAT type improve server frame rate?
No. NAT determines whether a connection can be established; it does not increase simulation capacity. Once reachability works, investigate tick rate, autosave stalls, player count, and the server’s frame behavior separately.
Should I delete a mod from the save to stop lag?
Do not delete mod data from your only copy. Back up the save, update or disable the mod, and compare both a clean world and the original world; effects can remain in saved data after removal.
How can I verify which program owns a dedicated-server port?
Use the operating system’s TCP and UDP socket inspection tools and identify the process ID bound to the port. This catches duplicate instances and custom-port mistakes that a configuration file alone cannot reveal.
Will a VPN automatically fix Satisfactory connection problems?
No. An alternate route can be a diagnostic experiment for difficult NAT paths, but it may add latency and does not repair a mismatched branch, blocked host firewall, or overloaded server. Compare the same host and save with and without the alternate route.