What Is a Minecraft Server Scanner and What Can It Do?

Updated

A Minecraft server scanner is a tool that probes Minecraft servers to report whether they are online and what they expose publicly — typically version, player counts, MOTD, and latency. It is useful when you want to check a known server's status, compare a shortlist of servers, or discover publicly listed servers. It is not a way to find private servers, and it should only be pointed at servers that are public or that you have permission to query.

Browsing a server list vs. actively scanning

These two activities are often lumped together, but they answer different questions.

Server list browsing Active scanning / probing
What you do Open a directory of publicly submitted servers and filter or sort it Send a status query to a specific host and port
What you get A catalog: names, tags, versions, rough player counts A live response from that server right now
Best for Finding new servers to try Verifying a server is up and what it reports
Freshness Depends on how often the list is updated Current at the moment of the query

A directory such as the Java and Bedrock server lists linked from Dankware's portal is a browsing resource: it points you at servers other people have listed. A scanner is the probing step — it tells you what a particular server says about itself when asked.

What a status query usually returns

Most scanners rely on the same public status handshake the game client uses. A typical result includes:

  • Online status — whether the server answered at all.
  • Version — the protocol or version string the server advertises.
  • Players — online count and the maximum, and sometimes a sample of names.
  • MOTD — the server's short description, which often carries formatting codes.
  • Latency — round-trip time to the server, useful for judging playability from your location.
  • Software hints — some servers reveal the server software or plugins in their response.

Bedrock servers use a different query (the RakNet ping) and return a similar but not identical set of fields, so a Java-only tool will not see Bedrock servers and vice versa.

A practical workflow

  1. Pick your targets. Start from a public list, or enter a hostname and port you already know. Java defaults to 25565; Bedrock defaults to 19132.
  2. Query one server first. Confirm the tool reaches it and returns a sensible response. If it times out, check the port and whether the host is reachable from your network.
  3. Batch the rest. Scan your shortlist and record status, version, players, and latency together so you can compare like with like.
  4. Verify before you commit. Re-query anything you plan to join, especially if results were cached or collected earlier.

Common snags

  • Timeouts on a server that is clearly up. Wrong port, a firewall blocking the query, or the server hiding its status response.
  • Player counts that look wrong. Some servers report inflated or placeholder numbers, or hide the player sample.
  • Version strings that don't match. Proxies and cross-version setups often advertise something different from what you'd expect.
  • Stale results. Any list or cached scan reflects the moment it was taken; servers go down, change ports, or wipe.

Limits worth knowing

Scan results are self-reported by the server, so treat them as claims rather than facts. A server can return a status response while refusing connections, or report a player count that has nothing to do with reality. Cross-check with a second query, a different tool, or by actually connecting.

On the ethics side: querying a public server's status is the same thing the game client does when you add it to your list, and it's generally fine. Repeated high-volume probing of servers you don't own, or scanning address ranges to enumerate hosts, is a different matter — stick to servers that are publicly listed or that you have permission to test.

If you want a starting point, Dankware's portal collects Java and Bedrock server lists alongside its developer tools, which makes it a reasonable place to source targets before you run your own checks.