Fix: Server Doesn't Respond to A2S_INFO Queries

Your server is up, players who know the IP can join, but it shows no data in the browser, monitoring sites report it offline, and query tools time out. That is an A2S_INFO problem: the server is not answering the UDP query that clients and the master list use to read its name, map, and player count. The process is running fine; the query path is broken. Here is how to find where.

1. Know what A2S_INFO is

A2S_INFO is a small UDP request sent to the server's game port (default 27015). The server replies with its hostname, current map, player count, and max players — the data every browser row and monitoring service displays. It travels on the same UDP port as gameplay, so if players can connect but queries fail, the issue is specific to how the query is handled or filtered, not basic reachability.

2. Check the firewall first (the usual cause)

The port must accept inbound UDP from anywhere, not just from IPs that have already connected. A firewall that allows established gameplay traffic but drops fresh query packets produces exactly this symptom. Confirm UDP 27015 (or your port) is open inbound:

# Linux, ufw
sudo ufw allow 27015/udp

# Linux, iptables
sudo iptables -A INPUT -p udp --dport 27015 -j ACCEPT

On a hosted VPS, also open the port in the provider's external firewall / security group — that is a separate layer from the OS firewall and is frequently the one still closed. See which ports a CS 1.6 server needs open.

3. Confirm the bind address and port

If the server bound to the wrong interface or a non-default port, queries to the expected address go nowhere. Check what it is actually listening on:

ss -lunp | grep hlds
# or
netstat -lunp | grep 27015

You want it listening on the port you are querying, on 0.0.0.0 or the correct public interface. If you set -ip or a +port that differs from what monitors query, fix the mismatch. Note that sv_lan does not block queries by itself — but with sv_lan 1 the server never heartbeats the master list, so it stays out of the internet browser regardless of query health. Set sv_lan 0 for a public server.

4. The A2S query-challenge change

To curb reflection/amplification attacks, GoldSrc servers were updated so that A2S_INFO queries must complete a challenge handshake — the server replies with a challenge number that the querier must echo back. Old query tools that send a bare A2S_INFO with no challenge get no reply, which looks exactly like the server being down. ReHLDS implements this correctly and current monitoring services follow the challenge. If only an old homemade script fails while real browsers and monitors work, the script is the problem, not the server — update it to send the challenge.

5. Test the query directly

Query from an external host (not the server itself — localhost can succeed while the public path is blocked). Any A2S tool works; the point is to test from outside your network. If an external query returns the server info, the query path is healthy and the original "offline" report was a stale monitor or a challenge-unaware tool. If it times out from outside but works locally, the firewall or provider security group is dropping the packet.

Troubleshooting

• Players can join but the browser shows no info — query packets are filtered while gameplay is allowed, or the query tool is challenge-unaware. Open UDP inbound broadly and test with a current tool.
• Works from the server, times out externally — provider firewall / security group, or an OS firewall rule scoped too narrowly. Open the port from all sources.
• Never appears in the internet list at all — sv_lan 1, so no heartbeat. Set sv_lan 0; see server not in the master list.
• Only one old monitoring script fails — it does not implement the A2S challenge. The server is fine; update the script.
• Wrong port everywhere — the server bound to a non-default port. Match your monitors to the real port from ss -lunp.

Verification

Confirm the listening socket on the box:

ss -lunp | grep 27015

Then run an A2S query from an outside host and confirm it returns the hostname, map, and player count. Finally, check the server row in the in-game internet browser (with sv_lan 0) populates with live data. When an external query answers correctly, the A2S path is healthy end to end. If clients also cannot even connect, that is a broader reachability problem, not a query-only one.