Counter-Strike 2 splits into two worlds that fail differently and are checked differently. Community servers are ordinary Source-engine servers you can query directly. Official matchmaking is Valve infrastructure you cannot query at all, and asking about it is really asking about Steam.
Which one are you asking about? ¶
- A community server with an address you connect to, from a server browser or a
connectcommand. Queryable, and everything below applies. - Official matchmaking, Premier or Competitive, where you queue and Valve assigns a server. Not queryable. If this is failing, it is a Valve or Steam problem, and our Steam status page is the better place to look.
Getting this wrong wastes time: no amount of checking a community server address tells you anything about why matchmaking will not connect.
Checking a community server ¶
CS2 kept the Source query protocol through the move to Source 2, so A2S works exactly as it did in CS:GO. The query port is normally the same as the game port, conventionally 27015 — which makes CS2 simpler than Rust, where the two differ.
Query it with our checker using address:27015. A response carries the hostname, current map, player count and maximum slots. That is a direct measurement from the server itself, not a cached list entry.
In-game diagnostics worth knowing ¶
The console tells you things no external check can:
statusshows the server you are on, your connection state, and the other players.pingand the net graph separate a slow server from a slow connection. Consistent high latency to every server is yours; high latency to one is theirs.- Connection problems that resolve on reconnect but recur are usually packet loss rather than an outage, and a status check will show the server perfectly healthy throughout.
What each outcome means ¶
- Query answers, you cannot connect: the server is up and refusing you. A password, a whitelist, a VAC or game ban, a full server, or a plugin rejecting your client.
- Query answers with a map you do not expect: a map change is in progress. Connections during one often fail and succeed a few seconds later.
- No answer: down, restarting, or the query port is not what you think.
- Everything answers and matchmaking still fails: not a server problem. Steam or Valve backend — check the Steam status.
Updates break connections predictably ¶
CS2 updates are mandatory and community servers need updating separately. In the window between a client update and a server operator applying it, the server is running and your client cannot join it. This is not an outage and no status check will show one; the error is a version mismatch, and the only fix is the operator updating.
For server owners ¶
The A2S query surface is worth two minutes of attention:
- Forward the query port in UDP as well as TCP. Many guides mention only TCP, which leaves a server that plays fine and is invisible to every browser and monitor.
- If
sv_hostnamechanges on every map, some monitors treat it as a different server. Keep it stable. - Rate limiting on A2S is sensible against query floods, but too aggressive a setting makes legitimate monitoring look like an outage. If your own status page flaps, check that first.
The A2S smoke test guide covers what a healthy response looks like field by field.
Ports beyond the game port ¶
A CS2 server can bind more than one, and the extras are worth knowing when a check behaves oddly:
- SourceTV, conventionally 27020. A separate listener for spectators. It answers its own queries, so pointing a check at it reports on SourceTV rather than the game server — they can fail independently.
- RCON, on the game port over TCP. Administrative only, and it should not be exposed publicly; an open RCON port with a weak password is a full server compromise.
If a status check reports healthy while players say the server is gone, confirm which port answered.
sv_lan hides a server completely ¶
With sv_lan 1 the server does not register with Valve's master
servers and will not appear in the internet browser, however healthy it is.
Direct connect still works, which is the distinguishing test: reachable by
address, invisible in the list. It is the most common reason a newly-built
server "does not work" when it is running perfectly.
Reading latency honestly ¶
A2S round-trip time and in-game ping measure different things. The query is a single UDP exchange with the query listener; in-game latency reflects the gameplay path including tick rate and any interpolation. A server can answer queries in 20ms and feel unplayable, and the query will never show it.
This is the same limitation every external check has, and it is worth stating rather than implying otherwise: reachability is not playability. The net graph in-game is the tool for the second question.