Minecraft 26.4 Snapshot Server Properties: allowed-connection-ids, status-contact-details & enable-legacy-status erklärt

Die 26.4-Snapshots sind da: Snapshot 1 erschien am 22. September 2026, und Snapshot 2 folgte am 29. September. Zwischen ihnen fügten die Minecraft 26.4-Snapshots drei neue server.properties-Schlüssel hinzu, die Dedicated-Server-Admins interessieren werden: allowed-connection-ids, status-contact-details und enable-legacy-status. Keiner davon ist bisher in einer stabilen Version enthalten, und 26.4 selbst ist nur für Q4 2026 geplant, ohne offizielles Datum.

TL;DR: Diese Schlüssel sind jetzt schon lernenswert, aber setze sie im Produktivbetrieb erst ein, wenn 26.4 tatsächlich released wird. Snapshot-Server bedeuten kein Paper, keine Plugins und Upgrades der Welt nur in eine Richtung.

Snapshot 1 ist der interessante: Er führte alle drei neuen Schlüssel ein, ergänzt durch eine unterstützende Änderung im Protokoll, wie der Client die Server-Adresse sendet. Snapshot 2 enthielt dagegen nur Bugfixes, Anpassungen beim Nebel bei der Sichtweite und ein Redesign des Debug-Bildschirms – ohne neue Eigenschaften (26.4 development versions, minecraft.wiki). Die primäre Quelle für alles Weitere ist Mojangs Changelog zu Snapshot 1.

Ein Hinweis zur Benennung: Seit der Nummerierungsänderung im Dezember 2025 heißen Snapshots im 26.4-snapshot-1-Stil statt im alten Format der Wochennummer 25w44a. Mojangs Sequenz lautet: Snapshots → -pre-N → -rc-N → Release.

Bevor wir uns die Schlüssel einzeln ansehen, musst du verstehen, warum diese Schlüssel überhaupt existieren. Das neue Parsing des Host-Feldes ist die Grundlage für alles Folgende.

Der Kontext zuerst: Wie funktionieren Eigenschaften in der Server-Adresse?

Das host-Feld im serverbound-minecraft:intention-Paket trägt nun Parameter im URI-Query-Stil. (Mojang schreibt inkonsistent minecraft:intent und minecraft:intention im selben Changelog. Gleiches Paket, Tippfehler, lass dich nicht verwirren.) Das bedeutet, eine Server-Adresse kann so aussehen: example.com?key1=value1&key2, mit prozentual codierten Schlüsseln und Werten gemäß URI-Regeln, wobei leere Werte erlaubt sind, um das = zu überspringen. Das Feld wurde zudem auf 1024 Zeichen erweitert, und Spieler können diese Eigenschaften in jedes „Server Address“-Feld eingeben.

Es gibt auch eine Kurzform: Eine Adresse wie [email protected] wird als play.example.com?_id=myid geparst. Das SAS Gaming Wiki ergänzt, dass die ID „alle Zeichen vor dem ersten @“ in der Adresse ist. Das ist ein Detail aus einem Community-Wiki, zweiter Hand, aber es stimmt mit Mojangs Beispiel überein.

Schlüssel, die mit _ beginnen, sind für Vanilla reserviert. _id ist derjenige, gegen den allowed-connection-ids abgeglichen wird. Es gibt auch eine SRV-Interaktion, die man kennen sollte: Wenn ein SRV-Eintrag die Adresse auf eine andere Domain auflöst, wird die aufgelöste zur Primären und die ursprüngliche wird als _o (Origin)-Eigenschaft weitergegeben. Laut Changelog behebt dies das inkonsistente SRV-Verhalten, das Mojang unter der Fehler-ID MC-278651 verfolgt.

Mojangs eigene Warnung, wörtlich zitiert: „Hinweis: Da das minecraft:intent-Paket unverschlüsselt ist, sollten Eigenschaften nicht für sicherheitsrelevante Zwecke verwendet werden.“ Behalte das im Hinterkopf für alles, was folgt.

Noch ein Changelog-Eintrag zur Vollständigkeit: Das minecraft:transfer-Paket erhielt ein properties-Feld, eine String-zu-String-Map, die zum Host-Feld hinzugefügt wurde, das an den Zielserver gesendet wird. Dies ist relevant für Transfer- und Proxy-Setups, sobald 26.4 stabil ist.

status-contact-details: der Schlüssel, den die meisten Admins tatsächlich nutzen werden

Unserer Meinung nach ist dies der für Community-Server nützlichste der drei Schlüssel. Wenn status-contact-details nicht leer ist, wird sein Wert im JSON des minecraft:status_response-Pakets unter der Eigenschaft contact gesendet, was bedeutet, dass er in deinem Serverlisten-Eintrag erscheint.

Mojangs beabsichtigter Zweck: Eine menschenlesbare Möglichkeit für Spieler, die Serverbesitzer zu kontaktieren, wenn es keine Website oder andere Infos gibt. Es gibt keine Formatbeschränkungen. Unser redaktioneller Vorschlag: Ein Discord-Invite oder eine E-Mail-Adresse funktioniert gut. Beide sind kurz, beide sind kopier- und einfügbar, und sie lösen genau das Problem, das Mojang beschreibt: Spieler, die deinen Server finden und keine Ahnung haben, wie sie dich erreichen können.

Der Standardwert ist leer (aus dem Changelog abgeleitet, nicht explizit dokumentiert). Eine Einschränkung: Die Kontaktinfo erscheint nur, wenn enable-status=true gesetzt ist.

Wenn du einen Freunde-und-Community-Server ohne Website betreibst, ist dies der eine Schlüssel, den es wert ist, frühzeitig auf der stabilen Version zu setzen.

allowed-connection-ids: ein leichtgewichtiger Verbindungsfilter mit einer großen Fallgrube

Zitat aus dem Changelog: „Eine Liste kommagetrennter IDs. Wenn nicht leer, wird der Server die Werte gegen die _id-Eigenschaft im minecraft:intention-Paket abgleichen. Wenn keine Übereinstimmung vorliegt, lehnt der Server die Verbindung ab. Dies funktioniert sowohl für Status- als auch für Login-Verbindungen, sodass jeder Benutzer, der ohne die korrekte _id in der Server-Adresse verbindet, den Status nicht sieht und nicht dem Server beitreten kann.“

Ein durchgerechnetes Beispiel (unsere Ableitung, nicht aus einer Quelle): Nimm an, du setzt

allowed-connection-ids=friends,alt-night

Spieler verbinden sich dann über [email protected] im Server-Adressfeld oder in der vollständigen Form your.server.ip?_id=friends. Beide Varianten werden zu _id=friends aufgelöst, was übereinstimmt, und sie sind drin.

Die Stolperfalle: Da der Filter auch Status-Pings steuert, bedeutet eine falsche oder fehlende ID, dass der Server gar nicht auf Statusabfragen antwortet. Dein Server wird in der Serverliste als tot angezeigt. Dies ist bei weitem die häufigste Fehlkonfiguration. Jemand setzt den Schlüssel, vergisst aber, seinen Spielern die ID mitzuteilen, und verbringt einen Abend damit, überzeugt zu sein, der Server sei abgestürzt. Clients, die abgewiesen werden, sehen die Meldung „Verbindung vom Server abgelehnt“ (siehe MC Toolkit).

Klartext: Das ist Obskurität, keine Authentifizierung. Die ID wird unverschlüsselt im Handshake übertragen – genau wie Mojang gewarnt hat. Jeder, der die Verbindung mitliest oder das Paketformat analysiert, kann sie lesen, und jeder kann sie eingeben. Betrachte dies nicht als Ersatz für deine Allowlist. Behalte die echte Allowlist aktiv.

Sieh allowed-connection-ids als praktischen Filter für einen halb-privaten Server, bei dem du lieber zufällige Spieler abweisen möchtest, als den Umweg über eine Ban-Workflow zu gehen.

Zwei Unbekannte, bei denen wir nicht raten: Der Standardwert ist nicht dokumentiert (Leer wird angenommen), ebenso wenig wie erlaubte Zeichen oder Längenlimits für IDs. Auch nicht verifiziert: Das Verhalten hinter Velocity oder BungeeCord. Netzwerk-Admins sollten warten und erst im RC-Stadium testen, da Proxies das Handshake-Format selbst parsen.

enable-legacy-status: Hausaufgaben für alte Ping-Tools

Dies ist der einzige der drei Werte mit einem dokumentierten Standard: true, was das bestehende Verhalten erhält. Wenn du ihn auf false setzt, wird die Behandlung des Legacy-Status-/Ping-Protokolls vor 1.7 deaktiviert. Zudem erfordert dies enable-status=true, damit überhaupt Statusinformationen – modern oder legacy – gesendet werden.

Wann würdest du ihn umschalten? Unsere Empfehlung: Nur wenn du sicher bist, dass nichts in deiner Toolchain noch mit dem Legacy-Protokoll pingt. Einige alte Server-List-Bots, Dashboards und Scanner tun dies noch. Wenn ein Monitoring-Tool deinen Server nach der Einstellung nicht mehr erkennt, ist dieser Schlüssel der erste Verdächtige. Schalte ihn zurück und aktualisiere das Tool.

Hierdurch werden keine Spieler blockiert; es betrifft nur die Antwort auf sehr alte Ping-Anfragen.

Schnellreferenz: Die drei Schlüssel auf einen Blick

Bearbeitungshinweis für server.properties: Es ist UTF-8, key=value Zeilen mit # Kommentaren, und der Server schreibt die Datei beim Start neu, kopiert vorhandene Werte und setzt fehlende oder ungültige Schlüssel auf Standards zurück. Ein Neustart ist nach Änderungen erforderlich, und sichere die Datei vor Experimenten.

Alle drei sind aktuell nur für Snapshots verfügbar und könnten sich vor dem Release von 26.4 ändern.

Testen auf einem Snapshot-Server: das vernünftige Vorgehen

Mojangs eigene Warnung gilt auch hier: Testversionen können deine Welt beschädigen, also sichere sie und führe Snapshots in einem separaten Ordner von deinen Hauptwelten aus. Snapshot-Welten werden nur in eine Richtung auf die Daten-Version des Snapshots aktualisiert. Keine Rückfrage, kein Rückgängig, und der einzige Weg zurück ist eine Sicherung vor dem Snapshot. Welten können sogar zwischen aufeinanderfolgenden Snapshots kaputtgehen.

Framework-Unterstützung zuerst. Stand Ende September können Vanilla und Fabric Snapshots ausführen, während Paper, Purpur, Spigot, Forge und NeoForge keine 26.4-Snapshot-Builds veröffentlicht haben; sie bauen nur Releases und Release Candidates. Das stammt aus einer einzigen Quelle (GameServerKings, am 28. Sep. 2026 verifiziert) und es lohnt sich, das vor der Nutzung gegen die Paper Build API zu überprüfen. Das bedeutet vorerst: Keine Plugins auf einem Snapshot-Server.

Um gezielt die neuen Schlüssel zu testen: Füge sie zu server.properties hinzu, starte den Server neu, verbinde dich über die friends@ip-Abkürzung und prüfe, ob der Eintrag in deiner Serverliste deine Kontaktdaten anzeigt. Führe danach die allgemeineren Grundprüfungen durch:

1. Sichere deine Produktionswelt und Konfigurationen.
2. Erstelle einen separaten Server zum Wegwerfen. Fass die Produktionsumgebung nicht an.
3. Kopiere deine Konfigurationen hinein.
4. Lies beim ersten Booten das Log auf abgelehnte oder unbekannte Schlüssel.
5. Geh deine Farmen und Redstone-Bauten durch, um zu prüfen, ob nichts kaputtgegangen ist.
6. Wirf ihn weg, wenn du fertig bist.

Wenn du eine Side-Instanz für Snapshot-Tests neben deinem Produktionsserver willst, gibt dir Minecraft Server Hosting mit täglichen Backups und One-Click-Setup deine eigene Maschine mit One-Click-Restore, was genau das ist, was du brauchst, bevor du irgendetwas anfässt.

Solltest du 26.4-Snapshots schon in der Produktion betreiben? (Urteil: nein)

Nein. Warte auf das Release oder zumindest die Release Candidates, wenn du ein Paper-Admin bist, da Paper RCs erstellt. Drei Gründe: Keine Plugin- oder Mod-Framework-Unterstützung auf Snapshots, einseitige Welt-Upgrades und alle drei Schlüssel sind neu genug, um sich vor dem Release von 26.4 zu ändern.

Sei ehrlich zu dir selbst bezüglich des Timings: Laut Wiki ist 26.4 für Q4 2026 geplant, ohne offizielles Datum von Mojang. Eine Schätzung für Dezember 2026 kursiert basierend auf dem ca. 10–14 Wochen langen Zyklus von Snapshot zu Release bei 26.1–26.3. Das ist eine Kalenderprojektion, keine Aussage von Mojang.

Was du jetzt tun solltest: Nichts in der Produktion. Optional erstelle einen wegwerfbaren Vanilla- oder Fabric-Snapshot-Server, um status-contact-details auszuprobieren und zu sehen, wie der Kontaktstring in der Serverliste aussieht.

Was du beobachten solltest: Wenn du Velocity oder BungeeCord nutzt, bist du die Gruppe, die 26.4 genau im Auge behalten muss, da Proxies das Handshake-Format selbst parsen und sich das erweiterte Host-Feld ändert, was sie sehen. SyntaxMine stuft Netzwerk-Admins genau als diese Gruppe ein. Wir werden diesen Artikel revisiten, wenn 26.4 Release Candidates oder stabil erreicht, und die Schlüsseldetails aktualisieren, falls sich etwas verschiebt.

Häufig gestellte Fragen

Was bewirken allowed-connection-ids, status-contact-details und enable-legacy-status eigentlich?

allowed-connection-ids lehnt Verbindungen (Status und Login) ab, die keine passende _id in der Server-Adresse enthalten. status-contact-details veröffentlicht eine Kontaktzeichenkette in der Statusantwort deines Servers. enable-legacy-status=false schaltet die Legacy-Ping-Behandlung vor Version 1.7 ab. Nur enable-legacy-status hat einen dokumentierten Standardwert (true); die anderen beiden sind leer, solange du sie nicht setzt.

Wie gibt ein Spieler die Connection-ID in seiner Server-Adresse ein?

Entweder die Kurzform [email protected] (geparst als your.server.ip?_id=friends) oder die vollständige Query-Form your.server.ip?_id=friends.. Alles vor dem ersten @ wird als ID behandelt.

Warum zeigt mein Server in der Serverliste tot an, nachdem ich allowed-connection-ids gesetzt habe?

Der Filter gilt sowohl für Status-Pings als auch für Logins. Sendet der verbindende Client keine passende _id, antwortet der Server nicht auf Status-Anfragen – die Serverliste zeigt ihn daher als offline an. Korrigiere die ID in der Server-Adresse oder lösche den Schlüssel.

Kann ich allowed-connection-ids als Whitelist verwenden?

Nein. Mojang weist explizit darauf hin, dass das minecraft:intent-Paket unverschlüsselt ist, sodass die ID gelesen oder gefälscht werden kann. Betrachte ihn als praktischen Filter für einen halbprivaten Server und behalte deine echte Allowlist bei.

Funktionieren diese neuen Schlüssel mit Velocity oder BungeeCord?

Unbestätigt. Proxies parsen das Handshake-Host-Feld selbst, daher ist das Verhalten hinter einem Proxy für 26.4-Snapshots nicht bestätigt. Netzwerk-Admins sollten Release-Candidate-Builds abwarten und testen, bevor sie sich auf irgendetwas hier verlassen.