Project Zomboid Ports: Why Yours Are Closed

A Project Zomboid dedicated server can look healthy in its console and still be impossible to join. The usual cause is not SteamCMD or Java. It is that the server uses two separately configured UDP ports, or that it quietly loaded a different configuration directory than the one you edited.

The quick answer is: set DefaultPort=16261, set UDPPort=16262, allow and forward both UDP ports, and write a custom cache directory as -cachedir=/path/to/data with an equals sign.

Knowing the numbers is rarely the problem. Testing them is, because a port test run from the machine hosting the server never leaves your own network and so always passes. Our free game server port checker probes 16261 from the public internet and tells you whether players can actually reach it.

Run Project Zomboid without managing ports by hand

The two ports do different jobs

• DefaultPort is the game and Steam-facing port. The default is UDP 16261.
• UDPPort is Project Zomboid's separate RakNet port. The usual default is UDP 16262.

They are independent settings in the server ini file. Treating the second port as an automatic side effect is risky: explicitly set both values, then make the firewall and router rules match them. Opening only 16261 can leave the server visible without a working player connection. Opening only 16262 leaves Steam discovery and the initial connection path on the wrong port.

How to port forward a Project Zomboid server

Router menus use different names, but the path is always internet to router, router to the server machine, then host firewall to Project Zomboid. Configure every layer in this order:

1. Reserve the server machine's private IP. Give it a DHCP reservation in the router so an address such as 192.168.1.50 does not move after a reboot. A forwarding rule aimed at yesterday's address will quietly stop working.
2. Set both ports in the active ini. Stop the server, then set DefaultPort=16261 and UDPPort=16262 in the ini that belongs to the server name you actually launch.
3. Allow both through the machine's firewall. They are UDP rules, not TCP rules. With UFW, sudo ufw allow 16261:16262/udp opens the pair. In Windows Defender Firewall, create an inbound UDP rule for 16261-16262.
4. Create two router forwarding rules. Forward public UDP 16261 to UDP 16261 at the reserved private IP, then public UDP 16262 to UDP 16262 at the same address. Choosing a combined TCP/UDP rule is unnecessary.
5. Start the server and wait for the world to load. Confirm that the process is listening on both ports before testing the router. If it still listens on the defaults after you chose custom ports, it loaded a different ini.
6. Test from outside the network. Use a phone on mobile data, ask a friend, or use the external port checker. A test from the server machine or the same Wi-Fi does not prove the forward works.

If the router's WAN address is private, or it does not match the public address seen from the internet, there is another NAT layer upstream. That is common with CGNAT and some modem-router combinations. A rule on your own router cannot cross that outer layer: ask the ISP for a public IPv4 address, put the upstream modem into bridge mode when appropriate, or run the server on a host with a public address.

Where the settings live

For a server named servertest, the main file is normally Zomboid/Server/servertest.ini below the server user's home directory. If you launch with -servername gh, the file becomes Server/gh.ini inside the active Zomboid data directory.

That last phrase matters. Project Zomboid has an installation directory containing the executable and a separate data directory containing the ini, world, database, logs, and mods. Editing an ini beside the executable does nothing unless the server was explicitly told to use that location.

The -cachedir syntax that fails silently

The safe form is -cachedir=/srv/project-zomboid/data. The equals sign is required. Unlike -servername gh, writing -cachedir /srv/project-zomboid/data with a space can be ignored. The server then falls back to the default Zomboid directory under the service user's home.

This creates a particularly confusing failure: you edit ports in one ini, start the server, and see a running Java process, but it binds to 16261 and 16262 because it read a different ini. Search the startup log for the cache directory, then check which Server folder changed most recently.

A reliable custom-port example

Suppose the router gives this server UDP 2200 and 2201. Use DefaultPort=2200 and UDPPort=2201 in the same ini. Launch the matching server name with an explicit cache directory, allow UDP 2200 and 2201 through the host firewall, and forward both router ports to the server machine.

The numbers do not technically have to be consecutive, but a consecutive pair is easier to allocate and reason about. What matters is that neither port overlaps another process and every layer uses the same two values.

Running several Project Zomboid servers

Every instance needs its own server name, cache directory, database, and two unique UDP ports. A clean allocation looks like this:

• Server A: DefaultPort 2200, UDPPort 2201
• Server B: DefaultPort 2202, UDPPort 2203
• Server C: DefaultPort 2204, UDPPort 2205

Do not leave every instance on UDPPort 16262 while changing only DefaultPort. The first server will take the RakNet port and the others will fail or behave unpredictably. Give each service its own data directory so worlds, player databases, settings, and Workshop mods cannot bleed into another instance.

How to check what is actually listening

On Linux, run ss -lunp while the server is up and look for both configured UDP ports. On Windows, use netstat -ano -p udp. A process bound to the correct ports proves the application side is ready; it does not prove the router or upstream firewall is forwarding internet traffic.

Test from outside the home network. Connecting from the same LAN can be misleading because some routers do not support NAT loopback. If LAN works and an external client does not, focus on port forwarding, the host firewall, CGNAT, or the public IP rather than reinstalling the game.

Port troubleshooting checklist

• Confirm the server name selects the ini you edited.
• Use -cachedir=/path, not a space after -cachedir.
• Set both DefaultPort and UDPPort explicitly.
• Verify both UDP ports are listening before checking the router.
• Allow both ports in the operating-system firewall.
• Forward both ports to the server machine's current private IP.
• Test from a different network and rule out ISP-level CGNAT.

How GHosting handles the pair

GHosting allocates a non-overlapping two-port span for every Project Zomboid instance. It writes DefaultPort and UDPPort independently, keeps each server in its own cache directory, and verifies that the game reaches a running state before presenting the address. The same configuration path also caps the stock 16 GB Java heap to the RAM actually assigned to the server.

If you are also adding Workshop content, read WorkshopItems vs Mods explained. For the full self-hosting path, see the Project Zomboid dedicated-server guide. Or choose a managed Project Zomboid server with both ports and Workshop handling already wired.