Buried in 26.4 Snapshot 1, under the network protocol section, is a server property that changes how a private Minecraft server can work: allowed-connection-ids.
It lets a server refuse connections – and refuse even to show its status – to anyone who did not arrive with the right string in the address they typed.
What it does
The setting takes a comma-separated list of ids. If it is non-empty, the server checks incoming connections against an _id property in the intention packet, and rejects anything that does not match.
The critical detail is that this applies to status connections as well as login connections. A player without the correct id does not get rejected at the login screen – they do not see the server responding at all.
How does a player supply an id? Through the address field. 26.4 extends the intention packet’s host field so it can carry URI-style query parameters, and the client will parse an address written as id@host into host?_id=id.
So a private server hands out [email protected] instead of example.com, and the plain domain simply appears offline.
Why this is not a whitelist
A whitelist authenticates a player. This authenticates a link.
The practical differences matter. A shared id works for anyone who has it, so it is a group credential rather than an individual one. It can be rotated by changing the property, which invalidates everyone at once. And because it hides the status response, it removes the server from the view of anything that scans for servers, which a whitelist does not.
The protocol notes are explicit about the limit: the intention packet is unencrypted, so these properties should not be used for anything security-sensitive. This is obscurity plus a soft gate, not authentication.
Used correctly it sits alongside a whitelist rather than replacing it – vetting decides who plays, and the connection id decides who can see the server exists.
The address format, in detail
The host field now supports a query string after a ?, with key=value pairs separated by &. Empty values can omit the =. Keys and values are percent-encoded by the standard URI rules, and keys starting with an underscore are reserved for vanilla.
The field was extended to 1024 characters to make room. Players can type properties into any Server Address field in the server list.
There is also an SRV wrinkle worth knowing. If a server uses SRV DNS records and the resolved domain differs from the original, the resolved one becomes primary and the original is attached as an _o origin property. The port field carries the resolved port.
The transfer packet gained a matching properties field, so a server can hand a client to another server with properties attached – which is how a network would pass an id along rather than making the player retype it.
The mod list packet
The same snapshot adds a minecraft:mod_list custom packet payload, sent during the configuration phase, intended to tell servers which mods a client has.
The vanilla client sends it empty, because it does not know about mods – populating it stays the responsibility of the modding platforms. The stated purpose is debugging.
That framing is worth taking at face value and also worth thinking about. A server that receives a reliable client mod list can use it for support, and can equally use it for enforcement. Whether Fabric and NeoForge populate it, and whether players can control what it reports, will decide which of those it becomes.
Two smaller server properties
status-contact-details – a free-text field sent in the status response under a contact property. It exists so a server with no website can still publish a way to reach its owners. Human-readable, no format restrictions.
enable-legacy-status – lets an admin turn off the pre-1.7 status and ping protocol handling. Defaults to true to preserve existing behaviour. Note that enable-status still has to be set for any status information, modern or legacy, to be sent at all.
Turning off legacy status is a small reduction in what an unauthenticated connection can ask the server to do, and there is no reason to keep it on unless something in your setup is genuinely from that era.
What to do with this
- Nothing yet – this is a snapshot and the properties may change before 26.4 releases.
- If you run a private server that currently relies on nobody finding it, connection ids will do that job properly, and the id belongs in the same place you keep the address.
- Do not treat an id as a password. It travels unencrypted and the protocol notes say so.
- Plan for the address format change if you document your server address anywhere – the
id@hostform is what players will need to be given.
For everything else in the snapshot, including the graphics change that will affect more people, the main 26.4 write-up has the list.
And whatever you change, back up before testing a snapshot against a world you care about.
Images: Programmer Art Fix project gallery.