Palworld dedicated servers are queryable, but the in-game community list is a poor guide to whether one is running. Servers disappear from it constantly while working perfectly, and the reflex to treat that as an outage sends people debugging a problem they do not have.
Ports ¶
- Game port, conventionally 8211 UDP. Gameplay.
- Query port, conventionally 27015 UDP, when RCON and query support are enabled in the server settings.
Query support is not always on. Where it is, point our checker at address:27015 for a direct answer from the server. Where it is not, a direct connect attempt from the client is the only reliable test.
Why the community list means so little ¶
Palworld's server list has been unreliable since launch. Servers register with a central list and are dropped for reasons that have nothing to do with their health: a missed heartbeat, list-side capacity, or simply too many servers competing for a place. Search is limited and filtering is coarse.
The practical consequence is that "my server is not in the list" is close to meaningless. Test it by connecting directly with the address and port rather than searching for the name. If direct connect works, the server is fine and the list is not.
Failure modes worth recognising ¶
- Direct connect works, list does not show it: a list problem. Nothing to fix on the server.
- Connects, then disconnects after a few seconds: usually a version mismatch between client and server after an update, or the server hitting its memory ceiling.
- Nothing responds at all: the server is down, restarting, or the port is not forwarded in UDP.
- Everything works for some players and not others: check whether the server was created as a community server or a dedicated one; the two behave differently for people joining from outside the host's network.
Memory is the usual cause of a real outage ¶
Palworld dedicated servers are memory-hungry, and consumption grows with the size of the world and the number of bases built in it. A server that has run fine for weeks can start crashing as the save grows, which reads as intermittent downtime with no obvious trigger.
The signature is a server that comes back on restart and fails again some hours later, with the interval shortening over time. That is memory, not networking, and no amount of port checking will show it.
Updates ¶
Early-access games update often, and Palworld is no exception. Client and server must match, and a server that has not been updated will refuse a freshly-updated client while remaining reachable and healthy. The query will answer normally throughout, which is worth knowing before you go looking for a network fault.
For server owners ¶
- Forward 8211 in UDP, and 27015 as well if you want the server to be checkable from outside. TCP alone is a common mistake and produces a server nobody can reach.
- Enable RCON and query support in the server settings — without them there is nothing to monitor, and you will learn about outages from players.
- Watch memory rather than uptime. Uptime looks fine right up until the crash, and the trend in memory use is the only thing that gives warning.
- Back up the save directory before every update. Palworld save corruption during early access has cost more worlds than downtime has.
Dedicated servers and co-op worlds are not the same thing ¶
Palworld offers two ways to play together, and they fail completely differently:
- A dedicated server runs as its own process, has an address and a port, stays up when nobody is playing, and is checkable from outside.
- An in-game co-op world is hosted by a player's own game. It exists only while that player is in it, is reached through an invite code rather than an address, and cannot be checked at all.
If there is no address and port, there is nothing to query, and "the server is down" usually means the host closed the game. That is not an outage and no tool will report one.
UPnP is why it worked once and then stopped ¶
Many home setups get their port opened automatically by UPnP. UPnP mappings expire, and they are not always renewed — so a server that was reachable yesterday can be unreachable today with nothing changed on either side.
If the pattern is "works after a restart, stops within a day or two", that is the signature. A static port-forward rule, entered by hand, does not expire and removes the whole class of problem.
Settings mismatches look like connection failures ¶
Palworld validates some world settings between client and server. A mismatch can produce a disconnect shortly after connecting rather than an honest error message, which reads like an unstable server. If a server accepts connections and drops them a few seconds later, look at settings and version before looking at the network.
What to check, in order ¶
- Direct connect by address and port, ignoring the community list entirely.
- Query the query port from outside, if query support is enabled.
- Confirm client and server versions match.
- Check the server's memory use before assuming a network fault.