Palworld Server Lag: Find the Cause First

"The server is lagging" arrives as one sentence and covers at least four unrelated faults. They feel similar from inside the game and they are fixed in completely different places, which is how people end up paying for more RAM to cure what was a Wi-Fi problem, or moving the server to another country to cure what a restart would have fixed.

This page is the route, not the repair: two questions that sort most reports in about a minute, then one number that settles whatever is left, then where each cause gets fixed. Every branch ends at the article that goes deep on it.

Step 1: is it the server at all?

Before touching a setting, work out whose problem it is. Two questions do almost all of the sorting — is anyone else feeling it, and does the picture stutter or do your inputs land late — and they separate the four cases cleanly.

The third row is what Steps 2 and 3 are about, and the first gets its own section further down. The other three rows have one thing in common: no setting on the server will move them.

One shortcut worth knowing before the work starts: if a restart makes it good again instantly, the machine is not too small. That single test rules out the most expensive wrong answer, and it points straight at what builds up over uptime.

Step 2: read the server's own frame rate

A Palworld server has a frame rate of its own, and it is the difference between "it feels laggy" and a number you can act on. It comes from the official REST API, which the server exposes on localhost once you enable it (setup and the one security rule are in the REST API guide):

curl -s -u "admin:$PW" http://127.0.0.1:8212/v1/api/metrics

Since 1.0, full speed for a Palworld dedicated server is about 60 frames per second. Across the servers we run on v1.0.5, a day of minute-by-minute readings sits at 59 whenever the server isn't under strain, idle or with a player or two online. Every threshold below is a share of that number, so a reading of 55 is nothing to worry about. What the number means:

Three other fields in that response earn their place in the same glance:

• serverframetime is milliseconds per frame, roughly the inverse of the frame rate — 60 fps is about 17 ms. Its value is that spikes show up here before the average frame rate moves, so it's the field that catches a server that's fine on average and hitches every few seconds.
• uptime is seconds since the process started. It's the evidence for build-up: pair a low frame rate with a large uptime and you have your answer before measuring anything else.
• basecampnum is how many bases exist in the world. Of everything the API reports, this is the number that tracks the frame rate most closely — worlds don't get heavy because more people joined, they get heavy because more has been built.

Take the reading while someone is complaining. A number from a quiet morning tells you nothing about a Saturday night.

Step 3: four things that pull server FPS down

In the order they actually turn up. Each one has a test that rules it in or out in under a minute.

1. Uptime — what builds up since the last restart. Memory climbs while people play, and a server that has been up for days carries more than one that restarted this morning. The test is the restart: good again immediately means this is it. The fix is a scheduled restart — intervals, the announce-save-stop-start order and a script are in keeping a Palworld server running 24/7, along with what memory actually did on a real server over ten days.

2. The world got heavy. Bases, structures, working Pals and dropped items all stay simulated after everyone logs off, and none of it goes away on its own. The test is basecampnum plus a look around: a world with a dozen bases and every base fully staffed is doing several times the work it did in week one. Four settings move this directly — bEnableInvaderEnemy, BaseCampWorkerMaxNum, BaseCampMaxNum and DropItemAliveMaxHours (every option explained) — and raids are the one to switch off first.

3. Peak hours — the main thread. Physics, pathfinding, combat and state sync all run on one thread, so clock speed decides your ceiling and extra cores barely help. The test is the shape of the curve: fine at four players, sagging at ten, back to normal when people log off. That's a sizing problem against your player count, not build-up — server requirements covers what to size against, and why a player cap is more than one number is in player limits.

4. A rhythmic hitch — the disk. Everyone freezes for a fraction of a second, at a regular interval, and it has nothing to do with how busy the server is. The test is the clock: if the hitch lines up with AutoSaveSpan (30 seconds by default), it's the autosave meeting a slow disk. This one gets misdiagnosed as a network fault constantly. An SSD ends it.

If two of these are true at once — and after a few months they usually are — fix them in this order anyway. The restart is free and rules out the biggest one.

Client FPS drop is a different number

Two frame rates share one name, and mixing them up sends people to change settings on a machine that was never the problem. Your client's FPS is what your graphics card draws. The server's FPS is how fast the world is simulated. They move independently.

The distinction is one question: do your inputs still land instantly?

That last row is the one worth knowing. A base with hundreds of structures and a full crew of working Pals costs the server simulation and costs your GPU rendering, so the same spot on the map tanks both numbers. People report it as "the server lags at my base" and go hunting on the wrong machine.

For a client-side drop the levers are all local — graphics preset, resolution scale, and closing whatever else is using the GPU — and a dedicated server can't help with any of them. What it can do is make sure the other half of the equation is healthy, which is what the rest of this page is about.

When it's your connection: ping and region

If only one person feels it, it's latency — the round trip between their machine and the server — and that is the only kind of lag that gets better when you move the server closer. Ping is the sum of three segments, and which one dominates decides what you can do about it:

• Distance. Light in fiber covers about 1,000 km in 5 ms one way; real routes aren't straight, so something 1,500 km away has a floor around 20 ms round trip. No hardware moves that floor.
• The path in between. Where traffic is handed off changes the round trip by tens of milliseconds, and neighboring countries are routinely routed through a third. A ping far above what the distance predicts is almost always this.
• The last mile. Your router, your ISP and the Wi-Fi in your house. This is larger than the international segment more often than people expect — a surprising share of "server lag" disappears when someone plugs in a cable.

Measuring it takes a few minutes. ping -n 20 <address> on Windows or ping -c 20 <address> on macOS and Linux gives you the round trip; read the gap between minimum and maximum, not just the average, because that gap is your jitter. tracert / traceroute shows which hop adds the milliseconds, and on Linux mtr -r -c 100 <address> adds per-hop packet loss. With no server yet, ping any public host inside each candidate region on the same evening — you're after the ranking, not an exact figure.

Palworld isn't a competitive shooter, so it tolerates more than people assume:

Steadiness matters more than the average. A line averaging 60 ms that swings between 30 and 120 feels worse than one sitting flat at 120, and because Palworld runs over UDP and doesn't resend what goes missing, packet loss above about 1% rubber-bands you no matter how good the average looks.

For a group spread across countries, optimize the worst player's number, not the average. Everyone measures the same candidate regions into one table; for each region take the largest number, and pick the region whose largest number is smallest. If exactly one person is on another continent, no region gets them under 150 ms — say so early, and don't schedule boss fights around their reflexes. This is also where a dedicated server beats an invite code: with a code, the host's home connection becomes everyone's ping (invite code vs dedicated server).

Pick the region before launch. Changing it later changes the address, so the save has to move and everyone has to retype where they connect.

One more case that reads like a network problem and isn't: a version mismatch. After a game update, a server on the old build doesn't feel slow — it locks everyone out. Updating without losing the save covers the order that keeps the world intact.

Common questions

Why is my Palworld server lagging?

Check who's affected first. If it's only you, it's your connection or your PC. If everyone rubber-bands at once, restart the server: good again instantly means it was build-up over uptime, and a scheduled restart keeps it from coming back. If the restart changes nothing, read serverfps from the REST API while people are complaining — a sag that tracks the player count is the CPU's main thread, a sag with the player count flat is a world that has grown heavy.

What is a normal server FPS on a Palworld server?

About 60 is full speed for a Palworld dedicated server since 1.0 (our servers on v1.0.5 read 59), so anything from 50 up is healthy. Between 30 and 50 the first complaints start; below 30 everyone in the world feels it, with rubber-banding and Pals frozen mid-task. Read it from /metrics on the REST API, and read it while the server is busy rather than at a quiet hour.

Is the FPS drop my PC or the server?

Ask whether your inputs still land instantly. A stuttering picture with instant, responsive controls is your graphics card, and nobody else will be seeing it. A smooth picture with hits that land late is the server, and everyone will be seeing it at the same moment. If both go at once and only in one part of the map, it's a base heavy enough to cost the server and your GPU at the same time.

What ping is good enough for a Palworld server?

Under 80 ms and almost nobody notices; up to 150 ms is comfortably playable. Between 150 and 250 ms building and gathering are fine while boss fights get frustrating. Judge the spread as well as the average: a ping that swings feels worse than a higher one that holds steady.

My ping is low but I still rubber-band. Why?

A low average hides jitter and packet loss, so swap Wi-Fi for a cable first to rule out the last mile. If nothing changes and everyone snaps back at the same moment, it isn't your line at all — it's the server, and Step 2 is where to look.

Do more bases make a Palworld server lag?

They're the single biggest thing a group does to its own server. Bases, their structures and their working Pals keep being simulated after everyone logs off, so the load tracks what has been built far more than how many people are online — and the basecampnum field in /metrics is the number to watch. Capping bases and workers per base, and turning off raids, are the three most direct levers.

Diagnosis you don't have to run

Everything above assumes someone is available to take a reading at the moment people are complaining — which is exactly when nobody is free to SSH in. That's the real difficulty with server lag: the evidence is only there while it's happening, and by the time anyone looks, the server is idle again and reads perfectly healthy.

On a Palworld server from KeepWorlds the readings are already taken — frame rate and player count every minute, kept as a 24-hour curve with an alert line, so "it was awful last night" is something you look at rather than reconstruct. Build-up over uptime is handled before you get there: the Daily scheduled restart puts memory back on the floor at an hour you pick, with an in-game announcement and a forced save first. And the settings that drive the other causes — raids, base limits, workers per base — are fields in the game settings form, not a line of .ini you edit over SSH.