> ## Content Index > Fetch the complete content index at: https://hostwolf.net/blog/llms.txt > Use this file to discover other available public pages before exploring further. # Minecraft 26.4 Snapshot Server Properties: allowed-connection-ids, status-contact-details & enable-legacy-status Explained - URL: https://hostwolf.net/blog/minecraft-26-4-snapshot-server-properties/ - Published: 2026-10-05T00:16:07.000Z - Updated: 2026-10-05T01:12:53.000Z - Description: Two September snapshots quietly added three server.properties keys that will matter to server admins. Here's what each one does, the caveats Mojang attached, and whether you should touch 26.4 snapshots yet. - Author: Hostwolf Team - Tags: News, Minecraft, Guides The 26.4 snapshots are here: Snapshot 1 landed on September 22, 2026, and Snapshot 2 followed on September 29\. Between them, the Minecraft 26.4 snapshots added three new `server.properties` keys that dedicated-server admins will care about: `allowed-connection-ids`, `status-contact-details` and `enable-legacy-status`. None are in a stable release yet, and 26.4 itself is only planned for Q4 2026 with no official date. **TL;DR:** these keys are worth learning now, but don't run them in production until 26.4 actually ships. Snapshot servers mean no Paper, no plugins, and one-way world upgrades. Snapshot 1 is the interesting one. It added all three keys, plus a supporting protocol change to how the client sends the server address. Snapshot 2 was bug fixes, render-distance fog changes and a debug screen redesign, with no new properties ([26.4 development versions, minecraft.wiki](https://minecraft.wiki/w/Java%5FEdition%5F26.4/Development%5Fversions?ref=hostwolf.net)). The primary source for everything below is [Mojang's Snapshot 1 changelog](https://www.minecraft.net/en-us/article/minecraft-26-4-snapshot-1?ref=hostwolf.net). One naming note: since the December 2025 numbering change, snapshots are named `26.4-snapshot-1` style rather than the old `25w44a` week-number format. Mojang's sequence is snapshots → `-pre-N` → `-rc-N` → release. Before we go key by key, you need to understand why these keys exist at all. The new host-field parsing is the foundation for everything below. ## The context first: how properties-in-the-server-address work The `host` field in the serverbound `minecraft:intention` packet now carries URI-query-style parameters. (Mojang inconsistently writes `minecraft:intent` and `minecraft:intention` in the same changelog. Same packet, typo, don't let it confuse you.) That means a server address can look like `example.com?key1=value1&key2`, with keys and values percent-encoded per URI rules, and empty values allowed to skip the `=`. The field was also extended to 1024 characters, and players can type these properties into any "Server Address" field. There's a shorthand too: an address like `myid@play.example.com` is parsed as `play.example.com?_id=myid`. The SAS Gaming wiki adds that the id is "any characters before the first @" in the address. That's a community wiki detail, secondhand, but it matches Mojang's example. Keys starting with `_` are reserved for vanilla. `_id` is the one `allowed-connection-ids` matches against. There's also an SRV interaction worth knowing: if an SRV record resolves the address to a different domain, the resolved one becomes the primary and the original is passed along as the `_o` (origin) property. Per the changelog, this addresses the inconsistent SRV behavior Mojang tracks under bug ID MC-278651. Mojang's own warning, quoted exactly: *"Note: since the minecraft:intent packet is unencrypted, properties should not be used for any security-sensitive purpose."* Keep that in mind for everything that follows. One more changelog item for completeness: the `minecraft:transfer` packet gained a `properties` field, a string-to-string map added to the host field sent to the target server. It matters for transfer and proxy setups once 26.4 is stable. ## status-contact-details: the key most admins will actually use In our opinion this is the most useful of the three for community servers. If `status-contact-details` is non-empty, its value is sent in the `minecraft:status_response` packet's JSON under the `contact` property, meaning it shows up in your server list entry. Mojang's stated intent: a human-readable way for players to contact the server owners when there's no website or other info. There are no format restrictions. Our editorial suggestion: a Discord invite or an email address works well. Both are short, both are copy-pasteable, and they solve exactly the problem Mojang describes: players who find your server and have no idea how to reach you. The default is empty (inferred from the changelog, not explicitly documented). One caveat: the contact info only appears when `enable-status=true`. If you run a friends-and-community server with no website, this is the one key worth setting early on the stable release. ## allowed-connection-ids: a lightweight connection filter with one big footgun Quoting the changelog: *"A list of comma-separated ids. If non-empty, the server will match the values against `_id` property in minecraft:intention packet. If there is no match, the server will reject the connection. This works both for both status and login connections, so any user connecting without the correct `_id` in the server address will not see the status and will not be able to join the server."* A worked example (our derivation, not from any source): say you set ``` allowed-connection-ids=friends,alt-night ``` Players then join via `friends@your.server.ip` in the server address field, or the full form `your.server.ip?_id=friends`. Either parses to `_id=friends`, which matches, and they're in. The footgun: because the filter also gates status pings, a wrong or missing id means the server doesn't respond to status at all. Your server shows as dead in the server list. This is by far the most likely misconfiguration. Someone sets the key, forgets to tell their players the id, and spends an evening convinced the server crashed. Clients that get rejected see the message "Connection rejected by server" (per [MC Toolkit](https://mctoolkit.net/blog/minecraft-26-4-snapshot-1?ref=hostwolf.net)). Say it plainly: this is obscurity, not authentication. The id travels unencrypted in the handshake, exactly as Mojang warned. Anyone sniffing the connection or reading the packet format can read it, and anyone can type it. Do not treat this as a replacement for your allowlist. Keep the real allowlist in place. Think of `allowed-connection-ids` as a convenience filter for a semi-private server where you'd rather randos bounce off than go through a ban workflow. Two unknowns we won't guess at: the default value is not documented (empty is inferred), and neither are the allowed characters or length limits for ids. Also unverified: behavior behind Velocity or BungeeCord. Network admins should wait and test at the RC stage, since proxies parse the handshake format themselves. ## enable-legacy-status: housekeeping for old ping tools This is the only one of the three with a documented default: `true`, preserving existing behavior. Setting it to `false` disables the pre-1.7 legacy status/ping protocol handling. It also requires `enable-status=true` for any status info, modern or legacy, to be sent at all. When would you flip it? Our recommendation: only if you're sure nothing in your toolchain still pings with the legacy protocol. Some old server-list bots, dashboards and scanners still do. If a monitoring tool stops detecting your server after you set this, this key is the first suspect. Flip it back and update the tool. Nothing here blocks players; it only affects how very old ping requests are answered. ## Quick reference: the three keys at a glance | Key | Default | What it does | Gates status? | When to use | | ---------------------- | ----------------- | ---------------------------------------------------------------- | --------------------------------- | -------------------------------------------------------- | | status-contact-details | empty (inferred) | Publishes contact info in the status response (contact property) | No | Community servers without a website | | allowed-connection-ids | empty (inferred) | Rejects logins and status pings without a matching \_id | Yes, wrong id = server looks dead | Semi-private friend servers, as convenience not security | | enable-legacy-status | true (documented) | Disables pre-1.7 ping handling when false | Legacy clients only | Admins retiring old ping tooling | Editing reminder for `server.properties`: it's UTF-8, `key=value` lines with `#` comments, and the server rewrites the file on startup, copying existing values and resetting missing or invalid keys to defaults. A restart is required after edits, and back up the file before experimenting. All three are snapshot-only right now and could change before 26.4 ships. ## Testing on a snapshot server: the sane procedure Mojang's own warning applies: testing versions can corrupt your world, so back up and run snapshots in a separate folder from your main worlds. Snapshot worlds upgrade one-directionally to the snapshot's data version. No prompt, no undo, and the only route back is a pre-snapshot backup. Worlds can even break between consecutive snapshots. ![A server tower with faintly glowing internals on a snowy plateau beside a warm orange campfire, cool blue-violet light on the icy cliffs behind](https://hostwolf.net/blog/content/images/2026/10/minecraft-26-4-snapshot-server-properties-img-test-server.webp) A disposable snapshot server: spin one up, test the new properties, then let it go. Framework support first. As of late September, Vanilla and Fabric can run snapshots, while Paper, Purpur, Spigot, Forge and NeoForge haven't published 26.4 snapshot builds; they build releases and release candidates only. That's from a single source (GameServerKings, verified 28 Sep 2026) and worth re-checking against Paper's build API before you rely on it. For now it means no plugins on a snapshot server. To test the new keys specifically: add them to `server.properties`, restart the server, connect using the `friends@ip` shorthand, and check that your server list entry shows your contact details. Then run the broader sanity checks: 1. Back up your production world and configs. 2. Spin up a separate, disposable server. Don't touch production. 3. Copy your configs in. 4. On first boot, read the log for rejected or unknown keys. 5. Walk your farms and redstone builds to check nothing broke. 6. Throw it away when done. If you want a side instance for snapshot testing alongside your production server, [Minecraft server hosting with daily backups and one-click setup](https://hostwolf.net/games/minecraft.html?ref=hostwolf.net) gives you your own machine with one-click restore, which is what you want before touching anything. ## Should you run 26.4 snapshots in production yet? (Verdict: no) No. Wait for the release, or at minimum the release candidates if you're a Paper admin, since Paper builds RCs. Three reasons: no plugin or mod framework support on snapshots, one-way world upgrades, and all three keys are new enough to change before 26.4 ships. On timing, be honest with yourself: 26.4 is planned for Q4 2026 per the wiki, with no official date from Mojang. A December 2026 estimate is floating around based on the roughly 10–14 week snapshot-to-release cadence of 26.1–26.3\. That's a calendar projection, not a Mojang statement. What to do now: nothing on production. Optionally spin up a disposable vanilla or Fabric snapshot server to try `status-contact-details` and see how the contact string looks in the server list. What to watch: if you run Velocity or BungeeCord, you're the group that must keep an eye on 26.4, because proxies parse the handshake format themselves and the extended host field changes what they see. SyntaxMine flags network admins as exactly this group. We'll revisit this article when 26.4 hits release candidates or stable, and update the key details if anything shifts. ## Frequently asked questions ### What do allowed-connection-ids, status-contact-details and enable-legacy-status actually do? allowed-connection-ids rejects connections (status and login) that don't carry a matching \_id in the server address. status-contact-details publishes a contact string in your server's status response. enable-legacy-status=false turns off pre-1.7 legacy ping handling. Only enable-legacy-status has a documented default (true); the other two are empty unless you set them. ### How does a player enter the connection id in their server address? Either the shorthand friends@your.server.ip (parsed as your.server.ip?\_id=friends) or the full query form your.server.ip?\_id=friends. Anything before the first @ is treated as the id. ### Why does my server show as dead in the server list after setting allowed-connection-ids? The filter applies to status pings as well as logins. If the connecting client doesn't send a matching \_id, the server won't respond to status — so the server list shows it as offline. Fix the id in the server address or clear the key. ### Can I use allowed-connection-ids as a whitelist? No. Mojang explicitly notes the minecraft:intent packet is unencrypted, so the id can be read or spoofed. Treat it as a convenience filter for a semi-private server and keep your real allowlist in place. ### Do these new keys work with Velocity or BungeeCord? Unverified. Proxies parse the handshake host field themselves, so behavior behind a proxy isn't confirmed for 26.4 snapshots. Network admins should wait for release-candidate builds and test before relying on any of this.