Palworld

Palworld Panthalus disconnect fix: why co-op drops and how to stop it

By the New Games Guide team · Last updated 2026-08-02

Disconnects that happen at a specific point — a particular boss, a particular area, the same moment every attempt — are a different problem from disconnects that happen at random. The random kind is your connection. The repeatable kind is almost always the host machine failing to keep up with a spike in what it has to simulate and send.

That distinction decides everything you do next, so start there.

Why a boss fight disconnects people#

It helps to know what is actually happening, because it explains why the fixes are not the ones people usually try.

In a Palworld co-op session, the host simulates everything: the world, every Pal, every base worker, and every projectile. Clients send inputs and receive state. During a large encounter, three things spike at once — the number of entities being simulated, the number of state updates being sent per second, and the memory being touched per frame.

If the host cannot keep up, the client stops receiving timely updates. After a short window with no valid state, the client gives up and disconnects. The client reports a network error for what is really a host performance problem, which is why "check your internet" is such persistently unhelpful advice here.

The corollary: fixes that reduce host load work. Fixes that adjust client settings mostly do not.

Fix 1 — Reduce what the host has to simulate#

The cheapest and most effective change, and the one nobody wants to hear: the host's bases are the problem, not the boss.

Base simulation runs continuously and does not pause because you are fighting somewhere else. A host with three maxed bases, dozens of working Pals and thousands of placed objects is spending a large share of its frame budget on that before the encounter even starts.

Before your next attempt, on the host:

1. Retrieve Pals from bases you are not using. Each working Pal is continuous cost.
2. Cut placed object count. Decorative structures, long conveyor-style layouts and large walls all cost simulation and networking.
3. Consolidate to fewer bases. Two efficient bases beat four sprawling ones by a wide margin.
4. Empty overflowing containers. Full containers cause Pals to repeatedly path, fail and retry — the single most expensive idle behaviour in the game.
5. Reduce Pal capture and base worker counts temporarily if you are pushing a hard encounter.

Then have the host close everything else — browsers especially — and try again.

Fix 2 — Move off invite co-op to a dedicated server#

If your group is more than two or three people, or anyone has a substantial base, this is the permanent fix rather than a workaround.

Invite co-op puts world simulation, rendering and networking on one machine that is also trying to play the game. The host's framerate and the world's stability are the same resource.

A dedicated server runs the world as its own process with its own memory and its own CPU budget. Nothing competes with the render thread because there is no render thread. Encounter spikes that reliably dropped clients in invite co-op frequently stop entirely.

You can run it on the same PC as one player, and it still helps — the separation of processes is most of the benefit. Migration is straightforward:

1. Stop the game everywhere.
2. Copy the world folder from the host's %LOCALAPPDATA%\Pal\Saved\SaveGames\<SteamID>\<world>\ to the server's save location.
3. Point the server config at that world.
4. Start the server and connect by IP.

Player files travel with the world, so everyone keeps their character, level and Pals. Keep the original folder untouched until you have confirmed the server world loads correctly.

Fix 3 — Check the host isn't hitting a hard limit#

Some disconnects are the host process dying or being throttled, not a network event.

• Memory. Watch the host's RAM in Task Manager during play. Palworld's memory use grows with world complexity and session length. A host at 95%+ RAM will start dropping clients before it crashes outright. Confirm the page file is system-managed rather than disabled.
• CPU thermal throttling. A laptop host on battery, or with blocked vents, will clock down exactly when the encounter demands the most. Check clocks under load, not at idle.
• Session length. If disconnects only appear after a couple of hours, that is a leak pattern. Restarting the session before a hard encounter is a legitimate workaround.
• Dedicated server player cap. Confirm the configured maximum is above your party size — connections above the cap fail in ways that look like drops.

Fix 4 — Fix the network path#

Now the parts that genuinely are networking, in order of how often they matter.

Wire the host. Not the clients — the host. Wi-Fi packet loss on the machine sending state to everyone else affects everyone. A cable to the host fixes more group disconnects than any other single change.

Enable UPnP or forward the ports. Give the host machine a DHCP reservation so its local IP stops changing, then either enable UPnP on the router or forward Palworld's ports (the default game port, plus the query port if you are running a dedicated server) to that reserved address.

Check for a double NAT. If your ISP router and your own router are both doing NAT, hosting is unreliable in ways that no port forwarding fixes. Put the ISP device in bridge mode, or forward through both layers.

Test your line quality, not your speed. A speed test tells you almost nothing here. Run a sustained ping to a stable address during play and look for loss and jitter:

ping -t 1.1.1.1

Any packet loss at all, or latency that swings by more than about 30ms, will cause the drops you are seeing. That is a line-quality problem for your ISP, not something a game setting fixes.

Fix 5 — Check the host's upload#

This is the number people never check, and it is frequently the whole story.

The host uploads state to every client simultaneously. Many home connections are extremely asymmetric — 500 Mbps down and 20 Mbps up is common — and it is the upload that matters.

Rough guidance for planning: budget a few Mbps of headroom per connected client, and remember you are sharing that upload with everything else in the house. One person uploading video, one cloud backup running, or one console downloading an update in the background can consume the entire margin. Pause cloud sync and background downloads on the host's network before a session.

Fix 6 — When only one player drops#

If four people are connected and the same one keeps falling out, stop looking at the host.

1. Have them verify their game files. Corrupt assets on the client cause a disconnect when the asset is needed.
2. Have them delete their shader cache and let it rebuild.
3. Check version parity. A client one patch behind the host connects and then fails at a confusing moment rather than refusing outright.
4. Check for mods on one side only. Any mod that touches Pals, items or the save format will desync a client. Disable everything, confirm a clean session, then reintroduce.
5. Test them on a different network. A phone hotspot for ten minutes tells you immediately whether it is their connection or their machine.

Fix 7 — Prevent losing progress when it happens anyway#

Until it is fully solved, protect what you have.

• Back up the world folder before every session. Copy %LOCALAPPDATA%\Pal\Saved\SaveGames\<SteamID>\ somewhere else. Thirty seconds, and it makes every other experiment safe.
• Have clients bank valuables at base before a hard encounter. Disconnect timing can lose items in flight.
• Set a shorter autosave interval on dedicated servers so a drop costs less.
• Watch the host's resource monitor on a second screen. Once you have seen RAM climb into the danger zone before a drop, you will recognise the pattern instantly.

FAQ#

Is this fixed by a patch, or do I have to do all this?#

Patches fix specific encounter bugs; they do not change the fact that one machine is simulating the whole world. If your drops are host-load driven, they will keep happening after every patch until the host has less to simulate — which is why Fix 1 and Fix 2 are first.

Does the client's internet speed matter?#

Barely. Clients receive a modest state stream and send small inputs. A client on a slow but stable connection is fine; a client on a fast but lossy connection is not. Stability matters, throughput does not.

Will a dedicated server fix it if I run it on the same PC as the host?#

Usually yes, and this surprises people. The win comes from separating world simulation into its own process with its own memory space, so it no longer competes with rendering for frame time. You get most of the benefit without renting anything.

We all disconnect at exactly the same second. What is that?#

That is the host process or the server process, not the network — a network fault would drop players unevenly. Check the host's memory and temperatures, and look at the server log's final lines. A simultaneous drop of everyone is the signature of the world process dying.

Do I lose my Pals or items if I disconnect mid-fight?#

Your character state is saved on the host's schedule, so you roll back to the last save point, not to the start of the session. Items picked up between the last save and the disconnect can be lost. This is why shortening the autosave interval on dedicated servers is worth doing.