#AMP-Hosted Project Zomboid Server Not Appearing on Public Server List (Build 42.14)

1 messages · Page 1 of 1 (latest)

light beacon
#

Hello,

I'm currently hosting a Project Zomboid Build 42.14 multiplayer server on a local PC using AMP (Application Management Panel). The server itself appears to be functioning normally — players are able to connect via Direct Connect with no issues, but the server does not appear anywhere in the in-game public server browser, even when searching by name.

Server Environment

Host: Local/home PC

Server Manager: AMP

Game Version: Build 42.14

Visibility: Public

Connection Type: Direct Connect works externally

Server runs and accepts players normally

Networking

Ports have been forwarded on the router and allowed through the firewall:

16261 – UDP (default PZ server port)

16262+ – UDP (player connection ports)

8766 – UDP (Steam port)

27015 – UDP (Steam query port)

Configuration

Relevant server settings:
-Public=true
-Open=true
PublicName: whatever
PublicDescription: testing with baer
SteamVAC=true

Observed Behavior:
-Server launches successfully
-Players can join using Direct Connect
-Server never appears in the public server list
-Searching by name returns no results

What I'm Trying to Determine - I'm trying to figure out whether the issue could be related to:

-Steam query port registration
-AMP not properly advertising the server
-Build 42 server listing behavior
-Incorrect port mapping or port binding
-A missing configuration parameter required for public Steam server registration

If anyone has successfully hosted a Build 42 server through AMP and gotten it to show up publicly, I would appreciate any insight or configuration examples.

Thanks!

vale flame
#

try thats ports

light beacon
#

Whenever I restart the server, this is the traffic I see. It clearly looks like the server is attempting to reach Steam’s master servers, but something about the handshake seems off and the server never ends up appearing in the public list.

I captured the traffic using:

sudo tcpdump -i any 'net 208.64.200.0/22 or net 185.25.180.0/22' -n

Output during server startup:

tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v] for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes

22:27:34.559028 wg0 Out IP 10.100.0.2.59152 > 185.25.183.163.27027: UDP, length 1300
22:27:34.801275 wg0 In IP 185.25.183.163.27027 > 10.100.0.2.59152: UDP, length 1300
22:27:34.962184 wg0 Out IP 10.100.0.2.59152 > 185.25.182.50.27037: UDP, length 1300
22:27:35.079997 wg0 In IP 185.25.182.50.27037 > 10.100.0.2.59152: UDP, length 1300

22:27:35.263696 wg0 Out IP 10.100.0.2.59152 > 185.25.182.50.27037: UDP, length 100
22:27:35.380403 wg0 In IP 185.25.182.50.27037 > 10.100.0.2.59152: UDP, length 55
22:27:35.464937 wg0 Out IP 10.100.0.2.59152 > 185.25.183.163.27027: UDP, length 100
22:27:35.665486 wg0 Out IP 10.100.0.2.59152 > 185.25.182.50.27037: UDP, length 100

22:27:35.707602 wg0 In IP 185.25.183.163.27027 > 10.100.0.2.59152: UDP, length 55
22:27:35.783518 wg0 In IP 185.25.182.50.27037 > 10.100.0.2.59152: UDP, length 55

22:27:35.866238 wg0 Out IP 10.100.0.2.59152 > 185.25.182.50.27037: UDP, length 100
22:27:35.866318 wg0 Out IP 10.100.0.2.59152 > 185.25.183.163.27027: UDP, length 100

22:27:35.982610 wg0 In IP 185.25.182.50.27037 > 10.100.0.2.59152: UDP, length 55
22:27:36.066633 wg0 Out IP 10.100.0.2.59152 > 185.25.182.50.27037: UDP, length 100
22:27:36.109043 wg0 In IP 185.25.183.163.27027 > 10.100.0.2.59152: UDP, length 55

22:27:36.167275 wg0 Out IP 10.100.0.2.59152 > 185.25.183.163.27027: UDP, length 100
22:27:36.184549 wg0 In IP 185.25.182.50.27037 > 10.100.0.2.59152: UDP, length 55

22:27:36.267926 wg0 Out IP 10.100.0.2.59152 > 185.25.182.50.27037: UDP, length 100
22:27:36.385927 wg0 In IP 185.25.182.50.27037 > 10.100.0.2.59152: UDP, length 55
22:27:36.410705 wg0 In IP 185.25.183.163.27027 > 10.100.0.2.59152: UDP, length 55

22:27:36.468468 wg0 Out IP 10.100.0.2.59152 > 185.25.182.50.27037: UDP, length 100
22:27:36.468545 wg0 Out IP 10.100.0.2.59152 > 185.25.183.163.27027: UDP, length 100

22:27:36.585409 wg0 In IP 185.25.182.50.27037 > 10.100.0.2.59152: UDP, length 55
22:27:36.669520 wg0 Out IP 10.100.0.2.59152 > 185.25.182.50.27037: UDP, length 100

22:27:36.710645 wg0 In IP 185.25.183.163.27027 > 10.100.0.2.59152: UDP, length 55
22:27:36.769813 wg0 Out IP 10.100.0.2.59152 > 185.25.183.163.27027: UDP, length 100
22:27:36.787446 wg0 In IP 185.25.182.50.27037 > 10.100.0.2.59152: UDP, length 55

22:27:37.013773 wg0 In IP 185.25.183.163.27027 > 10.100.0.2.59152: UDP, length 55
22:27:37.072467 wg0 Out IP 10.100.0.2.59152 > 185.25.183.163.27027: UDP, length 100

22:27:37.317793 wg0 In IP 185.25.183.163.27027 > 10.100.0.2.59152: UDP, length 55
22:27:37.374535 wg0 Out IP 10.100.0.2.59152 > 185.25.183.163.27027: UDP, length 100

22:27:37.618153 wg0 In IP 185.25.183.163.27027 > 10.100.0.2.59152: UDP, length 55

^C
32 packets captured
33 packets received by filter
0 packets dropped by kernel

**From what I can tell, the server is reaching Steam’s master servers and receiving responses, but the server still does not populate in the public server list.

Does anyone know what part of the registration process might be failing here?**

vale flame
#

show your server-console.txt

light beacon
#

Linux already portforwards based on this rule

#

Here is the full table:

table inet filter {
chain input {
type filter hook input priority filter; policy accept;
}

    chain forward {
            type filter hook forward priority filter; policy drop;
            iifname "wg0" oifname "enp1s0" ip saddr 10.100.0.2 meta l4proto udp accept
            ct state established,related accept
            iifname "enp1s0" oifname "wg0" udp dport { 8766-8767, 16261-16293, 27015 } accept
    }

}

vale flame
#

show log form server-console.txt zomboid. and also check in servertest.ini UPnP=true

light beacon
#

People can already connect externally, (in the original post) UPnP is already set to true. Ill grab the logs now.

vale flame
#

server is running now?

light beacon
#

No

#

You can only connect directly

#

The server does not meet STEAM's criteria and does not populate on PZ server lists

vale flame
#

just show log server-console.txt, maybe we'll see something there

#

This error is confusing

[S_API] SteamAPI_Init(): Loaded local 'steamclient.so' OK.
Setting breakpad minidump AppID = 108600
SteamInternal_SetMinidumpSteamID:  Caching Steam ID:  76561197960265728 [API loaded no]

and this

[S_API FAIL] Tried to access Steam interface SteamNetworkingUtils004 before SteamAPI_Init succeeded.
#

in settings server upnp is true?

light beacon
#

Yes

#

People can externally connect via DIRECT connect

#

even steam browser shows it, but it doesnt show up in the internet games tab

vale flame
#

write when starting server

light beacon
#

its been on

vale flame
#

ok. try to set upnp in settings server to false and check

light beacon
#

I

#

Am

#

Already

#

Port

#

Forwarding

vale flame
#

Sometimes you need to tell the game itself that you have everything done so that it doesn't try to do it itself.

junior musk
#

Can you share the server IP and server name so I can check its visibility?

light beacon
#

Ofc, give me a sec

junior musk
#

Since it looks like it worked perfectly fine 9 hours ago

light beacon
#

I’m at work at the moment, and I turned the PC off before I left. It’s its own standalone server, but yeah, it was visible on battle metrics but 8766 and 8767 UDP’s do not work, preventing the server from being listed publicly through Steam, but allowing direct connect externally in the favorites tab via IP search

junior musk
#

Battlemetrics just pulls from Steam

#

If its listed on Steam, its listed on Battlemetrics

#

Let me know once its online so I can check for any user error, such as missing any of the filters

light beacon
#

Sounds good, I’ll msg you when I’m back

light beacon
#

Check DM’s

junior musk
#

Is the server up at this moment?

light beacon
#

I dont know what I did

#

but I rebuilt the entire thing from scratch and it works now

#

I'm not sure where the handshake was going wrong but It populates now

#

TLDR

#

IT WORKS