Why Is My Minecraft Server Showing Offline on Server Lists?

If a listing site marks your server offline but you can still join in-game, the site's status check couldn't reach your server over the network — and that break is almost always at one findable spot. A listing site checks your server the same way a player's client does: it sends a small packet to your address and port and waits for a reply. If that round trip doesn't complete, you get the offline badge, regardless of whether the server itself is up. An offline badge doesn't touch your vote total — those are tied to your listing for the month and don't move with live status (see how rankings work), so a glitchy status check won't cost you any. A server that's genuinely down for days will naturally earn fewer, but a single failed ping won't subtract a thing.

How a listing site decides your server is online

The standard mechanism is Server List Ping, usually shortened to SLP. It's been part of Minecraft since 1.7, it runs over TCP on the same port players connect to (Java's default is 25565), and it needs no special server-side setup — your server already answers SLP just by being online. Most listing sites use exactly this, so if a site can complete one SLP round trip, your server shows online.

There's a second, optional protocol called Query. It runs over UDP, returns the full player list rather than just a sample, and only responds when you set enable-query=true in server.properties. Query is extra detail, not a requirement — a server that's never had Query enabled still shows online through SLP alone. Don't assume you need it.

Bedrock works a little differently. Bedrock Edition pings over UDP on default port 19132, which is a separate protocol from Java's TCP ping. That distinction matters if your listing is a Bedrock entry or a crossplay setup running Geyser, because the port and protocol the site checks aren't the same as Java's.

If the site's packet can't make a round trip on the right port, you get offline — even when your own client connects fine. That's the whole reason "I can join but it shows offline" happens, and the next step is where most owners find their answer.

Step 1 — Confirm the server is reachable from outside

You joining from the same network proves nothing about whether the rest of the internet can reach your server. A LAN connection takes a shortcut that never leaves your house, so it works even when external access is completely blocked.

Test the outside view directly. An external port checker like canyouseeme.org takes your public IP and port and tells you whether the connection actually lands — open means reachable, closed or timeout means something is dropping the packet before it gets to the server. A public Minecraft status checker works too, and has the advantage of probing the exact address:port your listing uses, so you see roughly what the site sees.

If that external check fails, the problem is reachability, and Steps 2 through 4 are where you fix it. If it passes but the listing is still offline, the server is reachable and the issue is an address or config mismatch instead, so skip ahead to Steps 5 and 6.

Step 2 — Port forwarding (self-hosted servers)

If you're hosting on your own machine, your router drops unsolicited inbound traffic by default. It only passes a connection through when a forwarding rule says "send traffic on this port to this local machine." No rule, no reply, offline badge.

Forward the correct port and protocol. Java is TCP 25565; Bedrock is UDP 19132. If you're running Geyser so both editions connect to one box, forward both. A common miss here is forwarding TCP only and wondering why Bedrock players (and a Bedrock listing) still can't reach you.

Then pin the machine's local IP so the rule doesn't quietly break. Routers hand out local IPs on a lease, and when your server's address changes, the forward rule is still pointing at the old one. Set a DHCP reservation — your router might call it Address Reservation or Static IP by MAC — so the local IP stays put.

If you're on a managed or hosted server, you usually don't touch any of this. The host already exposes the port for you, so jump to the firewall and config steps.

Step 3 — Firewall blocking the ping

Forwarding can be perfect and a firewall on the server machine can still drop the connection silently — no reply, no error.

On Windows, allow Java through Windows Defender Firewall on both the Private and Public profiles, or add an inbound rule for the port. The Public profile is the one people forget, and it's the one that matters for traffic coming off the internet. The process to allow is javaw.exe.

On Linux, check the host firewall — ufw status will show you what's open — and allow the port and protocol you need. If you're on a managed panel, it may have its own firewall layer that needs the port opened separately from the OS.

There's also the ISP. Some residential ISPs block common inbound server ports, 25565 among them. It's not universal, but if everything on your end checks out and the external port test still fails, it's worth testing on a different port to rule it in or out. From the listing site's side a firewalled-off port and a stopped server look identical — both come back as no reply, both render as offline.

Step 4 — enable-query / query.port (only if the site uses Query)

Most sites use SLP and need nothing in this section. But if a particular listing relies on the Query protocol, your server can be perfectly SLP-reachable and still read as offline to that one site.

To support Query, set enable-query=true in server.properties. The query.port value defaults to your server port, so if you run Query on a different port, set it explicitly. Then forward and open that query port as UDP, the same way you handled the main port — Query is UDP, so a TCP-only forward won't carry it.

One caution: don't flip enable-query on as a guess for a generic offline badge. Confirm the site actually asks for Query first. If it doesn't, this step changes nothing and just sends you down a wrong path.

Step 5 — Address, port, and DNS mismatches in your listing

This is the most common reason a reachable server still reads offline: the address or port saved in the listing doesn't match where your server actually answers.

Start in server.properties and check server-ip. It should be blank or set to 0.0.0.0 so the server binds to every interface. A stray value there can pin the server to answering on a single address, which the listing site may not be hitting.

If your listing uses a hostname instead of a raw IP, the site resolves that name through DNS, and DNS is its own pile of ways to point at the wrong place. A wrong or expired A record, a missing or misconfigured SRV record, or a DNS change that hasn't propagated yet can all send the site's ping somewhere your server isn't — even while connecting straight to IP:port works fine.

SRV records are worth a closer look, because they're the usual failure point when your server runs on a non-default port. An SRV record is what lets players and listings use a clean address without typing a port. If the SRV is wrong, the site falls back to probing the default port and misses a server that's actually running on a different one. Check the SRV target host and port carefully.

The action that catches most of these: re-test using the exact address and port stored in the listing, not the one you personally use to connect. If they differ, you've found it — correct the listing or the DNS so the site is pointed where your server actually answers.

Step 6 — Server-icon and MOTD: a display issue, not offline

A missing icon or a blank MOTD is a presentation problem, not the offline badge. Owners burn time chasing reachability when all that's wrong is a cosmetic file, so confirm which one you're actually dealing with first.

For the icon, the spec is exact and unforgiving. The file has to be named server-icon.png — lowercase, hyphen — it has to be exactly 64x64 pixels, a real PNG, and it goes in the server root right next to server.properties. Get any of that wrong and Minecraft silently ignores it. There's no error message, so you won't get a hint; the icon just doesn't show.

If the MOTD isn't appearing, restart the server after editing it, confirm the change actually saved, and strip out any unsupported or garbled formatting codes, which can blank or break the line. If you're rebuilding it from scratch, our MOTD generator outputs a valid motd= line for server.properties.

And give it a minute. Listing sites poll status on an interval rather than watching in real time, so after you fix reachability or an icon or the MOTD, the badge and the rest of your listing details refresh on the next poll cycle — minutes, not seconds. Don't assume the fix failed because nothing changed the instant you saved.

The myth: online-mode does not make you offline on a list

This is the dead-end owners waste the most time on, so here's the short version. The online-mode setting in server.properties controls player authentication — whether the server verifies players against their Mojang accounts. It has nothing to do with whether your server appears online on a listing.

An online-mode=true server and an online-mode=false server respond to Server List Ping exactly the same way. The setting doesn't suppress the ping or hide you from listings. So flipping it won't fix an offline badge, and turning it off introduces security problems you don't want. Leave it where it belongs and keep working the reachability steps instead.

Quick diagnostic checklist

Run this top to bottom:

1. External port check passes? Use a port checker against your public IP and port. Closed or timeout means stop here and fix reachability.
2. Correct port and protocol forwarded? TCP 25565 for Java, UDP 19132 for Bedrock, both if you run Geyser.
3. Firewall allowing it? Windows Defender on Private and Public, the Linux host firewall, and rule out an ISP port block if the rest is clean.
4. Query — only if the site needs it. Don't enable it on a guess.
5. Listing address, port, DNS, and SRV match where the server answers? Test the exact address saved in the listing, not your own.
6. Wait one poll cycle before deciding a fix didn't work.

Once the badge flips back, check your live entry to confirm — if you list a survival server, for instance, it'll show alongside the others on the survival servers page the next time the site polls.

FAQ

Does a proxy like Velocity or BungeeCord change what the listing pings?

It changes where the ping has to land. With a proxy out front, the public-facing address and port belong to the proxy, not to any backend server, so the listing should point at the proxy. The proxy answers SLP on behalf of the network, and your listing's address and port need to match the proxy's exposed port — not the internal port a backend like Paper is bound to. If you forwarded and listed a backend port by mistake, the site pings something that isn't reachable from outside and you get offline.

My host gave me a shared IP with a non-default port — what do I put in the listing?

Put the full IP:port exactly as the host gave it to you, including the non-default port. Shared hosting often runs many servers behind one IP, so the port is what separates yours from everyone else's, and dropping it makes the site ping 25565 by default and miss you. If you want a clean address without the port showing, set up an SRV record that points the hostname at the right target and port, then list the hostname — but only after you've confirmed the raw IP:port reaches the server first.