Game Server Ports: Which One Actually Answers a Monitor

Here is a situation that costs game server admins an evening on a regular basis. Players are connected and playing right now. You can see them in the console. You set up an uptime monitor on the port from your connect string, and it immediately reports the server as down. You check the firewall, restart the process, open a ticket with your host, and eventually conclude that monitoring "does not work for game servers."

Monitoring works fine. You were watching a port that was never going to answer.

Game ports do not talk to strangers

A game port carries the game protocol and nothing else. When a monitoring service opens a connection and sends a probe, the server has no reason to respond: the probe is not a valid game packet from a client that has completed a handshake. On UDP there is no handshake to fail, so nothing comes back at all — just silence. Silence is indistinguishable from a dead server, so the monitor calls it down.

Most game engines solve this with a second, separate port whose entire job is answering questions from the outside: the query port. It is what the in-game server browser talks to, what listing sites like BattleMetrics poll, and what a monitoring service should be watching. Ask it for status and it replies with the hostname, current and maximum player count, map and version.

So the rule is short: monitor the query port, not the game port. The rest of this article is the per-game specifics, because the two are not always different numbers, and sometimes they are not even the same protocol.

The one that catches everyone: Rust

Rust is where this trips up the most people, because the game port is the number everyone knows and shares.

• UDP 28015 — the game port. This is in every connect string. It is also completely silent to a status probe.
• UDP 28016 — the query port (game port + 1 by default, controlled by +server.queryport). This one answers.

We measured it against a live, populated Rust server while writing this: a status query to UDP 28015 times out, while the same query to UDP 28016 comes back with 197 bytes of server information. A monitor on 28015 would have shown a permanent outage on a server full of players.

There is a second trap right behind it. Rust's RCON also defaults to 28016, which makes people assume 28016 is "the admin port" and skip it. Both services can share the number because they use different transports: RCON is a TCP WebSocket, the query service is UDP. They do not collide. Monitor UDP 28016 and leave RCON alone — most hosts firewall RCON off from the public internet anyway, so a check on it from outside would sit red forever while RCON works perfectly for you.

Source engine games: CS2, Team Fortress 2, Garry's Mod

Source servers are friendlier: the game port and the query port are usually the same number, UDP 27015, and it answers status queries directly. One port, one check.

The mistake here is not the number but the protocol. Admins habitually set up a TCP check on 27015 because TCP is what port monitoring usually means. On a Source server TCP 27015 is typically closed — the game lives on UDP. We confirmed this on live CS2 and TF2 servers: TCP connections to 27015 time out, UDP queries to the same port answer immediately.

Garry's Mod deserves a footnote. On many GMod hosts TCP 27015 is open, because a control panel or RCON listens there. That makes a TCP check appear to work, which is worse than failing: you end up monitoring the panel rather than the game. If the game process dies while the panel stays up, your check stays green through the entire outage. Use UDP.

The exceptions: Minecraft and FiveM

Not every game hides behind UDP.

• Minecraft (Java Edition), TCP 25565. The Java protocol runs over TCP and includes a status handshake that any client may perform without logging in — that is how the multiplayer list shows you player counts and MOTD before you join. A plain TCP check on 25565 is meaningful here, and a protocol-level status query is better still. Bedrock Edition is the opposite: UDP 19132.
• FiveM (GTA RP), TCP 30120. FiveM exposes a small HTTP endpoint on its main port, which is why you can fetch /info.json and /players.json from a browser. TCP checks work, and an HTTP check gives you even more signal.

Quick reference

If your game is not listed, the reliable way to find the answer is your server's own configuration: look for a queryport, query_port or similarly named setting. If there is one, that is the port to monitor. If there is not, the game port usually doubles as the query port, as with Source.

What "up" actually means on UDP

This part is worth understanding, because it explains why UDP monitoring behaves differently from the TCP checks you may be used to.

TCP has a definitive answer: the handshake either completes or it does not. UDP has no handshake, so a checker has exactly three possible outcomes:

• A reply arrives. The service is alive. This is the only positive proof available on UDP.
• An ICMP "port unreachable" arrives. Nothing is listening. The port is closed.
• Nothing arrives. Ambiguous — the port may be filtered, or the service may simply be ignoring the probe.

Network scanners traditionally report that third case as "open|filtered" and lean towards calling it open. For a monitoring product that is the wrong call, and we tested why: a knowingly closed port on a live host also returns silence, because the ICMP reply gets filtered somewhere along the path. Treating silence as "up" would produce a monitor that is green forever — which is worse than no monitor at all, because you believe you are watching something.

That is why UptyBots requires an actual reply for a UDP port to count as up, and why the probe is a real status query rather than an empty packet. Game servers answer it, so for them the result is exact rather than a guess. The trade-off is that UDP services which stay silent by design — DNS resolvers, VoIP endpoints — are not a fit for this check; those need a protocol-specific query of their own.

Setting it up

The fastest path is to let the free checkers work out the address for you. Enter the connect string you already know — including the game port — and the checker will find the port that actually answers:

• Rust server checker — falls back from 28015 to the query port automatically
• CS2 server checker
• Team Fortress 2 checker
• Garry's Mod checker
• Minecraft (Java) checker
• FiveM checker

Each of them offers to put that exact address under continuous monitoring afterwards, with the right protocol already selected. If the server is down at that moment, the offer still stands — arguably that is the best moment to set it up, since you will be told the second it comes back.

Setting one up by hand is equally fine: create a Port monitor, enter host:port, and switch the protocol to UDP for the games that need it. TCP remains the default, because it is the right answer for most non-gaming services.

The short version

• Game ports are silent by design. Monitor the query port.
• Rust: UDP 28016, not the 28015 in your connect string.
• Source games: UDP 27015 — the number is right, the protocol is what people get wrong.
• Minecraft Java and FiveM are genuinely TCP.
• On UDP, only a reply proves anything. A check that treats silence as success is not monitoring.

Get the port and the protocol right and a game server monitor becomes genuinely useful: you learn about a crash from an alert rather than from your Discord filling up.