How to Reduce Lag on a Sons of the Forest Server
Rubber-banding, enemies that move in steps and stutters on a timer each have a different cause. This guide shows you how to tell whether the lag comes from a player’s connection, the world itself, the player load or the hosting plan, and which fix to try first.
If only one player rubber-bands, start with their ping, Wi-Fi and client files. True server lag tends to hit everyone in the same place at the same time.
A shared stutter every SaveInterval (600 seconds by default) is the world being written to disk. Smooth after restart but worse later points to uptime drift or a world that has simply grown heavy.
The simulation leans on one main thread. Fights, joins and players spread out across the map all add work to that thread, which is why total CPU graphs can mislead.
Restart cleanly, update server and clients, check autosave timing and lower ActiveTargetFramerate in steps before paying for more CPU class, RAM or a new region.
First, which kind of lag is it?
Do not start by changing random settings. In Sons of the Forest, the useful clues are who lags, when it happens, and where it happens. Those three answers usually point to the right layer straight away.
- Who? If one player has rubber-banding, late hits or slow doors while everyone else is smooth, that is almost always a local connection or client issue. If the whole group feels it together, the problem is on the server side.
- When? A regular hitch at the same interval is classic autosave. Lag that starts during fights, big raids or when somebody joins suggests the server is missing its active simulation target under load. Smooth after a restart but rough later in the day or by the weekend points to world state and long uptime.
- Where? Problems only around the main base usually mean structure count, dropped items, cut logs and other accumulated world state. Problems when players split across the island usually mean the server is simulating more AI and more active areas at once.
Use that reading order before touching the plan or blaming “the host”. It stops you paying for the wrong fix.
Check memory against the plan limit and how far the server is from your group.
What actually loads a Sons of the Forest server
The dedicated server is not just passing packets around. It simulates AI, tracks structures, keeps the world state in memory, saves that state to disk, and sends a large amount of it to joining players through BlobSync. With the default ActiveTargetFramerate of 60, the server is trying to complete sixty active loops each second while players are connected. If the work for each loop becomes too heavy, the server falls behind and players feel that as stepped enemy movement, late hits, rubber-banding and interactions that respond after a pause.
Endnight’s own optimisation notes are useful here because they show what matters: they reduced the CPU cost of lots of idle structures and optimised the construction database to lower both CPU usage and the amount of data sent over the network in multiplayer. That tells you building load is not just a client FPS problem. A big base costs the server as well.
- AI costs active simulation time on the server. Cannibals, mutants and animals are server-side, not just visual.
- Structures cost CPU and network data. Every placed piece lives in the construction database and has to be represented to clients.
- Players spread out wake more of the island at once. More separate hotspots means more AI and world updates in parallel.
- Saves cost disk work and briefly interrupt smooth simulation while the world is written out.
- Joins cost network and some CPU because the joining player has to pull world state through BlobSync. On an old, busy save that transfer is much larger.
The matrix below is the quick way to read which resource is taking the hit.
| Activity | CPU | RAM | Disk | Network |
|---|---|---|---|---|
| Cannibals, mutants and animals | Yes | Partly | No | Partly |
| Large bases and many structures | Yes | Yes | Partly | Yes |
| Players spread across the island | Yes | Partly | No | Partly |
| Autosave every SaveInterval | Partly | No | Yes | No |
| A player joining (BlobSync) | Partly | No | Partly | Yes |
| Long uptime and world clutter | Yes | Yes | No | No |
Layer 1 — the local connection
If one player lags and nobody else does, start here. A server problem is shared by everyone nearby at the same moment; a local problem is not. Patch 08 added a ping column to the in-game server browser, so the player can at least compare their route to the server before joining.
What the player should check
- Ping in the server browser. If their ping stands out from the rest of the group, the route or distance is already telling on them.
- Wired over Wi-Fi. Wi-Fi adds jitter and packet loss, which shows up as rubber-banding and hits landing late even if the average connection looks fine.
- Background traffic. Downloads, cloud sync and streaming can steal bandwidth or add queueing delays on the same line.
- Verify game files after a patch. A version mismatch can show up as a silent disconnect at the loading screen, and a damaged client after an update can behave oddly.
Why the server cannot fix this is simple: it is already sending the same world state to everyone. If only one player receives it late, drops packets or stalls on their own PC, lowering server settings will not cure the root cause. Sort the player’s route, Wi-Fi or client first.
Layer 2 — world state: autosaves, uptime drift and a busy save
The easiest server-side lag to recognise is the autosave hitch. If the whole group stutters together at a regular interval, the server is probably writing the world to disk. That write is controlled by SaveInterval, which defaults to 600 seconds. On a mature world, there is simply more state to serialise, so the pause becomes more noticeable.
{
"SaveInterval": 600,
"IdleTargetFramerate": 5,
"ActiveTargetFramerate": 60,
"IdleDayCycleSpeed": 0.0
} What is happening during that hitch? The server has to package up the current world state and write it to the save slot. That costs disk I/O and some CPU time, and because the simulation is time-sensitive, everyone feels the same pause together. Faster SSD or NVMe storage shortens that pause, but it does not remove the fact that a write is happening.
How to handle the autosave hitch
- Accept it if it is brief and predictable. That is the safest option.
- Lengthen SaveInterval only if you also use reliable backups and clean restarts. A longer gap means fewer writes, but it also means more recent progress at risk if the server dies uncleanly.
- Do not shorten it on a big world. More frequent saving means more frequent hitches.
Long uptime is the other common world-state issue. A server that feels fresh after a restart but sluggish later is usually carrying accumulated world clutter and general session drift. Scheduled restarts help more than most one-off tweaks because they reset the running process and reload the world cleanly. Use a quiet hour, let the server stop cleanly so it saves, back up the save, and do not schedule the restart for the same minute as an autosave. Also make sure normal running uses SaveMode “continue”; leaving it on “new” will overwrite the slot on every start.
Finally, there is plain save busyness. Large bases mean many construction pieces in memory and more data to sync to joining clients. Dropped items, corpses, cut logs and other leftovers add to that over time. If lag is worst near one base or joins take longer and longer, the world itself is part of the problem.
Layer 3 — player load and the framerate target
Sons of the Forest has an 8-player cap. What matters is not just how many of those slots are occupied, but what those players are making the server do. Eight players travelling together in one area are usually easier on the server than a smaller group split across distant parts of the island, because spread wakes more AI and more active world simulation at once.
What ActiveTargetFramerate actually does
ActiveTargetFramerate is the closest thing SotF has to a tick-rate setting. It is the target simulation rate when one or more players are connected. The default is 60. If the main thread cannot complete that much work under load, the real loop rate drops anyway, and players feel the collapse as enemies moving in steps, late melee registration, and doors or structures responding after a pause.
Lowering the target in steps is a legitimate fix on a CPU-bound server. Going from 60 → 45 → 30 reduces the amount of active simulation work the server is trying to squeeze into each second. The trade-off is straightforward: a steady lower rate can feel smoother than a target of 60 that repeatedly collapses, but movement and physics updates become coarser. It does not save memory, and you should never raise it above 60. The minimum allowed value is 10.
Test each step with the same group doing the same busy activity. If stepped enemies improve, hits land more reliably and doors stop pausing, you were CPU-bound on the active loop.
What to leave alone
IdleTargetFramerate and IdleDayCycleSpeed only apply when no players are connected. They are not active-session lag fixes, so leave them at their defaults unless you have a separate reason to change idle behaviour.
Command-line override and the typo trap
Any key from dedicatedserver.cfg can also be passed on the launch command line:
SonsOfTheForestDS.exe -dedicatedserver.ActiveTargetFramerate "45"
This is useful if your panel supports launch arguments or you want to test without editing the file. A missing key uses its default. A misspelled key, though, is simply ignored, which is why a typo can look like “the setting did nothing”. If you edit JSON directly, keep the quotes, commas and exact key names correct; an invalid file fails the server self-test, while a valid file with a wrong key name quietly falls back to default behaviour.
Layer 4 — the hosting itself: CPU, RAM, disk and region
If you have ruled out one-player issues, timed autosave hitches and easy world-state fixes, the hosting plan comes under the spotlight. Start with CPU, not RAM. SotF leans heavily on one main thread, so per-core speed matters more than a big core count. That is why a panel can show relaxed total CPU usage while one core is actually saturated and the server is stuttering in fights.
CPU: why per-core speed matters most
Main-thread saturation looks like this: the server is acceptable while quiet, then enemies start moving in steps, hits register late, or doors and structures answer after a pause once combat starts or players spread out. More cores do not help much if the work that matters is bottlenecked on a single busy thread. In plan terms, a stronger CPU class is the upgrade that changes this, not just a larger headline core count.
RAM: what the graphs actually mean
RAM still matters, but mostly as headroom for the world you have built. Read the memory graph by time:
- Climbs slowly over days, drops after each restart: usually normal for a long-running world.
- Climbs to the plan limit within hours of a restart: the save has outgrown the plan.
When the server hits its memory limit, it may be stopped or restarted with a rollback to the last save. That is a capacity problem, not a tuning problem.
Size the server by how busy the world is, not by slot count. These are the figures we use in our host comparison:
Disk and region
Fast SSD or NVMe storage helps during file-heavy moments: start-up, world load and saves. It can shorten the autosave hitch, but it does not fix combat lag caused by an overloaded main thread. Region matters as well. For a UK group, pick a UK or London location if you can; in our Sons of the Forest server hosting comparison, 22 of the 37 hosts we compared show a London or UK location.
Windows-only build and Linux hosts under Wine
The dedicated server build is Windows-only. On Linux hosting, it runs under Wine, which adds some overhead mostly in memory use and during file-heavy moments such as start-up, world load and saves. That does not mean Linux-hosted SotF is unusable, but it does add one more moving part. If a server starts stuttering straight after a game update and the obvious server/client version checks are already done, the compatibility layer is a fair suspect. For the broader sizing picture, see our guide to game server hardware requirements.
Fix order: tune first, upgrade last
- Identify the layer. Use the who/when/where test so you are fixing the right cause, not the loudest complaint.
- Update the server and clients. Update the dedicated server app and have players verify game files after patches. If anyone is using client-side mod tools, remove them; SotF has no official mod support, and multiplayer desync or crashes are common when those tools touch game code.
- Restart cleanly. Stop the server properly, let it save, then bring it back. Patch 08 added an immediate save before shutdown, which makes clean restarts safer.
- Check autosave timing. If the hitch is regular, confirm it lines up with SaveInterval. Move scheduled restarts away from that minute.
- Lower ActiveTargetFramerate in steps. Test 60, then 45, then 30 if needed. You are trading smoother consistency for coarser updates on a CPU-bound server.
- Trim clutter and plan world settings for the next fresh save. Busy bases, dropped items and long-lived world mess all add weight. In custom mode,
GameSetting.Vail.EnemySpawn,EnemySearchParties,AnimalSpawnRateandGameSetting.Construction.NoCuttingsSpawnchange how busy the island is, but they are read only when a new save is created, never on an existing one. - Move region if the group is far away. For a UK-heavy group, a UK region is a practical first choice.
- Upgrade CPU class. Do this when fights, joins and spread-out players still crush the active loop after sensible tuning.
- Upgrade RAM. Do this when memory hits the plan limit within hours or the server is being stopped and rolled back at the limit.
Tune it or upgrade?
| Sign you see | Tune first | Upgrade when |
|---|---|---|
| Everyone hitches on a regular timer | Check SaveInterval, keep clean restarts, avoid restart-at-autosave collisions | Only consider faster storage if the save pause itself is the last nuisance left |
| Enemies move in steps during fights | Lower ActiveTargetFramerate and test with the same group activity | Upgrade CPU class if combat still collapses at a lower target |
| Fine after restart, worse after a day or two | Schedule restarts, back up saves, reduce clutter over time | Upgrade RAM if memory reaches the plan limit within hours |
| Slow joins and everyone feels a wobble while someone loads in | Restart, keep the world tidy, accept BlobSync cost on mature saves | Move to faster storage or a stronger plan if joins are disruptive every session |
| One player only lags | Have that player check ping, Wi-Fi, downloads and game files | Do not upgrade the server for this alone |
| Problems started straight after a patch | Update server and clients, verify files, and on Linux-hosted servers consider Wine as a suspect | Change platform or plan only if the problem remains after updates settle |
If you have reached the point where region, CPU class or RAM really are the issue, compare plans by location and hardware headroom rather than slot count alone.
Compare Sons of the Forest hostsSelf-hosting on your own PC: the extra causes people miss
Self-hosting adds problems a rented server simply does not have. Your upload is now part of the server’s performance, your household network load matters, and your PC is sharing CPU, disk and memory between the game, the server and everything else running on Windows. If you host and play on the same machine, those jobs compete directly.
- Use wired networking if possible. Hosting over Wi-Fi adds instability before the traffic even reaches the internet.
- Do not let the PC sleep. Patch 08 fixed an issue where a dedicated server could not be joined after the computer returned from sleep mode, but sleep is still a bad state for a machine meant to stay online.
- Forward all three UDP ports. GamePort 8766 handles gameplay traffic, QueryPort 27016 is for listing and discovery, and BlobSyncPort 9700 is used to initialise systems and exchange world data.
- Expect IPv4 only. That is the officially supported network mode.
- Watch for NAT loopback limits. Without hairpin NAT, players on the same LAN or the same machine may not see the internet listing properly and may need the LAN browser instead.
- Set the Windows network profile to Private for LAN hosting, and watch the server boot self-test for port errors such as “UDP <PortName> <PortNumber> is closed.”
If your server needs to stay up while your PC is off, if your router makes port forwarding awkward, or if your household upload is the weak point, that is the moment to move away from self-hosting. For the basics, see our guide to self-hosting a game server.
Symptom → likely cause → first fix
| Symptom | Likely cause | First fix |
|---|---|---|
| Everyone stutters every ~10 min | Autosave hitch at the default SaveInterval | Confirm the timing, then keep it or lengthen SaveInterval only with backups and clean restarts |
| One player rubber-bands | That player’s connection, Wi-Fi or client issue | Check the server-browser ping, switch to wired, stop background downloads, verify game files |
| Enemies move in steps during fights | CPU-bound server missing its active loop target | Lower ActiveTargetFramerate in steps and retest with the same fight load |
| Slow joins and stutter while someone joins | BlobSync transfer on a mature world, plus extra CPU/network work during join | Restart cleanly, keep the world tidier, and expect joins to get heavier as the save ages |
| Smooth after restart, worse after days | Uptime drift and accumulated world state | Add scheduled clean restarts and back up the save |
| Server restarts on its own with rollback | Memory limit reached or the process was stopped at the limit | Check whether RAM climbs to the cap within hours; if it does, move up in RAM |
| Stutter started right after an update | Server/client version mismatch, damaged files, or on Linux hosting a Wine issue | Update the dedicated server, verify client files, then consider the compatibility layer if it persists |
| Settings change seems to do nothing | Misspelled JSON key, wrong value, or a world-setting that only applies on a new save | Check the exact key name, JSON syntax and whether that setting is only read at save creation |
| Lag is worst near the main base | Structures, clutter and heavier world state in that area | Trim clutter, restart regularly, and plan lighter world settings for the next fresh save |
Sons of the Forest server FAQ
Why does my Sons of the Forest server lag every 10 minutes?
The usual cause is autosave. The default SaveInterval is 600 seconds, so a mature world often produces a regular shared hitch at that rhythm while the server writes the save to disk. Faster storage can shorten the pause, but it will not remove the fact that a save is happening.
Does more RAM fix Sons of the Forest server lag?
Sometimes, but not as often as people assume. Combat stutter, stepped enemies and late hits are more often main-thread CPU problems than RAM problems. More RAM helps when the world has grown large enough that memory reaches the plan limit within hours of a restart or the server is rolling back at the limit.
What should ActiveTargetFramerate be?
Start at the default of 60 and only lower it if the server is clearly CPU-bound under load. Testing in steps such as 60, then 45, then 30 is sensible because a steady lower rate can feel better than a target of 60 that keeps collapsing. Never raise it above 60, and remember that lowering it does not save memory.
Is it my connection or the server?
Ask who lags, when it happens, and where it happens. If one player struggles while everyone else is fine, it is usually their connection or client. If the whole group stutters together, especially in the same place or on a timer, it is server-side.
How often should I restart a Sons of the Forest server?
Daily at a quiet hour is a good starting point for a busy save, and a very busy 8-player server may benefit from twice-daily restarts. The key points are to stop it cleanly, back up the save, and avoid restarting at the same minute an autosave is due. If the server is only used casually, you can be less aggressive.
More Sons of the Forest server help
Compare hosts on CPU, RAM and UK locations, or brush up on server hardware basics.
Settings, defaults and ports follow Endnight’s official dedicated server configuration guide and patch notes. Game updates and host panels change; if a panel path, launch option or menu label differs from this guide, follow your host’s current control panel.
