Minecraft Java vs Bedrock server status: TCP SLP and UDP/RakNet

Java TCP Server List Ping and Bedrock UDP/RakNet status are different observations, and Bedrock silence stays Unknown rather than Offline.

Last verified: 2026-07-21
Evidence cutoff: 2026-07-20

Direct answer: Java and Bedrock status checks are different observations, not interchangeable “is the server up?” probes. Java status is a short TCP Server List Ping (SLP) that can receive a structured JSON response—or an explicit connection refused from the admitted target. Bedrock status is a UDP/RakNet Unconnected Ping/Pong exchange; UDP has no TCP-style refuse handshake, so timeout or silence is Unknown, not Offline. Using the wrong edition, wrong port family, or collapsing silence into “offline” produces false confidence.

This guide compares the two status paths. It does not announce a live outage, invent player counts, or claim that one edition’s check proves the other.

Side-by-side comparison

Dimension	Java Edition status	Bedrock Edition status
Transport	TCP	UDP (RakNet)
Typical probe	Handshake with next state status (1) → Status Request → Status Response JSON; optional Ping/Pong	RakNet Unconnected Ping → Unconnected Pong with server ID / MOTD string
Common default port	25565 (unless SRV or an explicit port redirects)	19132 (documented Bedrock default; use the host’s configured listen port when it differs)
Positive Online evidence	Parseable, accepted status response within the evidence window	Parseable Unconnected Pong (or equivalent accepted Bedrock status envelope) within the window
Offline (narrow)	Admitted resolved target refuses the TCP status connection	Rarely available as a hard Offline claim from silence alone; product mapping keeps refuse-like semantics TCP-centric
Silence / timeout	Unknown (filtering, wrong path, overload, loss, non-response)	Unknown—UDP silence cannot distinguish offline process, drop, filter, or wrong host/port
What it does not prove	Full login, whitelist, auth, resource packs, tick health	Full login, Xbox/Minecraft token chain, packs, play-state success

Cross-edition mistakes are common: probing a Bedrock host with a Java SLP client, probing Java on 19132, or treating a Bedrock timeout like a Java refuse.

What Java status actually does

On modern Java Edition, Server List Ping is part of the usual client-server protocol but stays on the status path:

Client opens TCP and sends a Handshake with next state status (1).
Client sends a Status Request.
Server replies with a Status Response JSON object (version, players with optional sample, description/MOTD, optional favicon, and related fields).
Optionally, client and server exchange Ping / Pong for a round-trip sample.

That answers: “Did this admitted target answer a Java status probe?” It does not prove gameplay login will succeed.

Useful Java-specific facts for checkers:

When a client is only probing to learn which protocol to use, handshake protocol version is conventionally -1. That is a documented convention, not automatic proof of a broken server.
SRV (_minecraft._tcp...) redirects the connect target host and port; the handshake server-address field can differ by client or tool and must not be described as a universal rewrite.
Operators can set enable-status=false in server.properties. Status replies are suppressed so the multiplayer list can look offline while the server still accepts connections. That is a status-path setting, not proof the play path is dead.

For field-by-field JSON meaning, see Minecraft MOTD and the Java status response. For Online/Offline/Unknown mapping, see Online, Offline, and Unknown explained.

What Bedrock status actually does

Bedrock multiplayer for external servers uses UDP with RakNet, not Java’s TCP stream framing. Default documented Bedrock port is 19132.

List discovery commonly starts with RakNet Unconnected Ping messages. A responsive server answers with Unconnected Pong, which can carry a semicolon-separated server ID string (edition tag, MOTD lines, protocol/version strings, player counts, ports, and related fields). Those fields are self-reported by the pong, the same caution that applies to Java MOTD JSON: they are not an audited census.

Important UDP consequences for status tools:

UDP does not establish a TCP connection, so you do not get a universal “connection refused” signal the way a TCP stack can.
Dropped packets, stateful firewalls that black-hole UDP, asymmetric routes, and rate filters often look identical to “nothing is listening.”
Therefore a Bedrock probe that times out without a valid pong is Unknown, not Offline.

A later full Bedrock join (Open Connection → login/encryption → resource packs → play status) is a different state machine from an Unconnected Ping. Status Online does not certify join success; status Unknown does not prove the world process is stopped.

Conservative result mapping

Use this evidence-first mapping when interpreting a Java or Bedrock status result.

Evidence class	Typical result	Edition notes
Valid status response / accepted pong	Online	Java SLP JSON or Bedrock Unconnected Pong envelope, after framing/schema checks
Admitted-target connection refused	Offline	Strongest on TCP Java status; do not invent Offline from UDP silence
Timeout / no response	Unknown	Especially critical for Bedrock UDP
Reset, closed without status, invalid frame/payload	Unknown	Bytes incomplete or not protocol-valid
DNS unresolved, rate limited, outbound capacity, internal error	Unknown	Observer or resolution limits—not a global outage claim

Unknown is not Offline. Collapsing them hides SRV mistakes, edition mismatches, filtered UDP, and checker-side limits.

Diagnostic flow

Confirm edition before interpreting the label. Java clients and Java SLP tools are not Bedrock RakNet tools. If the community address is Bedrock-only (or the reverse), stop re-running the wrong probe.
Confirm host and port family. Java defaults toward 25565 (plus possible SRV). Bedrock defaults toward 19132. An explicit wrong port is a configuration error, not “Minecraft is down.”
Read Online as path-specific success only. Online means the status method answered from this vantage inside the evidence window. Proceed to join troubleshooting if players still cannot enter.
On Java Offline (connection_refused): Treat refuse as strong for that admitted TCP target and method. Still check reverse proxies, wrong public port, and whether status is refused while another listener accepts play traffic.
On Java or Bedrock Unknown with timeout: Do not rewrite the result as Offline. Branch into wrong edition, firewall/UDP filtering, SRV/DNS, vantage differences, and capacity. See Why a server can look offline while players still join.
If Java looks offline but friends join: Consider enable-status=false, status blocked at a proxy, or status and play on different front ends—status path ≠ join path.
If Bedrock pongs but join fails (or the reverse): Separate Unconnected Ping success from full RakNet login/play-state success. Packs, tokens, and version gates live after the list probe.
Separate status RTT from gameplay feel. Optional Java ping/pong or pong timing is not tick lag. See Minecraft server ping, latency, and timeout.
Never cross-apply one edition’s result to the other. A healthy Java SLP says nothing about a Bedrock port on the same hostname, and a Bedrock pong says nothing about TCP 25565.

Evidence limits

One vantage, one edition method, one evidence window. Results expire; a prior Online is not a live availability promise.
Status success is not whitelist, ban, auth, transfer, or resource-pack success.
Player counts and MOTD/version strings are self-reported by the target’s status/pong payload.
Bedrock UDP silence stays Unknown without stronger proof; do not equate it with Java TCP refuse.
Checker rate limits, DNS failures, and internal errors describe the observer, not a platform-wide outage.
This article does not freeze a current outage or all-clear for any named community server.

Live check

Use the homepage Minecraft server status checker and select the edition that matches the address you are allowed to probe. Interpret the state with Online, Offline, and Unknown explained. For Java response fields, see MOTD and the Java status response.

Last verified

Evidence cutoff: 2026-07-20
Sources rechecked: Minecraft Wiki Server List Ping; Java protocol packets; server.properties (enable-status, ports); Bedrock Edition protocol; RakNet Unconnected Ping/Pong; Minecraft Help network troubleshooting; product Online/Offline/Unknown mapping.