Start by comparing one failed join with the server's log at the same time. “Getting server info” describes the client's current stage; it does not identify a broken firewall, a corrupted world or a particular mod. Reinstalling everything loses useful evidence and may leave the original cause untouched.
This guide covers Steam PC clients and an existing Linux dedicated server. Paths follow our Ubuntu setup guide: account pz, home /srv/pz, installation /srv/pz/server, server name servertest. Substitute your actual account and paths. Build 42 is already available on the public branch; compare the full version printed by each running program rather than relying on an old guide's branch label.
Find out whether one client or one server is affected#
Try two controlled comparisons without editing the world. Can the affected client join another compatible vanilla server? Can another player join yours? Note the time, destination address, connection port and visible message for each attempt. A failure affecting every server points toward that client's environment or Steam path; a failure affecting every player on one server points toward that server or its network.
Use the appropriate address. On the same LAN, try the server's private address. From another network, use its public address. 127.0.0.1 always means the computer running the client. A public-address test from inside your own LAN may depend on router hairpin NAT, so it is a poor substitute for an external test.
An administrator's support discussion recommends testing another Steam Download Region when multiple servers fail. Treat this as a reversible comparison: record the original region and restore it if the result is unchanged. It does not repair an unreachable dedicated server.
Establish that the server finished starting#
In a separate SSH session, inspect the data actually used by the process:
sudo -iu pz sh -c 'id; printf "%s\n" "$HOME"; ls -ld "$HOME/Zomboid" "$HOME/Zomboid/Logs"'
sudo -iu pz find /srv/pz/Zomboid/Logs -maxdepth 2 -type f -printf '%TY-%Tm-%Td %TH:%TM %p\n'
sudo ss -lunp 'sport = :16261 or sport = :16262'
These are observations, not a readiness test. Open the current log identified by its timestamp and inspect the startup and failed-join interval. A Java process can still be initializing, downloading Workshop content or failing before networking becomes ready. A UDP socket can exist before a player can enter the world.
Look for the first relevant error, then inspect the lines before it. Distinguish Steam initialization failure, Workshop download failure and world-loading failure. Do not replace the last visible line with an assumed diagnosis. In a Build 42 report on the developer's forum, installation layout mattered; that single resolution does not make moving every installation the general cure.
Match builds before changing network settings#
Read the client version and the dedicated server's startup version, including the minor release. Compare their selected Steam branches as well. “Both Build 42” is insufficient when one side runs a newer unstable release.
For a Build 41 world, retain its compatible server installation and select the publisher-documented legacy41 branch for clients. Check dedicated app 380870 branch availability separately rather than assuming it shares every client branch. For a new Build 42 world, align the public builds. The branch and world guide explains the separation. Do not update the only installation over an old world merely to see whether the handshake changes.
If a version change is needed, make an intact stopped backup first. Keep configuration, world and account databases together, plus the matching installation. A newer executable failing to read an old world is a compatibility investigation, not evidence that the world should be deleted.
Verify both UDP paths, one boundary at a time#
For the default configuration, inspect only the relevant non-secret settings:
sudo -iu pz sed -n '/^DefaultPort=/p; /^UDPPort=/p; /^Public=/p' /srv/pz/Zomboid/Server/servertest.ini
sudo ufw status verbose
The usual pair is DefaultPort=16261 and UDPPort=16262. The developer's support explanation identifies both as UDP. If your generated configuration differs, follow its actual values. Avoid copying old per-player TCP ranges.
Check the host firewall, provider firewall and, for a home server, forwarding to the correct private host. A router rule pointing at yesterday's DHCP address can look correct while delivering traffic elsewhere. Double NAT requires checking both routers; carrier-grade NAT requires a reachable address or a UDP-capable alternative.
A TCP “port checker” cannot validate these UDP paths. Neither does a quiet UDP scan establish that they are closed. Use a real external client attempt and correlate it with server-side evidence. If LAN works and external access fails, concentrate on that boundary rather than resetting the world.
Isolate mods without damaging the original save#
If the log stops during content loading, prepare a separate test world with the same build, empty server mod lists and a different server name. Stop the original server before any test that would reuse its ports. Preserve its complete data and configuration; never remove mods from the only copy of a world that depends on them.
A successful vanilla join narrows the investigation to the selected content or its configuration. Reintroduce a small dependency-complete group in the isolated test and compare the first new error. The Workshop troubleshooting guide separates download IDs from loaded components.
After correcting the fault, join the intended world with a normal player account, disconnect and reconnect. Keep a short record of the matching builds, tested addresses and final result. If support is still needed, provide that record with redacted log excerpts; omit passwords, access tokens and player account databases. That evidence is more useful than another full reinstall.
