GameHosting.pl

Notatki operatora

Jak naprawić crashujący modpack na serwerze Minecraft

Serwer modowany nie chce wstać albo wywala się po kilku minutach? Ten przewodnik prowadzi metodycznie: najpierw gdzie szukać przyczyny w logach i jak czytać stack trace, potem najczęstsze powody crasha i ich naprawy, na koniec metoda bisekcji listy modów, gdy log nie wskazuje winnego wprost. Z perspektywy kogoś, kto nieraz odpalał ten sam modpack po pięć razy, zanim ruszył.

Opublikowano · ~9 min czytania

W skrócie: nie zgaduj, czytaj log. Zacznij od crash-reports/ (plik crash-...-server.txt), a jeśli jest pusty, od logs/latest.log. Szukaj słów Exception i Caused by, a w liniach at ... nazwy pakietu winnego moda. Najczęstsze przyczyny: za mało RAM (flaga -Xmx), zła wersja Javy do wersji gry (od MC 1.20.5 i całej 1.21 potrzebna Java 21), niezgodne wersje modów, brak zależności, mod tylko po stronie klienta wrzucony na serwer. Gdy log milczy, połów listę modów na pół (bisekcja). Jeśli nie chcesz tego robić ręcznie, weź hosting z gotowymi profilami modów i automatycznym doborem Javy.

Najpierw log, dopiero potem domysły

Pierwszy odruch przy crashu to grzebanie w ustawieniach na ślepo. To strata czasu. Serwer Minecraft niemal zawsze zapisuje, co się stało, i wystarczy to przeczytać. Są dwa miejsca, do których zaglądasz w pierwszej kolejności:

W obu plikach szukasz tych samych słów kluczowych: ERROR, WARN, Exception i przede wszystkim Caused by. To one prowadzą do sedna. Resztę linii (zwykłe komunikaty INFO o ładowaniu modów) możesz na tym etapie pominąć.

Jak czytać stack trace i znaleźć winny mod

Stack trace to blok tekstu zaczynający się od nazwy wyjątku (na przykład java.lang.NullPointerException) i ciąg linii zaczynających się od at. Czyta się go od góry do dołu, a kolejne warstwy przyczyn rozdzielają linie Caused by:.

Zasady, które ratują przy szukaniu winowajcy:

  1. Pierwsza linia to typ błędu. Mówi co się stało (na przykład odwołanie do null, brak metody, błąd ładowania klasy), ale jeszcze nie kto zawinił.
  2. Szukaj nazwy pakietu moda w liniach at. Linia typu at com.autor.modid.Klasa.metoda(Plik.java:55) wskazuje konkretny mod. Fragment po com, net, me czy dev to przeważnie autor i identyfikator moda. Klasy z pakietów net.minecraft albo java. to silnik gry i sama Java, one rzadko są źródłem, częściej miejscem, gdzie wybuchł cudzy błąd.
  3. Schodź po każdym Caused by: aż do najgłębszego. Crashe bywają zagnieżdżone, prawdziwa przyczyna jest zwykle w ostatnim Caused by na samym dole.
  4. Gdy w trace jest kilka modów, zacznij od tego najbliżej góry. To on był na wierzchu w chwili wywalenia.

Na samym dole crash-reportu jest sekcja z danymi systemu, a w niej lista wszystkich załadowanych modów wraz z wersjami. Porównaj nazwę winnego pakietu z tą listą, dostaniesz dokładną nazwę i wersję moda do podmiany albo usunięcia.

Z doświadczenia: przy modowanych serwerach (Forge, NeoForge, Fabric) najczęściej liczy się to, co stoi tuż po Caused by:, a nie pierwsza, efektowna linia wyjątku. Skopiuj całą sekcję od typu błędu do najgłębszego Caused by i wklej w wyszukiwarkę razem z nazwą moda, połowa typowych crashy ma gotowe rozwiązanie na trackerze danego moda.

Najczęstsze przyczyny i ich naprawa

1. Za mało pamięci (RAM)

Modpacki są pamięciożerne. Objawy braku RAM to crash z java.lang.OutOfMemoryError, długie zacięcia albo proces ubity przez system. Pamięć przydzielasz flagami startowymi JVM:

Ile dać? Lekki zestaw około 30 modów chodzi na 3 do 4 GB, średni modpack na 6 do 8 GB, a duże zestawy typu All the Mods potrafią potrzebować 8 do 10 GB, czasem więcej przy kilku graczach. Nie przydzielaj całej fizycznej pamięci maszyny. Zostaw około 1 do 1,5 GB poza -Xmx na samą Javę i system, inaczej zabraknie pamięci poza stertą. Więcej nie zawsze znaczy lepiej, bardzo duża sterta wydłuża pauzy garbage collectora, dlatego rzadko przekracza się 10 do 12 GB bez wyraźnej potrzeby. Do dopasowania wielkości serwera do modpacka i liczby graczy zerknij do doboru sprzętu pod serwer gry.

Jeśli walczysz z zacięciami przy odpowiedniej ilości RAM, warto dołożyć tak zwane flagi Aikara (zestaw parametrów strojących garbage collector G1GC pod Minecraft), zaczynające się od -XX:+UseG1GC. To strojenie wydajności, nie lekarstwo na sam crash z braku pamięci.

2. Zła wersja Javy do wersji gry

Bardzo częsty powód, że serwer w ogóle nie wstaje. Każda wersja Minecraft wymaga określonej (lub nowszej) wersji Javy. Stan na 2026:

Wersja MinecraftWymagana Java
1.16.5 i starszeJava 8
1.17.xJava 16
1.18 do 1.20.4Java 17
1.20.5 oraz cała seria 1.21Java 21

To samo dotyczy loaderów modów: Forge, NeoForge i Fabric pod Minecraft 1.20.5 i 1.21 wymagają Javy 21. Objawy złej Javy to UnsupportedClassVersionError w logu (mod skompilowany pod nowszą Javę niż masz zainstalowaną) albo wprost komunikat startera, że potrzebna jest nowsza wersja. Naprawa: zainstaluj i wskaż serwerowi właściwą Javę. Na zarządzanym hostingu zwykle wybierasz wersję Javy z listy, na własnym VPS instalujesz odpowiednie JDK i podajesz pełną ścieżkę do java w skrypcie startowym.

3. Niezgodne wersje modów

Mod skompilowany pod Minecraft 1.20.1 nie załaduje się na 1.21, a mod pod Forge nie zadziała na Fabric. W logu zobaczysz komunikaty o niespełnionych zależnościach wersji albo Incompatible mods found. Zasada: wszystkie mody muszą pasować do tej samej wersji Minecraft i tego samego loadera (Forge albo NeoForge albo Fabric, nie mieszane). Pobierając mody ręcznie zawsze sprawdzaj kolumnę zgodności wersji.

4. Brakująca zależność (np. biblioteka)

Wiele modów wymaga dodatkowych bibliotek (na Fabric typowo Fabric API, na Forge bywają osobne biblioteki danego autora). Gdy jej brakuje, crash przy starcie często wprost wymienia, czego mu trzeba, na przykład requires fabric >= ... albo Missing or unsupported mandatory dependencies, z nazwą brakującego moda. Naprawa jest dosłowna: dograj wskazaną zależność w odpowiedniej wersji do folderu mods/.

5. Mod tylko po stronie klienta wrzucony na serwer

Część modów (mapy, shadery, poprawki interfejsu, minimapy) działa wyłącznie po stronie klienta i na serwerze albo nie ma sensu, albo wręcz wywala start, bo odwołuje się do klas renderowania, których serwer nie ma. W trace zobaczysz wtedy nazwy klas związane z grafiką lub ekranem. Naprawa: usuń mody oznaczone jako client-side z serwerowego folderu mods/, zostaw je tylko u graczy.

6. Uszkodzony świat lub config

Jeśli crash ma w trace odwołanie do generowania albo wczytywania świata (chunki, save), winny może być uszkodzony świat, a nie mod. Podobnie potrafi zaszkodzić błędnie zapisany plik konfiguracyjny w config/ (na przykład po ręcznej edycji z literówką). Szybki test: tymczasowo przenieś folder świata gdzie indziej i pozwól serwerowi wygenerować nowy. Jeśli wystartuje, problem jest w świecie. Plik configu z błędem zwykle naprawia się przez usunięcie go (mod odtworzy domyślny) lub przywrócenie z kopii.

Metoda bisekcji, gdy log nie wskazuje winnego

Czasem crash jest skutkiem konfliktu dwóch modów i żaden pojedynczy pakiet w trace nie jest oczywistym winowajcą. Wtedy zamiast wyłączać mody po jednym, stosujesz bisekcję, czyli połowienie listy:

  1. Zrób kopię folderu mods/, żeby móc wrócić do pełnego zestawu.
  2. Wyłącz połowę modów. Najprościej zmieniając rozszerzenie z .jar na .jar.disabled albo przenosząc połowę plików do osobnego folderu obok.
  3. Wystartuj serwer. Jeśli crash zniknął, winny jest w wyłączonej połowie. Jeśli został, w tej, która działa.
  4. Tę podejrzaną połowę dziel znów na pół i powtarzaj. Przy 60 modach trafiasz w winowajcę po mniej więcej 6 uruchomieniach zamiast 60.

Jedna pułapka: zależności. Wyłączając bibliotekę, musisz wyłączyć też mody, które jej wymagają, inaczej crash zmieni przyczynę i wynik bisekcji będzie mylący. Gdy znajdziesz konfliktową parę, masz wybór: zaktualizować jeden z modów, podmienić na alternatywę albo zrezygnować z mniej istotnego.

Aktualizacja, dopasowanie wersji i czysta reinstalacja

Gdy znasz już winny mod, kolejność działań jest taka:

Jeśli całość zaczynasz od zera albo chcesz zrozumieć, jak modowany serwer różni się od czystego, zobacz jak postawić serwer Minecraft z modami oraz ogólny przewodnik jak zrobić serwer Minecraft.

Najczęstsze pytania

Gdzie serwer zapisuje informacje o crashu?

W logs/latest.log (pełny log uruchomienia) oraz, przy poważnym wywaleniu, w osobnym pliku w folderze crash-reports/ o nazwie typu crash-...-server.txt. Zaczynaj od crash-reportu, a gdy go nie ma, czytaj latest.log, szukając Exception i Caused by.

Jak znaleźć w logu, który mod powoduje crash?

W stack trace szukasz linii at z nazwą pakietu moda (na przykład com.autor.modid...), czytasz od góry i schodzisz po każdym Caused by do najgłębszego. Listę wszystkich modów z wersjami znajdziesz na dole crash-reportu.

Ile RAM dać serwerowi modowanemu?

Lekki zestaw 3 do 4 GB, średni 6 do 8 GB, duże modpacki 8 do 10 GB lub więcej. Ustawiasz to flagami -Xms i -Xmx (trzymaj je równe) i zostawiasz około 1 do 1,5 GB zapasu poza -Xmx na Javę i system.

Jakiej wersji Javy potrzebuje moja wersja gry?

MC 1.16.5 i starsze: Java 8; 1.17.x: Java 16; 1.18 do 1.20.4: Java 17; od 1.20.5 i przez całą 1.21: Java 21. Forge, NeoForge i Fabric pod 1.20.5/1.21 też wymagają Javy 21.

Na czym polega bisekcja listy modów?

Wyłączasz połowę modów (zmiana rozszerzenia na .jar.disabled) i startujesz. Crash zniknął, winny jest w wyłączonej połowie; został, w działającej. Tę połowę dzielisz znów na pół i powtarzasz, pamiętając o zależnościach.

Powiązane