You ping your server with any standard tool — Minecraft Server List, MCSrvStat, our own /minecraft hub — and it says 0/0 players. You know there are sixty people on right now. The protocol isn't broken; the response is just lying. Four common reasons, in order of likelihood.
1. BungeeCord is reporting itself, not its backends ¶
If your network looks like one proxy in front of N Spigot/Paper servers, you're running BungeeCord (or Velocity, or Waterfall — same family). The proxy answers SLP queries from its own config.yml, not by polling the backends. The default motd + player_limit + online_players values that ship with a fresh BungeeCord install all read 0.
This is not a bug. The proxy doesn't know how many players are on backend-server-3 unless something explicitly tells it. By design, BungeeCord doesn't ask. The fix is one of three plugins (RedisBungee, NetworkManager, or — for Velocity — the built-in player-count forwarding) that aggregate counts and write them back into the SLP response.
How to confirm this is your problem: ping a backend port directly. Find the actual Spigot port (usually 25566+ on the same host), set up an internal SLP query against it, and you'll see real numbers. If the backend reports 23/100 and the proxy reports 0/0, congratulations — you've reproduced the bug, and now you know the fix isn't on the player's side.
2. Version-protocol mismatch (the silent killer) ¶
The SLP handshake includes a protocol version integer. The convention with most query libraries is to send -1, which is "I don't care, just respond." Servers can ignore that and only respond to handshakes that match their own protocol. Hypixel's 1.8 PvP servers do this — a 1.21 client gets an empty response with no players, no MOTD, nothing.
If a server keeps reporting 0/0 only to some third-party trackers but renders correctly in the actual Minecraft launcher, this is almost certainly the cause. The launcher sends a real protocol number; the third-party tool sent -1 and got back garbage.
For owners, there's no fix and no need for one — the in-game multiplayer list works correctly because clients send their actual version. The third-party tools either learn to send a matching protocol or accept that they get blank reads.
3. Sample-list omission with the count blanked along with it ¶
SLP has two player fields: a numeric online/max and a "sample" array of usernames that some servers populate to render the hover tooltip in the multiplayer list. Many hosts blank the sample for privacy — fine. Some take it a step further and zero the numeric count too, often for one of two reasons:
- Anti-DDoS shaping. Some hosts answer SLP from a cache rather than the live server, and the cache stamps zeros to avoid leaking real-time state to attackers.
- Premium/whitelist signaling. A few cracked-compatible servers blank counts so anti-piracy crawlers can't easily build heat maps of which servers are popular.
Easy fingerprint: if MOTD + version are populated correctly but only the player numbers are zero, this is the case. There's nothing for an outside observer to do; the server owner can audit their host's edge cache config or their plugin stack.
4. The server is genuinely empty and you misread the indicator ¶
It happens. Especially on creative SMPs or whitelisted servers — the operator account isn't always counted. Vanilla Minecraft shows you in the player count whether you're a regular user or an op. But some networks (Hermitcraft-style private SMPs, big network testbeds) intentionally exclude staff from the public counter. Check by joining a second account, or asking someone outside the staff list whether they see a non-zero count.
Decision tree ¶
| What the SLP response shows | Most likely cause |
|---|---|
| 0/0, generic MOTD, no version string | BungeeCord with default config |
| 0/0, custom MOTD, version present | Sample-list omission with count blanked |
| Empty everything, just a TCP handshake | Version-protocol mismatch — re-query with the server's actual version number |
| 0/0 only on third-party trackers, correct in client | Same as above — trackers send protocol -1 |
What to do as a server owner ¶
If you're running a network and want third-party trackers to render real numbers — which is most of the reason anyone ever notices the 0/0 — pick one of:
- RedisBungee if you already run Redis. Aggregates counts across the network into a shared key, BungeeCord reads it, SLP responses report the real total.
- Velocity's
player-info-forwarding-modeif you migrate off BungeeCord — Velocity handles aggregation natively without a plugin. - NetworkManager / NetworkInterceptor for plain BungeeCord without Redis, with a tiny in-memory aggregator. Fewer moving parts; works for small networks.
Whichever route, test the result with two independent queries: one in the actual Minecraft launcher, one from outside (our /minecraft hub or any SLP query library). If both show real numbers, you're done. If only the launcher does, you forgot to enable the SLP-write step in your aggregator.
FAQ ¶
Why does Hypixel show players correctly but my own BungeeCord network doesn't?
Hypixel runs a fork of BungeeCord with a custom SLP handler that polls every backend over an internal RPC and stamps the aggregated total into the response. Most public networks do something similar. If you're running stock BungeeCord with no plugin, you're not running what Hypixel runs.
Will fixing the count make my server appear higher on server lists?
It might, but server lists deduplicate aggressively and usually rate-shape based on player retention over an hour, not a single ping. Don't fix this expecting a ranking jolt; fix it because zero is wrong and your players see it on every screenshot they share.
Does any of this affect Minecraft Bedrock?
No. Bedrock's query protocol is different and doesn't go through BungeeCord. Geyser-translated traffic uses Java SLP under the hood, so a Geyser-backed Bedrock proxy inherits whichever Java behavior it sits on top of.