Minecraft Ressourcenpack auf dem Server einrichtenEigene Optik für alle Spieler - automatisch geladen

Veröffentlicht am 9. August 2026 · zuletzt aktualisiert am 2. September 2026

Wie der Mechanismus funktioniert

Wichtig zum Verständnis: Der Minecraft Server hostet das Pack nicht. Er teilt dem Client beim Verbinden nur zwei Dinge mit - eine URL, unter der die Datei liegt, und optional eine Prüfsumme. Der Client lädt das Pack dann selbst herunter.

Daraus folgt: Du brauchst einen Ort, an dem die .zip-Datei per direktem Link erreichbar ist. Es reicht nicht, sie auf den Gameserver zu legen - dessen Dateien sind nicht per HTTP abrufbar.

Geeignet ist jeder Ort, der einen unveränderlichen Direktlink liefert, etwa ein Webspace. Ungeeignet sind Freigabelinks, die auf eine Vorschauseite führen statt direkt auf die Datei.

Zur Einordnung: Ein Datapack wirkt rein auf dem Server und liegt in dessen Weltordner, ein Ressourcenpack ist reine Client-Sache. Und das Server-Icon wiederum ist eine einzelne Datei im Serververzeichnis. Drei Dinge, die gern durcheinandergeraten, weil sie alle „irgendwie die Optik" betreffen.

Der richtige Ablageort für die Datei

Ob eine URL taugt, prüfst du in einer halben Minute: Öffne sie in einem privaten Browserfenster. Startet sofort der Download der .zip, ist der Link brauchbar. Erscheint stattdessen eine Seite mit Vorschau, Anmeldung oder Wartehinweis, bekommt der Minecraft-Client genau diese Seite geliefert - und meldet ein defektes Pack.

• HTTPS und ein fester Pfad. Keine Weiterleitungsketten und keine Links, die nach ein paar Tagen ablaufen.
• Dateiname ohne Leerzeichen und Umlaute. Das erspart Kodierungsprobleme in der Konfigurationszeile.
• Dauerhaft erreichbar. Ist der Ablageort weg, sehen neue Spieler die Standardoptik - bei require-resource-pack=true kommen sie gar nicht erst herein.
• Versionierter Dateiname. pack-v4.zip statt pack.zip macht jedes Update eindeutig und umgeht alte Zwischenspeicher.

Ein Webspace erfüllt all das und liegt in derselben Hand wie der Server. Der Gameserver selbst kommt dafür nicht in Frage: Seine Dateien erreichst du per SFTP und über den WebFTP-Dateimanager, aber nicht über HTTP - dort hört an der festen Server-Adresse aus IP und Port nur Minecraft zu, kein Webserver.

Einträge in der server.properties

Drei Werte steuern das Verhalten - alle in der server.properties:

resource-pack=https://example.com/pack.zip
resource-pack-sha1=<SHA-1-Pruefsumme>
require-resource-pack=false

• resource-pack - der Direktlink zur ZIP-Datei.
• resource-pack-sha1 - die Prüfsumme der Datei. Ohne sie lädt der Client das Pack bei jedem Verbinden neu herunter.
• require-resource-pack - auf true wird das Pack zur Pflicht; wer ablehnt, kommt nicht auf den Server.

Nach Änderungen ist ein Neustart nötig. Die Prüfsumme ermittelst du lokal mit einem SHA-1-Werkzeug - unter Windows etwa über certutil -hashfile pack.zip SHA1.

Prüfsumme bei jedem Update erneuern

Der mit Abstand häufigste Fehler im laufenden Betrieb: Das Pack wird aktualisiert, die SHA-1 bleibt stehen.

Die Folge ist tückisch - Spieler bekommen weiterhin die alte, zwischengespeicherte Fassung, oder das Laden schlägt fehl, weil Datei und Prüfsumme nicht zusammenpassen. Beides sieht nach einem defekten Pack aus, ist aber nur ein veralteter Hash.

• Nach jeder Änderung am Pack die SHA-1 neu berechnen und eintragen.
• Alternativ die Datei unter neuem Namen ablegen und die URL anpassen - dann greift kein alter Zwischenspeicher.

Pflicht oder freiwillig?

Die Entscheidung über require-resource-pack hat spürbare Folgen:

Pflicht ist sinnvoll, wenn das Pack Spielinhalte trägt - etwa Custom-Item-Modelle, ohne die ein Server-Konzept nicht funktioniert. Für reine Texturpakete ist freiwillig die freundlichere Wahl. Halte das Pack klein: Jedes Megabyte ist Wartezeit beim ersten Verbinden.

Was Spieler sehen, wenn etwas klemmt

Der Server verrät dir wenig, denn das Laden passiert beim Spieler. Umso hilfreicher ist es, die Sicht von dort zu kennen:

• Abfrage beim Verbinden. Der Client fragt, ob das Paket geladen werden soll. Wer ablehnt, spielt mit Standardoptik weiter - oder wird abgewiesen, wenn das Pack Pflicht ist.
• Fehlgeschlagener Download. Der Spieler landet trotzdem auf dem Server, sieht aber die normalen Texturen. Genau deshalb fällt ein kaputter Link oft tagelang niemandem auf - außer den Spielern, die sich über fehlende Custom-Modelle wundern und es für einen Fehler auf ihrer Seite halten.
• Langer Hänger beim Beitritt. Sehr große Pakete lassen den Verbindungsaufbau stehen. Für Spieler ist das nicht von einem Verbindungsfehler zu unterscheiden.
• Bedrock-Spieler bleiben außen vor. Wer über Crossplay beitritt, bekommt ein Java-Ressourcenpack in aller Regel nicht zu sehen - die Bedrock-Edition nutzt ein eigenes Paketformat. Plane deinen Server also nicht so, dass er ohne die Custom-Optik unspielbar wird, solange Bedrock-Spieler mitspielen sollen.

Der einzige verlässliche Test ist der aus Spielersicht: mit einem zweiten Konto und geleertem Zwischenspeicher verbinden. Erscheint das Pack dort, erscheint es auch bei allen anderen. Prüf dabei gleich mit, wie lange der Download dauert - was bei dir in zwei Sekunden durch ist, kann anderswo eine halbe Minute Wartezeit vor dem ersten Spielerlebnis bedeuten.

Häufige Fehler

• Kein Direktlink - die URL führt auf eine Vorschauseite statt auf die Datei. Der Client kann damit nichts anfangen.
• Kein HTTPS - unverschlüsselte Links machen je nach Umgebung Probleme.
• Veraltete SHA-1 - der Klassiker nach einem Pack-Update.
• Falsche pack_format-Nummer in der pack.mcmeta - dann meldet der Client das Pack als inkompatibel.
• Pack zu groß - sehr große Pakete lassen den Verbindungsaufbau ins Leere laufen.

Zum Testen einmal selbst mit geleertem Client-Zwischenspeicher verbinden - so siehst du genau das, was ein neuer Spieler sieht.

Häufige Fragen