Launch sale20% off everything — celebrating the launch of GHosting!
← All guides

Project Zomboid Server Ports: 16261, 16262 and the -cachedir Trap

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.

A fortified Project Zomboid base running on a persistent dedicated server 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.

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.