Palworld Server Port Forwarding: 8211, 27015, CGNAT

Palworld server port forwarding normally means sending UDP 8211 to the LAN address of the PC running your dedicated server. Pocketpair documents 8211 as the default, changeable network port; its current setup docs do not require UDP 27015 on every server. This guide shows how to keep the target address stable, make the matching router and firewall rules, and find out whether an outside player can really join.

Check which port your server actually listens on#

For a default Palworld dedicated server, start with UDP 8211. Pocketpair’s server requirements say the default can be changed and must be forwarded through the router. Its server arguments reference says -port=8211 changes the listening port. If you changed that argument, use the configured port everywhere below instead of copying 8211 blindly.

Do not confuse the listening port with -publicport. Pocketpair says -publicport supplies the public port advertised by a community server; it does not change which port the server listens on. For a normal direct-IP connection, friends enter an IP address and port below the server list, as the official connection guide describes. For the wider choice between a home server, VPS, container, or rental, see the dedicated-server routes guide.

The official -publiclobby and -publicport documentation does not name 27015 as a universal query or listing port. The current Requirements, Arguments, and Connect pages all display version 1.0.4; check the settings shipped with your installed server when changing anything beyond the default. Do not add TCP or a range of guessed Steam ports because a generic guide lists them.

Reserve the server PC’s local address#

Give the server a stable address on your home network before adding a router rule. If DHCP later assigns the PC a different address, the existing rule can still point to the old device. A DHCP reservation in your router is usually simpler than manually setting a static address on the PC, because the router continues to manage its address assignment.

1. Find the server's active IPv4 address

   On the server PC, check the active Ethernet or Wi-Fi adapter and note its IPv4 address. Make sure you select the adapter connected to the router that will receive the port-forwarding rule; a virtual-machine or VPN adapter can show a different address.

2. Reserve that address in the router

   In the router’s admin page, find the connected-device list or DHCP reservation page. Select the server PC, then reserve its current LAN address. Router makers use different labels; TP-Link, for example, calls the feature Address Reservation. Its current port-forwarding guide also recommends a stable address for the forwarding target.

   After saving, confirm the PC still has that address. If the router asks for an IP outside its DHCP range, follow the router’s own instructions rather than guessing an address.

If your PC uses more than one network adapter, bind and forward to the address on the adapter that has a route to your home router. A reservation prevents the common “it worked yesterday” failure where the router sends incoming traffic to another device or nowhere at all.

Complete Palworld server port forwarding on your router#

Open the router’s Port Forwarding, Virtual Server, or NAT page. Create a rule for the server’s actual listen port and send it to the reserved LAN address. For an unchanged default, the important values are:

Keep the external and internal port the same for this basic setup. If you changed -port, put that actual value in the port fields and allow it in the firewall too. Do not forward the port to the router itself or to a different PC. Router pages vary, so use the manual for your exact model instead of following menu names from another brand.

Add a separate UDP 27015 mapping only when the specific server image or manager you chose documents it for a feature you enabled. The Thijsvanloef Compose sample above is one such image-specific example; it does not prove all Palworld installations need that port. Do not expose the REST API or RCON just to make players connect.

Allow the same traffic through the host firewall#

Your router and the server PC each have their own network rules. In Windows Security, open Firewall & network protection → Allow an app through firewall, then allow the Palworld server executable on the network profile you use. If you need a port rule instead, open Advanced settings → Inbound Rules → New Rule and allow only the configured UDP port. Microsoft’s Windows Firewall guidance says allowing a recognized app is generally safer than opening a port for all traffic; do not turn off the firewall to test.

On Ubuntu with UFW, the default game port can be allowed with this single-port UDP rule:

sudo ufw allow 8211/udp
sudo ufw status

If the server listens on a different port, replace 8211 with that value. Use an additional firewall rule for 27015/udp only when the particular image or manager documents that requirement and you have enabled the associated feature. The Ubuntu UFW guide shows how to inspect and remove rules; avoid opening an entire port range to make troubleshooting easier.

The Windows Firewall and router rules are separate: a correct forwarding rule cannot override a host firewall that blocks the server process. Pocketpair calls out those two settings separately for Windows installs in its requirements page. For exact Windows, UFW, and cloud firewall rules, see the Palworld server firewall guide.

Test from outside your home network#

A router page showing a saved rule is not proof that players can reach the game. Test in two stages, and use a real Palworld client for the second one. After forwarding works, dynamic DNS can keep a hostname pointed at a changing public IP; it does not repair an unreachable port. Generic “open port” sites often probe TCP, while Palworld’s documented default game port is UDP; a result from a TCP-only checker cannot establish whether the game connection works.

1. Confirm a local player can reach the server

   With the server running, connect from another device on your home network using the server PC’s reserved LAN address and the actual game port, usually 8211. If this fails, check the server process and host firewall before changing the router.

2. Ask a player on another internet connection to join

   Have a friend outside your Wi-Fi enter your public IPv4 address and the configured port in Palworld’s direct-connection field. Pocketpair’s connection instructions describe this IP-and-port route. Xbox and PS5 players need a community server and join it through the Community server list, according to Pocketpair’s server guide; follow the community-server deployment steps for that setup. A direct-IP test from those platforms is not the right check.

   Only mark the setup successful after that external client joins the intended world. Trying your own public IP from the same Wi-Fi may fail on routers without hairpin NAT even when an outside player can connect; Pocketpair documents that limitation for community servers.

If the local test works but the outside test fails, the server itself is probably running; inspect the WAN path next. Confirm the firewall and forwarding target still match the current LAN address, then check whether another router or your ISP sits in front of the router you configured.

Check for double NAT or CGNAT#

Compare the IPv4 address shown as WAN or Internet in your router with the public IPv4 address seen by a device on your network. If they differ, or the router’s WAN address is private, your router may be behind another NAT layer. That might be a second modem/router in your home or Carrier-Grade NAT (CGNAT) operated by your ISP; the address difference is a clue to investigate, not proof of which one you have.

An address in 100.64.0.0–100.127.255.255 is in the shared IPv4 range reserved for service-provider networks by RFC 6598. Private IPv4 ranges such as 10.x.x.x, 172.16.x.x through 172.31.x.x, or 192.168.x.x can also indicate an upstream router. Cisco’s CGNAT overview explains how an ISP can share one public IPv4 among customers.

If you own both routers, you may need to put the upstream device in bridge or access-point mode, or configure the forwarding across both layers according to their manuals. If the upstream layer belongs to your ISP, ask whether your connection has a public IPv4 address and supports inbound port forwarding. A static address reservation on your home router cannot remove a NAT layer that you do not control.

Choose another route if inbound access is unavailable#

If your ISP cannot provide a usable public route and you do not want to maintain a tunnel, hosting the server on a remote game-server service avoids configuring inbound forwarding on your home router. For a group that wants to skip this home-router setup, we recommend Game Hosting’s Palworld service. Its integrated panel handles settings and restarts alongside three free backup slots, so the host can manage upkeep and save copies in one place. That removes this home-router step, but it is not a promise that every account, platform, or network issue will disappear.

If you want to continue self-hosting, return to the full Palworld dedicated-server guide for the complete install and connection routes. Keep the CGNAT distinction clear: a second router you control may be configurable, while an ISP-side NAT needs an option from the ISP or a different hosting route.