You can join your own server. Your players can join. But MCSrvStat, your server-list entry, and our /minecraft hub all render it offline. Nothing is wrong with the server in the sense you'd expect: it's answering the connections that matter. What's failing is a different, much smaller conversation, and once you know the two are separate the diagnosis takes about a minute.
Joining and being listed are two different protocols ¶
When a client joins, it opens a TCP connection, sends a handshake with next-state 2 (login), and proceeds through authentication into play. When a tracker checks your server, it opens a TCP connection, sends a handshake with next-state 1 (status), and expects a single JSON blob back: MOTD, version, player count, favicon. That's the Server List Ping, or SLP.
Both start identically. They diverge on one byte. So it is entirely possible, and common, for login to work perfectly while status never answers. Anything that can distinguish the two, a plugin, a proxy, an anti-DDoS edge, will happily break one and leave the other alone.
The five causes, in the order worth checking ¶
1. A plugin is suppressing the status response
Anti-bot and anti-scrape plugins routinely drop status pings while allowing logins, on the theory that scrapers only ever send status packets. Look for ServerListPlus, most anti-VPN plugins, and anything advertising "query protection" or "hides your server from crawlers". Some of these ship with suppression on by default.
Fast test: stop the server, start it with no plugins, ping it externally. If it answers, re-add plugins in halves until it stops. This is the single most common cause on servers that were "working last week".
2. enable-status=false in server.properties
Vanilla and Paper both expose this. Setting it to false makes the server refuse status pings entirely, on purpose. Logins are unaffected. It is a one-line fix and a surprisingly common accidental setting, because it sits near enable-query and enable-rcon in the file and people toggle the wrong one while hardening.
3. The tracker is querying a different address than your players use
If your players connect to play.example.com and that resolves through an SRV record to node4.host.example:25612, then a tracker that ignores SRV records will try play.example.com:25565 and find nothing. Your players are fine; the tracker is knocking on a door that doesn't exist.
Check by querying both forms explicitly. If the host:port form answers and the bare domain doesn't, your SRV record is either missing, wrong, or not yet propagated, see how long DNS propagation actually takes. Our DNS lookup tool will show you what's actually published.
4. The proxy answers status from config, and the config is wrong
BungeeCord and Velocity answer status themselves rather than forwarding it to a backend. If the proxy is up but its listener config points at a stale backend, or its MOTD block is malformed, it can return a response that trackers parse as offline while the login path still routes correctly. This is the same family of problem as a server reporting 0/0 players, and worth reading if you run a network.
5. The firewall allows established connections but drops new ones from certain sources
Rate-limit rules that count new connections per source IP will happily let your players through, they connect once and stay, while blocking trackers, which connect from the same address every minute and never hold the connection open. Anti-DDoS providers do this aggressively by default.
Fingerprint: the ping times out rather than being refused. A refused connection means nothing is listening; a timeout means something ate the packet. That distinction is the difference between connection refused and connection timed out, and it's the most useful single signal you have.
The two-minute diagnostic ¶
- Ping from outside your network. Testing from the same LAN as the server proves nothing, you'll bypass exactly the layers most likely to be at fault. Use our /minecraft hub or any external SLP tool.
- Note the failure shape. Refused means nothing is listening on that address and port. Timeout means something dropped it. Empty-but-connected means the server accepted TCP and then declined to answer, which points at a plugin or
enable-status. - Query the raw host:port, bypassing SRV. If that works, the problem is DNS, not Minecraft.
- Restart with no plugins. If that works, it's a plugin, and you now have a bisect to run.
| What the external ping does | Where to look |
|---|---|
| Connection refused | Wrong port, server not bound to a public interface, or the process is down |
| Times out | Firewall or anti-DDoS dropping new connections |
| Connects, then closes with no data | enable-status=false, or a suppression plugin |
| Works on host:port, fails on the domain | Missing or stale SRV record |
| Works externally, tracker still says offline | Tracker cache, wait one refresh interval before chasing it |
Why this matters more than it looks ¶
A server that shows offline on lists loses new players silently. Existing regulars keep joining, so your player count doesn't crater and nothing alerts you, but the discovery funnel is dead. That's the worst class of outage: no error, no complaint, just a slow decline nobody can attribute.
It's also why watching your own SLP endpoint is worth doing even when you're confident the server is fine. If you add it as a monitor, you're checking the exact protocol the trackers use, from outside your network, on a schedule, and you find out the same day rather than the same month.
FAQ ¶
Why does it work in my launcher but not on trackers?
Your launcher sends a real protocol version and, if you added the server by address, follows SRV records. Many trackers send protocol -1 and skip SRV. Both are legal; they just exercise different paths.
Do I need enable-query=true?
No. That's the separate GameSpy-style UDP query protocol, used by some older tools and stats plugins. Standard server lists use SLP over TCP and don't need it. Leave it off unless something specifically asks for it.
Does this apply to Bedrock?
The principle does, the protocol doesn't. Bedrock uses RakNet's unconnected ping over UDP. A Bedrock server can be joinable while its UDP ping is firewalled, and the diagnosis is the same shape: test from outside, and note whether you get a refusal, a timeout, or silence.