Match this symptom
The server starts, local or direct-IP joining may work, but searching the Community Server list returns no matching result.
The answer first
First decide whether discoverability or connectivity is broken. If direct IP works, the world and server process are healthy; check the public-list startup arguments and search behavior. If direct IP also fails, troubleshoot the listening port and firewall before the list.
Run the test in the right order
- 1Stop searching the public list temporarily. From a client outside the host PC, try the server's direct-IP join route using the same public port configured for the server.
- 2If direct IP succeeds, record that result. It proves the server is running and reachable; continue with the listing checks below.
- 3If direct IP fails, confirm the server process is running, confirm the configured listening port, and inspect Windows Firewall and router forwarding before changing public-list options.
- 4Retest after one change at a time. Restart the server when a startup argument changes.
Confirm the public-list arguments
Pocketpair documents the -publiclobby argument for publishing a dedicated server to the Community Server list. The documented startup arguments also include -publicip and -publicport when automatic detection is not suitable.
Do not add a guessed public IP to the world configuration file. These are process startup arguments. Keep a copy of the working launch command before editing it.
- Confirm -publiclobby is present exactly once in the launch arguments.
- If the host has multiple network adapters or automatic detection is wrong, set -publicip to the current public IPv4 address and -publicport to the forwarded game port.
- Keep the server name distinctive enough to search, and remove punctuation only as a temporary search test.
- Wait several minutes after a clean start before concluding the listing failed.
Do not confuse a list problem with a port problem
Pocketpair's requirements page documents UDP 8211 as the default dedicated-server port and notes that firewall and router configuration are required. If you changed the port, every layer must use the same value: server argument, Windows Firewall rule, router forward and direct-IP join.
- Test from a different internet connection; a same-network test can be affected by router loopback behavior.
- Forward UDP, not only TCP, for the Palworld game port.
- Avoid forwarding a broad range when one explicit port is sufficient.
- If the ISP uses carrier-grade NAT, normal home-router forwarding may not create a publicly reachable address.
Safe stopping point
If direct IP works but the Community Server list still does not, give players the direct-IP join details while you investigate discoverability. Do not recreate the world or delete save data: neither action repairs a listing advertisement.
Verify the advertisement with fresh evidence
Record the exact launch command, current public IPv4 address, selected game port, server name, and startup time. The documented public IP and public port values describe how the listing advertises the server; they do not replace the actual listening -port value or create a router forward. A stale advertised address can therefore leave direct joining on the correct address healthy while the list sends players elsewhere.
Test with an exact server-name search after a clean restart and compare results from a client that has never favorited the old entry. If the public address changes dynamically, verify it again before editing configuration. Keep the working world and save tree untouched, and retain the before/after launch lines so a listing service delay is not mistaken for a successful setting change.