Match this symptom
The server works on the host PC or local network, but an outside player cannot connect by direct IP, times out, or sees an unstable network connection.
The answer first
Use one explicit UDP game port from the server to the router. Palworld documents UDP 8211 as the default. Match that value in the server startup arguments, Windows Firewall inbound rule and router port forward, then test from outside the home network.
The minimum port plan
- Game port: UDP 8211 by default, unless you intentionally start the server with a different -port value.
- Windows Firewall: one inbound UDP rule for the chosen local port, scoped to the server executable or private host as narrowly as practical.
- Router: forward the same external UDP port to the same internal UDP port on the server PC's reserved local IP address.
- Client: connect to the public IPv4 address and the selected public port.
Create the Windows Firewall rule
- 1Open Windows Defender Firewall with Advanced Security and choose Inbound Rules.
- 2Create a new Port rule for UDP and enter 8211, or the custom port you actually configured.
- 3Allow the connection only on the network profiles the server PC uses. Give the rule a clear name such as Palworld Dedicated UDP 8211.
- 4If you prefer a program rule, point it at the current dedicated-server executable and verify that an update did not move the executable.
- 5Do not disable the firewall as a permanent fix. A short controlled test can isolate the layer, but restore protection immediately.
Forward the router port
- 1Reserve the server PC's local IPv4 address in the router so the destination does not change after a reboot.
- 2Create a UDP forward from external 8211 to internal 8211 at that reserved address. If you chose a custom port, use the custom value consistently.
- 3Save the rule and confirm that a second router, modem-router or mesh system is not creating double NAT.
- 4Test from a phone hotspot or another outside connection while the Palworld server is actually running.
When the exact symptom persists
- Local connection succeeds, outside fails: inspect router forwarding, double NAT and ISP carrier-grade NAT.
- Neither local nor outside succeeds: confirm the server process and listening port before touching the router.
- Outside test reaches the wrong PC: update the forward to the server PC's reserved local address.
- It worked before a reboot: verify that the local address and firewall executable path did not change.
Prove the listener and public path independently
While the server is fully started, verify that Palworld is bound to the intended UDP port on the intended interface. A correct router rule cannot forward to a process that is not listening, and a local join can sometimes use a different discovery path. Preserve the startup log and launch arguments before changing the bind or port so the world identity is never part of this network experiment.
Compare the router's WAN address with the public address seen from the Internet. A mismatch can indicate double NAT or carrier-grade NAT; adding wider forwards or disabling Windows Firewall will not remove that upstream boundary. After each network change, restore the firewall to its narrow rule and test from a phone hotspot with the server online, recording whether traffic reaches the host rather than relying only on an external port-scanner result.