Your friend on PS5 opens Palworld, goes looking for your server, and it is not there. Meanwhile a friend on PC joined half an hour ago and is happily building a base. Nothing on the dashboard is red, the server is running, and the crossplay switch is on. This is the most common Palworld support question we get, and the crossplay switch is almost never the answer.
The reason it is confusing is that two separate settings control two different things, and the words for them overlap. One decides who is allowed on your server. The other decides who can reach it at all.
Allowed versus reachable
| Setting | What it actually controls | Default on your server |
|---|
| Crossplay | Which platforms the game will accept a connection from. On means the allowed list is Steam, Xbox, Mac and PS5; off narrows it to Steam only. | On |
| Community Servers listing | Whether your server is published into the in-game Community Servers browser. | Off |
Pocketpair's own server guide is explicit about why the second row is the one that matters here. Its list of cross-play platforms covers Steam, the Xbox series and the Windows PC version downloaded from the Microsoft Store, macOS and PS5 — and then it says that if you want to join the server from the Xbox version or the PS5 version, you need to deploy it as a community server. A console client has no field to type an address into. The browser is the whole interface.
So a console player being unable to find your server is the expected result of an unlisted server, not a symptom of anything broken. The fix is to publish it.
Get a console player onto your server
Everything below happens on one page: open your server, go to the Settings tab, and work inside the Palworld settings card. Nothing here takes effect until the server restarts, which is the last step.
Turn crossplay on so the console is allowed
Find the Crossplay row. Its own description says it lets Xbox, PS5 and Mac players join alongside Steam, and that off means Steam only. The switch shows as on unless someone deliberately turned it off, so this step is usually a confirmation rather than a change — but confirm it anyway, because with crossplay off the listing will publish a server your friend still cannot enter.
You know it worked when: the switch reads as on. Behind the scenes this is the difference between an allowed-platform list of (Steam,Xbox,PS5,Mac) and one of (Steam).
Set a server password
Fill in Server password. Its placeholder says you can leave it blank for no password, and for a private server among friends that is normally fine — but not here. The listing will not publish a server without one.
Pick something you are willing to type into a group chat, because everyone joining from the browser will need it.
You know it worked when: the next row stops being greyed out.
The row is labelled List in Community Servers (so PS5/Xbox can find it). While the password field is empty it is locked and reads "Set a server password first — an open server is never published." With a password in place it unlocks; turn it on.
That gating is on purpose and it is enforced on the server side, not only in the browser. Listing broadcasts your server to every Palworld client in the world, and a listed server with no password is a far larger blast radius than an unlisted one.
You know it worked when: the switch is on and its description is the explanatory one, not the "set a password first" one.
Restart the server
Press Save settings, then restart the server with the Restart button above the tabs. The save confirmation itself says it: saving updates the server's setup right away but does not interrupt a running server, and a restart is what applies the change.
This is true of every Palworld setting on that page, not just these two. A saved setting that has not been through a restart yet is stored, not live.
You know it worked when: the server comes back to running. First boots can be slow on Palworld, so give it time before assuming something failed.
Search for the server name on the console
Have your friend open Palworld, choose Community server from the side of the server list, and search for the name in the Server name field — not your hostname, which a console has nowhere to type. Then they enter the password.
If it is not there: confirm the server is actually running rather than asleep, and confirm the name you are searching for is the one saved on the settings page.
The silent part of this that catches people
The listing needs a non-empty join password, and when there isn't one, nothing complains. The community-listing configuration is simply not written into the server's setup at all — an omission, not a rejection. The server boots normally, the settings page still shows your other choices, the logs are clean, and the server never appears in anyone's browser.
That is why this article exists. Every other Palworld setting fails loudly or not at all; this one just quietly does not happen. If you turned the listing on, restarted, and consoles still cannot see the server, check the password field first — including the case where you set a password, listed the server, and later cleared the password for convenience.
What a PC player types instead
A PC player never needs any of this. Pocketpair's connection guide describes entering an IP address and port below the server list, and that path works whether or not your server is listed.
Both values live on the server page, above the tabs, in the Server address card:
- the hostname on the top line — that is what goes in the address field;
- the UDP port on its own line underneath, shown as
Port: {port} (UDP).
Palworld dials a host and a port directly, so the port is genuinely required — unlike Minecraft Java, where the hostname alone is enough. The Copy button on that card knows this and copies host and port together for games that connect over UDP, confirming with "Address copied". If the port line still reads "Port not yet assigned", the port has not been allocated yet; wait a moment and reload the page.
Why a listed server can disappear again
A server that is asleep, stopped or archived is not running, so there is nothing registered in the browser — it drops off the list and comes back when it starts. Our own description of the listing switch says exactly this.
For a PC player that barely matters: connecting to the address and port is enough to wake a sleeping server, because the wake catcher watches those UDP ports and treats two datagrams from the same player within five seconds as a genuine join attempt rather than an internet scanner. A console player has no address to dial, so they cannot wake anything — an asleep server is invisible and stays invisible until somebody else starts it.
If most of your group plays on console, that is a good reason to leave auto-sleep off, or to start the server yourself before they log in. Auto-sleep is off by default, so unless you turned it on, this is already handled.
This is not Minecraft's crossplay
Both games have a setting with the word crossplay in it and they are unrelated mechanisms. On a Minecraft server here, crossplay is a per-server feature that attaches a Bedrock-facing bridge and gives the server a second, Bedrock-only port. On Palworld it is a list of allowed platforms in the game's own configuration — no bridge, no extra port, no plugin. Knowing how one behaves tells you nothing useful about the other, and the Bedrock port line you may have seen on a Minecraft server has no counterpart here.
Read next
- — what the game itself needs, and what running it yourself costs
- — the server address card, the tabs, and the rest of the page
- — when a server sleeps, what wakes it, and what that means for a console group
- — if you are hosting Palworld at home instead