How Game Server Queries Work: A2S and Beyond

Every server list you have ever browsed is doing the same small trick, over and over, thousands of times an hour. It sends a tiny packet to a machine somewhere, waits a moment, and reads back a short reply that says: here is my name, here is my map, here are twelve people playing out of thirty-two slots. That reply is the entire foundation of the listing. The rank, the player graph, the little green dot next to the name — all of it descends from a few hundred bytes that a game server chose to emit.

Understanding what that exchange actually is will change how you read every server page you visit. It explains why a server you know is running shows as dead. It explains why some player counts are obviously fabricated and others are not. It explains why your favourite game might never appear on a list at all, no matter how many people ask for it.

The status endpoint is not the game

The first thing to get straight is that querying a server has almost nothing to do with playing on it.

When you connect to a game server, you go through a long, stateful, game-specific handshake. You authenticate, you download or verify content, you get assigned a slot, and from then on you are exchanging a continuous stream of position updates and events until you disconnect. That process is expensive, it is particular to the game, and it usually will not tolerate a stranger poking at it.

A query is the opposite. It is a single small request that says, roughly, "describe yourself," and a single small response that answers. No authentication. No session. No slot consumed. The server does not care who you are and does not remember you afterwards. It is closer to a vending machine returning a printed receipt than to a conversation.

Game developers built this deliberately, because the alternative is unworkable. If the only way to find out whether a server had space was to join it, browsing would mean connecting to dozens of servers in sequence and being kicked from most of them. So the server exposes a second, much cheaper surface that anybody can read, and the in-game browser — along with every third-party list, JoinGG included — reads that surface instead.

This separation is why a server can be perfectly healthy and completely invisible. The game is one component. The status endpoint is another. They usually live in the same process, but they fail independently, and one of them going quiet does not stop the other from working.

Query port and game port

Here is where most confusion starts.

The port you connect to when you play is not always the port that answers queries. Sometimes they are the same number, sometimes the query listener sits on a different port entirely, and sometimes it is the game port with a fixed offset applied. Which of these applies depends on the game, on the server software, and on how the host configured it.

There is a reasonable engineering story behind the split. The two listeners have very different traffic profiles. Game traffic is a small number of long-lived, high-frequency connections. Query traffic is a large number of one-shot requests from strangers, many of them automated, some of them abusive. Keeping them separate lets an operator rate-limit, firewall, or filter one without touching the other. It also means an attacker hammering the public status endpoint is not directly interfering with the packets that carry player movement.

The practical consequence for you as an operator is that opening the game port is not enough. A depressing number of servers that "will not show up on any list" are configured correctly for play and have simply never had the query port opened on the firewall, or have it bound to a local interface where nothing outside the machine can reach it. Players can join by direct connect. Lists see nothing. The server appears offline to the entire outside world while a full lobby plays on it.

If you are hosting behind NAT, this bites twice, because you need the forward on both ports and it is easy to set up the one you tested by joining and forget the one you never see. When people ask why nobody is joining their server, an unforwarded query port is near the top of the list of causes, well ahead of anything to do with content or marketing.

What comes back

The shape of the response varies by protocol, but the useful fields are broadly consistent, because everybody wants the same things from a browser.

You get a hostname — the display name the operator set, which is free text and can say anything at all. You get the current map or world. You get a current player count and a maximum, which is what drives the "12/32" you see in listings. You usually get some flag for whether a password is required, and often whether anti-cheat is enabled. There is normally a game or mod identifier so the browser knows which category the server belongs in.

Beyond that, most protocols carry a bag of extra key-value data that the operator or the server software populates. Version strings, tags, region hints, gamemode names, website URLs. Lists lean on these heavily for filtering and categorisation, which is also why they are inconsistent — the fields are conventions rather than guarantees, and different server software populates them differently.

Some protocols will also return a player list: names, scores, and connected time for each person currently on. This is genuinely useful and also genuinely optional. Plenty of servers disable it for privacy, plenty of others return it in a mangled state because a plugin is injecting fake entries, and on a busy server it is a much larger response than the basic status reply, which makes it a more attractive target for abuse. Treat a missing player list as normal rather than suspicious.

The protocol families

There is no single standard. There are several, each tied to a lineage of games, and they do not interoperate.

A2S: Valve's Source and GoldSrc games

The most widely deployed family in the dedicated-server world is Valve's A2S set of queries, used across their Source engine titles and the older GoldSrc engine that preceded it. It is a small collection of related request types: one that returns the server's basic information, one that returns the connected players, and one that returns the server's public configuration variables.

This is the protocol behind status for Counter-Strike 2, Counter-Strike: Source, Team Fortress 2, Garry's Mod, Left 4 Dead 2 and Day of Defeat, along with Half-Life, the original Counter-Strike 1.6, and their long tail of community servers. It also covers plenty of non-Valve games built on those engines or deliberately made compatible with them, Rust among them.

A2S is old, well documented, and consequently very well supported. Almost every server list, monitoring tool and Discord bot you will encounter speaks it. Its age also shows: it has accumulated compatibility quirks, compressed and multi-packet responses for larger payloads, and a challenge-response step that was strengthened over the years after the plain version was abused for reflection attacks. Anyone who has written an A2S client has a story about a server that responds in a slightly nonstandard way.

Minecraft's Server List Ping

Minecraft has its own thing entirely, and it is architecturally quite different. Rather than a separate lightweight service, the status request rides the same connection protocol the game itself uses, entering a distinct status state instead of proceeding to login. The client opens a connection, declares its intent is status rather than play, and receives a structured response back.

That response carries the MOTD, the version string, the online and maximum player counts, an optional sample of player names, and often a base64-encoded server icon — which is why Minecraft listings can display a per-server image where most other games cannot. There is also a ping exchange used to measure latency.

Because the status handshake includes a protocol version number, Minecraft status responses can tell you something other protocols usually cannot: whether the server will actually accept the client version you are running. This is why Minecraft listings can helpfully say "1.21" next to a server, and it is one reason the choice of server software — Paper, Purpur, Fabric and the rest shows up so visibly in listings. Different software reports itself differently, and some of it modifies the status response in ways vanilla never intended.

There is also an older, simpler legacy ping that predates this, kept alive for compatibility with very old clients. Most tooling still implements both, because there are still ancient servers out there answering only the old one. If you are setting up a first server, the good news is that status responses work out of the box on nearly every distribution — the usual failure is network reachability, not configuration.

FiveM's HTTP endpoints

FiveM went a different route again, and it is the most modern of the three approaches: the server exposes its status over plain HTTP. You make a request to a documented path on the server and get back structured JSON with the server's information, and another path returns the connected players.

This has real advantages. JSON is trivially parseable, HTTP tooling is universal, and the response can carry arbitrarily rich structured data — a full set of server variables, resource lists, tags, and more — without the packet-size gymnastics that binary UDP protocols require. It is also easier to debug, because you can open the endpoint in a browser and read it.

The cost is that it moves with the platform. FiveM's server builds change, and behaviour around these endpoints has shifted across versions, which occasionally breaks tooling that assumed an older shape. If you run a FiveM server and your listing status has gone strange after an update, artifact updates and how they affect server queries is the specific thing to read, because this is a recurring and well-understood category of problem rather than a mystery.

Everything else, including nothing at all

Beyond these three families there are many smaller protocols. Older titles from certain publishers used shared middleware for their master server and query systems. Various engines ship their own bespoke status listener. Some modern games expose a status API through the publisher's backend rather than from the server process itself.

And then there is the large and growing category that matters most: games with no public query protocol whatsoever.

This is increasingly common, and it is a deliberate design choice rather than an oversight. If a game ships without dedicated servers, or with servers that are only reachable through the publisher's matchmaking layer, there is simply no endpoint for an outside party to ask. The server may not even have a stable address. It may be spun up on demand for a single session and destroyed afterwards.

The consequence is absolute and worth stating plainly: if a game has no query protocol, no server list can honestly report live status for it. Not with more effort, not with a better crawler, not with a clever workaround. The information does not exist outside the publisher's own systems. Any site showing you live player counts for such a game is either using a private arrangement with the publisher, or making it up.

What this means when you read a listing

Once you know how the data arrives, the failure modes stop being mysterious.

A running server showing as offline. This is almost always the query path, not the game. The port is not forwarded, a firewall rule changed, a DDoS mitigation layer is dropping the query packets as suspicious, or the server software's query listener crashed while the game kept running. Ironically, protection measures are a common cause — filtering rules aimed at stopping DDoS traffic against a small server can be aggressive enough to eat legitimate query packets from listing services, since those look structurally similar to reflection-attack probes. Your players connect fine and the list sees a corpse.

Player counts that are not real. Here is the uncomfortable structural fact: the server writes its own response. Nothing in any of these protocols verifies that the number a server reports bears any relation to the number of humans on it. A server that wants to claim ninety-eight players out of a hundred can simply say so, and there is no cryptographic or protocol-level way for the querying party to catch it.

There are two common flavours. Some server software supports "fake players" or bot padding as a documented feature, on the theory that a server showing activity attracts more real joiners than an empty one does. Other operators run plugins built specifically to inflate counts on public listings. Either way, the query response is a claim, not a measurement, and it is a claim made by the party with the strongest incentive to exaggerate.

Some signals are harder to fake than others. A server that reports a player list can be checked for internal consistency — do the names look plausible, do their connected times and scores change between polls in ways real players would produce, or do they sit frozen. A count that never moves, or that moves in suspiciously round patterns, tells you something. None of this is proof, but it separates the careless liars from the careful ones.

Direct querying versus republished claims. This is the single most useful distinction to hold in your head when comparing server lists, and it is not always visible from the outside.

Some lists query servers themselves, on their own schedule, from their own infrastructure. They see the raw response, they measure their own latency, they know when a server stopped answering and for how long, and they can compare what a server says now against what it said an hour ago. That history is where most anti-inflation work happens.

Other lists take a feed. The server, or the operator, or an intermediate service, pushes numbers to the list and the list displays them. This is cheaper to run and scales beautifully, and it also means the list has no independent knowledge of anything. It is a noticeboard. If the feed says four hundred players, the page says four hundred players.

Neither approach is dishonest by itself, but they produce very different products, and the difference only shows up in edge cases — exactly the cases where you care. The broader question of what makes a server listing trustworthy comes down largely to this: does the site know things, or does it repeat things.

Games that will never be listed. When someone asks why a popular title has no server list, the answer is usually that it has no dedicated servers and no query protocol. The absence is not neglect. There is nothing to query.

Polling, latency, and why numbers lag

Lists do not query continuously. Each query costs a packet out and a packet in, multiplied across every server tracked, so there is always an interval — every few minutes for most servers, more often for large or popular ones, less often for servers that have been unresponsive for a while.

This means the count you see is a snapshot from some point in the recent past, not a live reading. On a server with high turnover, the real number moves considerably between polls. When a listing and the in-game browser disagree, the most likely explanation is simply that they polled at different moments.

Latency figures deserve similar scepticism. A ping shown on a listing is measured from wherever the list's querying infrastructure sits, which is not where you sit. It is useful for comparing servers against each other on the same list, and close to meaningless as a prediction of your own connection quality. A server that reads as forty milliseconds on a listing might be four hundred from your house.

Timeouts also complicate the picture. A server that fails one poll is not necessarily down — packets get lost, especially UDP ones, and especially when the server is under load. Reasonable lists retry before marking anything offline, which means status changes lag reality in both directions.

Understanding this rhythm helps a lot when you are actually trying to find a good server to play on. Look at whether a server sustains players across many observations rather than at one impressive number, because sustained population is much harder to fake than a single inflated reading.

For operators

A few things follow directly from all of the above, if you run a server and want it to appear correctly.

Verify your query port from outside your own network, not from the machine and not from your LAN. Binding to localhost while thinking you have bound to all interfaces is the classic error, and it is invisible from where you are testing.

Keep your reported slot count honest and sane. A server advertising hundreds of slots it cannot fill reads as a red flag to experienced players and often sorts badly. The question of how many slots you actually want is worth thinking through properly, because it affects both your hosting bill and how your listing reads.

Set your hostname field with care. It is free text, it is the first thing anyone sees, and it is one of the few parts of the response entirely under your control. Cramming it with symbols and keywords to game sort order is a strategy with a short shelf life, because lists notice.

Do not pad your player count. Beyond the ethics, it is a bet that no one will compare your claims against observed reality over time, and that bet gets worse as lists get better at exactly that comparison. Real growth compounds; inflated numbers get delisted.

And when you are budgeting, remember that query traffic is real traffic. A popular server fields a constant background of status requests from lists, bots and players' browsers. It is small per request and not nothing in aggregate, which is one of the quieter line items in a hosting bill.

Frequently asked questions

Why does my server show as offline when people are playing on it right now? Almost certainly your query port is unreachable from outside. The game port and the query port are separate, and a server can accept players perfectly while its status endpoint is firewalled, unforwarded, bound to the wrong interface, or being filtered by DDoS protection. Test the query port from a machine outside your network.

Can a server lie about its player count? Yes, completely. The server composes its own query response, and no query protocol verifies that the number corresponds to real connected humans. Some server software offers fake-player padding as a feature. This is why lists that query directly and track history over time can catch things that a list republishing whatever it is told cannot.

What is the difference between the query port and the game port? The game port carries actual gameplay traffic for connected players. The query port answers small public status requests from browsers, lists and monitoring tools. Depending on the game they may be the same port, a fixed offset apart, or independently configurable. Both need to be reachable for a server to be both playable and visible.

Why is my favourite game not on any server list? Most likely it has no public query protocol, or no dedicated servers at all. If sessions are brokered entirely through the publisher's matchmaking and never expose a queryable address, there is nothing for a list to ask, and no amount of engineering on the list's side changes that.

Do queries slow down my server? Individually, no — a status response is tiny compared to gameplay traffic. In aggregate on a popular server it is a steady background load, and unfiltered query endpoints have historically been abused for reflection attacks, which is why modern protocols added challenge-response steps and why operators sometimes rate-limit the query port.

Why does the listing show a different player count than the in-game browser? Polling intervals. Neither number is live; both are snapshots taken at different moments, and on a busy server the real count moves between them. Persistent large gaps are worth questioning. Small disagreements are just timing.

Does a missing player list mean something is wrong? No. Returning the player list is optional and many operators disable it deliberately, for privacy or to reduce response size. Its absence is normal. A player list that is present but obviously synthetic — frozen names, implausible scores, times that never advance — is the thing worth noticing.

Is the ping shown on a server list my ping? No. It is measured from the list's own infrastructure to the server. Use it to compare servers against each other within the same list, not to predict your own connection. Your actual latency depends on where you are, and can differ enormously.