Palworld ports: separate the listener from the advertised address

When a Palworld server appears in the community list but joining times out, draw the actual public-to-private UDP route. The game can register a listing while advertising a port that never reaches its listener. Changing the public announcement does not create a router rule, open a firewall or move the listening socket.

This guide concerns an existing dedicated server, especially one behind NAT or a container mapping. Pocketpair's documentation displays version 1.0.4; sources were checked on October 18, 2026. Linux examples use the palworld service from our setup guide. Replace paths, account and ports with the actual deployment.

Write down all sides of the mapping#

Use a concrete example: public UDP 18211 forwards to host UDP 8211, where the game listens. On a public VPS without translation, the external and local ports may both be 8211. With Docker bridge networking there can be a further host-to-container mapping; inspect that too.

The addresses are intentionally described rather than supplied as a runnable public IP. Never advertise a documentation example, private LAN address or an address owned by someone else. If the home router's WAN address is not a reachable public address because of carrier-grade NAT, ordinary forwarding on that router cannot provide the missing upstream route.

Inspect the real listening socket#

sudo systemctl show palworld -p ExecStart -p MainPID -p WorkingDirectory
sudo systemctl cat palworld
sudo ss -lunp 'sport = :8211'
sudo ufw status verbose

Match the socket's process to this service, including any wrapper or child process. For Docker, run the socket check in the relevant network namespace and inspect the published mapping; a host socket listing alone may not describe bridge-network forwarding. Do not accidentally inspect a second stopped installation's launcher.

The official argument reference separates -port, which selects listening, from -publicport, which announces the community endpoint. -publicip supplies an external address when automatic detection is unsuitable. Keep launcher output private if it exposes secrets.

For the example mapping, the relevant launch arguments are:

-port=8211 -publiclobby -publicport=18211

This is an argument fragment for the existing launcher, not a second server launch. Add the real public-IP override only if you have confirmed it is needed. An announcement for 18211 still requires a working UDP rule to the 8211 listener. The separate console discovery article covers community-mode and platform checks; this article diagnoses the route after that registration.

Apply one consistent change during maintenance#

Inspect the existing configuration and launcher first. Preserve private copies under new backup names. Have a connected administrator save and request the documented graceful shutdown before editing launch settings:

/AdminPassword REPLACE_ADMIN_SECRET
/Save
/Shutdown 30 PortMaintenance

Wait for exit and ensure the supervisor has not automatically restarted the old command. If necessary, stop the managed service deliberately and confirm it remains stopped. Edit the existing launcher, keeping its world paths and other required options intact. Reload systemd only if the unit itself changed, then start the existing service once and read its fresh log.

Check the router mapping, provider firewall and host firewall against the same protocol and addresses. The requirements page identifies the gameplay route as UDP. Opening RCON or the REST administration port does not repair it, and exposes a different service. Avoid blindly copying TCP/UDP ranges from an unrelated server recipe.

Observe an external connection attempt#

Ask a player on a genuinely external network to connect to the real public endpoint. A test from the hosting LAN can be affected by hairpin NAT, as the community deployment guide explains. If needed, observe packets during a single agreed attempt:

sudo timeout 30 tcpdump -ni any -nn -c 40 'udp port 8211'

Run this on the appropriate host/interface for your mapping; change the port if necessary. It prints packet metadata without payload display and stops after 30 seconds or 40 packets. Source addresses are still private incident data. timeout returning 124 simply means its deadline expired; it does not identify a game failure.

No arrival at the destination points upstream: public address, provider policy, NAT or client route. Arriving packets with no successful join narrow the investigation to return traffic, firewall state, the listener and game compatibility/authentication. Arrival alone is not proof that the game accepted the player. A TCP port-check website does not substitute for this UDP observation.

Validate both direct access and the listing#

A 2024 support thread describes exactly the misleading symptom: a visible community entry and failed connections despite local access. Its historical settings are not a current fix. Use it to recognize the distinction, then use today's documented arguments and your actual mapping.

First confirm an external direct join where the client's platform supports it. Then select the current community entry and join the same expected world. If direct access works but the list route fails, compare the advertised address and port; if both fail, keep investigating the shared gameplay path. Repeat after one controlled restart and retain the final mapping, startup arguments, timestamp and client result.