Bedrock Support

Connect lets Bedrock players join connected endpoints through the same public addresses Java players already use:

• <endpoint>.play.minekube.net
• custom domains attached to the endpoint
• endpoint routing through the Connect network

For Connect-routed players, Bedrock translation is handled by the Connect edge before traffic reaches your connector. That means the usual Connect setup stays the same for Paper/Spigot, Velocity, BungeeCord, and Gate connectors.

Managed default

Microsoft/Xbox-authenticated Bedrock players can join Connect endpoints without owning or linking Java Edition. If an authoritative Java link exists, Connect preserves the linked Java profile; otherwise it uses the player's verified native Bedrock/XUID identity. No Bedrock-specific server configuration is required.

Support Behavior Matrix

Setup	What to configure	Bedrock translation	Backend Floodgate API	Online-mode and account behavior	Custom domain coexistence
Connect-managed Bedrock with Paper/Velocity/Bungee connector	Install the Connect plugin normally. Do not enable backend Gate bedrock: true for Connect-managed Bedrock.	Connect edge	Supported only for the compatibility data Connect forwards. If a plugin expects a local Floodgate/Geyser runtime, collect logs and plugin names.	Java online-mode stays on the Java path. Microsoft/Xbox-authenticated Bedrock players do not need a linked Java account by default.	Supported. Bedrock and Java can use the same endpoint subdomain or custom domain.
Connect-managed Bedrock with standard Gate connect enabled	Enable the Gate Connect connector normally. Do not add local Bedrock settings only for Connect players.	Connect edge	Same Connect-managed compatibility behavior as plugin connectors.	Microsoft/Xbox-authenticated Bedrock players do not need a linked Java account by default. Do not switch the backend to offline mode only for Bedrock.	Supported. Connect addresses and custom domains stay shared.
self-hosted Gate direct Bedrock	Add bedrock: true to the standard Gate instance that Bedrock clients join directly.	Your Gate instance	Local Gate/Floodgate behavior belongs to that Gate setup, not Connect-managed Bedrock.	Follow Gate's direct Bedrock and account-linking requirements.	Use a separate direct Bedrock hostname or port unless you intentionally route that hostname outside Connect.
Standard Gate with both Connect and direct Bedrock	Enable Connect for Connect addresses and bedrock: true only for the separate direct Bedrock listener.	Connect edge for Connect addresses, Gate for the direct Bedrock address	Diagnose by join address. Connect-managed joins use Connect compatibility data; direct joins use local Gate behavior.	Ask which address the player used before changing online-mode or linking settings.	Supported when DNS clearly separates Connect-routed names from direct Gate names.
Gate Lite behind Connect	Configure Gate Lite as a Java connector behind Connect.	Connect edge	Treat backend Floodgate API reports as Connect-managed compatibility reports.	Gate Lite is not the direct Bedrock authority; keep auth decisions in the backend/proxy path.	Supported for Connect-routed endpoint domains.
Gate Lite as a direct Bedrock listener	Use standard Gate instead.	Not supported in Gate Lite	Not supported.	Not supported.	Not supported.

Connect-Routed Bedrock

Use this path when players join through Connect addresses such as <endpoint>.play.minekube.net, minekube.net, or a custom domain attached to your endpoint.

For Bedrock clients, add the same Connect hostname as the server address and use the normal Bedrock port 19132. For example:

• Server Address: <endpoint>.play.minekube.net
• Port: 19132

If you attached a custom domain to the endpoint, Bedrock players can use that custom domain with port 19132 too. This is a player-facing Connect edge port. It does not mean you need to open UDP 19132 on your home network, VPS, backend server, or connector host.

You do not need to:

• install Geyser on your backend
• install Floodgate on your backend
• open a local UDP Bedrock port
• set bedrock: true in your backend Gate just for Connect players

This applies to the Connect Java plugin and to Gate used as a Connect connector.

Do not enable backend Gate bedrock: true for Connect-managed Bedrock. That setting is for self-hosted Gate direct Bedrock listeners and can create a second Bedrock path that support then has to diagnose separately.

Direct Self-Hosted Gate Bedrock

Use this path when Bedrock players connect directly to a Gate address you operate yourself, outside the Connect network. In that case, standard Gate can manage Bedrock locally:

bedrock: true

With that setting, Gate starts and manages the Bedrock translation runtime for direct Bedrock clients. This local setting does not change how Connect-routed Bedrock players are handled.

Domains

Connect domains are shared by Java and Bedrock players. If a custom domain already routes Java players to your endpoint, Bedrock players use the same domain after it is attached to the endpoint in the dashboard. Java clients normally use the Java port 25565; Bedrock clients normally use the Bedrock port 19132.

Use a separate direct Bedrock address only when you intentionally run local Bedrock support on your own standard Gate instance.

Account Linking and Online Mode

Connect-routed Bedrock players arrive through the managed Bedrock path and are represented through the compatibility layer before they reach your connector. The default endpoint policy accepts a Microsoft/Xbox-authenticated Bedrock identity without requiring a linked Java Edition account. This is separate from generic offline-mode Java access.

• With an authoritative account link, the endpoint receives the linked Java identity.
• Without a link, the endpoint receives a stable profile derived from the verified Bedrock XUID.
• Without valid Microsoft/Xbox authentication, the managed Bedrock session is rejected.

See the complete player identity matrix for the corresponding Java and offline-Java paths.

The exact rejection reason identifies the component that needs attention:

• policy_linked_java_only means the endpoint has an explicit linked-Java-only policy override. Connector settings such as bedrock-identity.enforcement cannot change this edge policy. Include the endpoint name when asking Minekube support to review an unexpected override.
• scope_unavailable means Connect cannot resolve a usable endpoint/organization identity scope. Reinstalling Geyser or changing backend online mode will not repair endpoint ownership.
• capability_unavailable means the selected connector did not prove the required Bedrock identity capability. Update to a compatible connector build. Identity keys, URLs, and capability settings are automatic for the managed service; changing backend authentication does not repair a missing connector capability.

If you are troubleshooting online-mode behavior, first identify whether the player joined through a Connect address or a direct self-hosted Gate Bedrock address. The required configuration is different for those two paths.

Keep online-mode decisions tied to the whole Java forwarding topology. A Connect-managed Bedrock report is not, by itself, a reason to disable online-mode or allow offline-mode players on the backend.

Connect-managed Bedrock identity uses official Microsoft/Xbox Bedrock authentication at the Connect edge. It is not a Minekube password system, it is not backend Geyser authentication, and it is not the same thing as allowing generic offline-mode Java players. The connector can enforce the Bedrock identity that Connect already verified, while Java online-mode players continue to use the normal Java session path.

Bedrock Identity Enforcement

For Connect-routed Bedrock, the Connect edge verifies the player's Microsoft/Xbox Bedrock identity and signs a short-lived identity envelope before forwarding the session to your connector. Gate verifies this envelope before opening the player tunnel. The Connect Java Plugin also provides a verifier for the managed handover.

Gate checks the signature, expiry, endpoint and organization scope, session binding, and replay protection before admitting the Bedrock identity. Minekube publishes the current and previous verification keys for automatic key rotation. These are public verification keys; private signing keys stay at the Connect edge.

For the normal managed service, install or update your connector and keep its defaults. You do not need to configure identity URLs, copy keys, or declare capabilities. Current Connect Java releases also supply the legacy identity defaults when that section is absent from an older configuration file. Explicit identity overrides remain operator-controlled.

Gate version compatibility

Gate v0.74.28 and earlier do not include automatic verification of the managed v1 Bedrock handover. Upgrade to Gate v0.74.29 or later for automatic Connect Bedrock identity support. Keep the normal Connect configuration and enable Bedrock on your Connect endpoint; no identity settings are needed. Configuring v2 identity keys on an older Gate build does not make it compatible with the managed v1 handover.

Custom Watch services and explicit signed-principal v2 deployments use their own trust configuration. See the Connect Java identity reference for those advanced deployments. They are separate from the normal managed setup.

What a Bedrock player looks like at your backend

A Connect-managed Bedrock player has no Java Edition account, so the endpoint receives a profile that Connect derives from the player's verified Xbox identity. Both parts have a fixed shape for every unlinked Bedrock player, and both are intentional:

• Username: _<gamertag>. The Connect edge applies the configured Bedrock username prefix . to the gamertag, and Connect normalizes the result into [A-Za-z0-9_], capped at 16 characters, so that every backend implementation accepts the login name. That is why the prefix reaches your backend as _, and why every space or non-ASCII character in the gamertag is encoded to _ as well. A gamertag like icedRyan appears as _icedRyan, and .LLG icedRyan appears as _LLG_icedRyan.

  The Java account alphabet is the narrower [A-Za-z0-9_], but what constrains a proxy-supplied login name is the backend server's own validation, not one Java-wide rule: Paper's check also accepts . and rejects spaces, while vanilla's check is only the [A-Za-z0-9_] alphabet, and both cap the name at 16 characters. Connect normalizes into the vanilla alphabet because it cannot know which implementation a backend runs, so the . prefix is not a way to hand a dot to a backend that validates names the vanilla way.

• UUID: a stable RFC 4122 version-5 UUID derived from the verified Bedrock XUID (the established XUID namespace, SHA-1 hashed with the version-5 and variant bits applied). It deliberately does not look like a Mojang UUID, so a version-5 value such as xxxxxxxx-xxxx-5xxx-yxxx-xxxxxxxxxxxx is the normal form and not a defect. The same XUID always produces the same UUID, so bans, permissions, economy entries, and other UUID-keyed data stay attached to the same player on every reconnect and on every endpoint.

Two properties of that UUID matter when you are debugging:

• It is an identifier, not a secret and not a signature. Seeing it in logs is expected.
• Do not rewrite it. Connect checks the profile UUID of the Bedrock session against the XUID-derived value before it hands the signed Bedrock identity to your connector, so a component that substitutes a different UUID makes Connect reject the session instead of fixing anything.

No action is required for either value. If a backend plugin rejects the player because the username or UUID is not a Mojang one, that plugin is the thing to adjust. Rewriting the UUID or switching the backend to offline mode does not make a Connect-managed Bedrock join produce a Mojang identity.

Floodgate's 00000000-0000-0000-XUID key is a different identifier

Geyser and Floodgate identify a Bedrock connection with a second value: the XUID placed in the low 64 bits of an otherwise zero UUID, conventionally written 00000000-0000-0000-XUID. That value belongs to a local Geyser + Floodgate runtime. A Connect-managed join does not deliver it to your backend.

This is why UUID-keyed data does not follow a player from a plain Geyser + Floodgate setup into Connect on the first join. Both identifiers are stable and both come from the same verified XUID, but they are different values, and no Connect setting renames one into the other.

Backend Floodgate API Compatibility

Some backend plugins query Floodgate-style player metadata to decide whether a player is from Bedrock, linked to Java, or allowed past a login step. Connect-managed Bedrock forwards compatibility data for supported paths, but servers can still fail when a plugin assumes it is talking to a local Floodgate/Geyser installation.

When Floodgate-dependent behavior fails, ask for:

• the exact join address the Bedrock player used
• connector type and version
• backend server type and version
• Floodgate, Geyser, auth, or login plugin names and versions
• the kick text and logs from Connect, the connector, proxy, and backend around the same timestamp
• whether the same player succeeds through a direct self-hosted Gate Bedrock address, if one exists
• whether bedrock-identity.enforcement is disabled, warn, or require
• Bedrock identity warnings such as missing envelope, invalid signature, expired identity, replayed nonce, policy mismatch, endpoint mismatch, or organization mismatch

Do not recommend installing backend Geyser/Floodgate or enabling Gate bedrock: true unless the user wants to operate a separate self-hosted Gate direct Bedrock path.

Do not ask users to paste signed Bedrock identity envelopes, private keys, account tokens, or full player profile dumps into public support channels. The useful support data is the join address, connector version, endpoint ownership, relevant timestamps, sanitized logs, and the exact rejection reason.

Discord support response draft

Connect-managed Bedrock is separate from self-hosted Gate Bedrock. If your player joins through <endpoint>.play.minekube.net, minekube.net, or a custom domain attached to the endpoint, Bedrock clients should use that hostname with port 19132. Do not install backend Geyser/Floodgate, open local UDP 19132, or enable backend Gate bedrock: true just for that player. Connect handles Bedrock translation at the edge. If a Floodgate-dependent plugin rejects the player, send the join hostname, connector type/version, backend type/version, Floodgate/Geyser/auth plugin versions, the exact kick text, and logs from the Connect connector/proxy/backend at the same timestamp. Only use bedrock: true when Bedrock clients connect directly to your own standard Gate instance outside Connect. Unlinked Bedrock accounts are accepted by the default Connect endpoint policy; if the kick reason is policy_linked_java_only, include the endpoint name so Minekube support can review its explicit policy override.