Przejdź do głównej zawartości

Jak czytać logi i crash reporty

Kiedy serwer Minecraft nie chce wystartować, wyrzuca graczy albo nagle się wyłącza, odpowiedź prawie zawsze jest w logach. Ten poradnik pokazuje, gdzie znaleźć logi i crash reporty na hostingu voxelhost oraz jak czytać je krok po kroku, żeby samodzielnie wskazać przyczynę.

Gdzie znaleźć logi​

Logi swojego serwera znajdziesz w panelu voxelhost na trzy sposoby.

Konsola (podgląd na żywo). Otwórz serwer i przejdź do zakładki Konsola. Zobaczysz logi na żywo, dokładnie tak jak pojawiają się na serwerze. U góry możesz filtrować wpisy po poziomie: Info, Ostrzeżenia, Błędy, Konsola i Bez etykiety. Zostaw włączone co najmniej "Błędy" i "Bez etykiety", żeby nie ukryć kolejnych linii wyjątku, na przykład Caused by: i stacktrace. Przyciskiem Kopiuj widoczne skopiujesz to, co aktualnie widać na ekranie, a w polu na dole (Wpisz komendę) wykonasz komendę przyciskiem Wykonaj. Konsola działa tylko przy włączonym serwerze - jeśli jest wyłączony, zobaczysz komunikat "Włącz serwer aby uzyskać dostęp do konsoli."

Zakładka Konsola z filtrami poziomów i przyciskiem Kopiuj widoczne

Zakładka Konsola z filtrami poziomów i przyciskiem Kopiuj widoczne

Pliki (pełny plik logu, pobieranie w panelu). W zakładce Pliki wejdź do folderu logs/ i otwórz latest.log bezpośrednio w panelu albo pobierz go przyciskiem Pobierz przy pliku. Starsze logi to spakowane archiwa w rodzaju logs/2026-07-05-1.log.gz - te możesz tylko pobrać i rozpakować u siebie (plików .gz nie otworzysz w edytorze w panelu). Crash reporty znajdziesz w folderze crash-reports/, także z przyciskiem Pobierz przy każdym pliku.

Zakładka Pliki z folderem logs/ i menu kontekstowym pliku z opcją Pobierz

Folder logs w zakładce Pliki z opcją Pobierz

SFTP (dla dużych plików). Pliki powyżej 50 MB przenoś przez SFTP, np. programem WinSCP lub FileZilla. Dane logowania znajdziesz w panelu w zakładce Ustawienia, sekcja FTP: host sftp://ftp.voxelhost.pl, port 22, login i hasło (hasło wyświetla się tylko raz przy generowaniu). Układ plików jest ten sam co w zakładce Pliki: logs/latest.log, spakowane logs/*.log.gz oraz crash-reports/.

Jak czytać loga​

Każda linia loga ma ten sam schemat: [godzina] [wątek/POZIOM]: treść. Na przykład:

[12:03:44] [Server thread/ERROR]: Encountered an unexpected exception

Tu 12:03:44 to godzina, Server thread to wątek, ERROR to poziom ważności, a reszta to właściwa wiadomość. Poziomy, które warto znać, to INFO (zwykła informacja), WARN (ostrzeżenie, często nieszkodliwe), oraz ERROR, SEVERE i FATAL (realne błędy). Starsze wersje i pluginy używają krótszego zapisu [12:03:44 ERROR]:, ale zasada jest ta sama.

Nie czytaj całego logu od góry do dołu. Otwórz latest.log i użyj funkcji szukania (Ctrl+F), wpisując kolejno:

  • Caused by: - pokazuje właściwą przyczynę błędu,
  • ERROR, SEVERE, FATAL - poważne problemy,
  • Exception - miejsca, w których coś się wywaliło.

Najważniejsza zasada: liczy się pierwszy błąd. Gdy serwer się psuje, jeden błąd często wywołuje lawinę kolejnych, więc te niżej są zwykle tylko skutkiem. Przewiń do pierwszego ERROR/Exception od początku problemu, a nie do ostatniego.

Crash report krok po kroku​

Jeśli Minecraft sam obsłuży awarię, zwykle zapisze osobny plik w crash-reports/. Przy nagłym zakończeniu procesu, na przykład przez limit pamięci, SIGKILL lub awarię natywną Javy, nowy crash report może nie powstać. Wtedy sprawdź końcówkę latest.log oraz zdarzenie pokazane w panelu. Jeśli raport powstał, ma powtarzalną budowę:

  1. Description - jedna linia na samej górze, która streszcza awarię, np. Exception ticking entity. To pierwsza wskazówka, czego szukać.
  2. Stacktrace - ciąg linii z nazwami klas i łańcuchem Caused by:. Gdy jest kilka bloków Caused by:, ten najgłębszy (ostatni) jest zwykle prawdziwą przyczyną, a nie pierwszy.
  3. System Details - na dole znajdziesz wersję Javy, przydzieloną pamięć, loader modów oraz, w Forge, pełną listę modów.

Aby znaleźć trop, zacznij od najgłębszego komunikatu Caused by: oraz sekcji crash reportu wskazującej podejrzany mod, jeśli loader ją wygenerował. Nazwy pakietów w stacktrace, na przykład com.jakismod.cos, pokazują tylko kod obecny na ścieżce wywołań i nie są samodzielnym dowodem winy. Porównaj je z listą modów, ale nie usuwaj dodatku wyłącznie na podstawie jednej ramki stacktrace.

Typowe wzorce​

  • Brak pamięci RAM: java.lang.OutOfMemoryError: Java heap space. Serwer wyczerpał przydzieloną pamięć - najczęściej przez zbyt wiele modów, mod z wyciekiem pamięci lub za dużo wczytanego świata.
  • Brakująca zależność moda: komunikaty o Missing or unsupported mandatory dependencies (Forge). Mod wymaga innego moda lub innej wersji, której nie ma na serwerze.
  • Nieakceptowana EULA: You need to agree to the EULA in order to run the server. Na hostingu voxelhost akceptacja EULA i plik eula.txt są obsługiwane automatycznie. Jeśli komunikat pojawia się ponownie po restarcie serwera, skontaktuj się z supportem zamiast edytować plik ręcznie.
  • Zajęty port: Failed to bind to port / Address already in use. Serwer próbuje wystartować na porcie, który jest już zajęty przez inną instancję.
  • Ticking entity: crash z opisem Exception ticking entity. Zwykle winna jest konkretna encja lub mod.

Zanim napiszesz na Discordzie​

Zespół wsparcia rozwiąże problem znacznie szybciej, jeśli od razu dostanie właściwe dane. Zamiast zrzutu ekranu z fragmentem konsoli dołącz cały plik latest.log (pobierzesz go z zakładki Pliki), a przy crashu także cały plik z folderu crash-reports/. Pełne logi przesyłaj wyłącznie w prywatnym tickecie wsparcia. Przed wysłaniem usuń z nich adresy IP, tokeny, hasła i inne poufne dane. Zrzut ekranu prawie nigdy nie zawiera kluczowej linii Caused by:. Do szybkiego wklejenia kilku linii przyda się przycisk Kopiuj widoczne w konsoli, ale pełny plik zawsze pomaga najbardziej. Krótko opisz też, co robiłeś, gdy pojawił się błąd, i co ostatnio zmieniałeś na serwerze.

Powiązane artykuły​

Ostatnia aktualizacja: lipiec 2026