Zrozum, co Twój serwer Minecraft zapisuje, gdy coś się psuje

Trzy miejsca, w których serwer zapisuje rzeczy

Konsola to tylko jedna kopia. Te same linijki trafiają do folderu logs, a crash dodaje własny raport.

latest.log i spakowane starsze logi

Każda linijka w latest.log zaczyna się tak samo: czas, wątek, który ją zapisał, i poziom, jak w [21:07:33] [Server thread/WARN]:. Najczęściej spotkasz INFO dla zwykłych zdarzeń, WARN dla czegoś dziwnego, co serwer przetrwał, i ERROR dla czegoś, co się nie udało. Linijki bez tego przedrostka należą do linijki nad nimi, zwykle jako część stack trace.

Gdy serwer startuje, poprzedni latest.log jest pakowany do pliku .log.gz nazwanego datą, z numerem na końcu, który rośnie, gdy jednego dnia jest ich kilka. Uruchomienie, które trwa po północy, też jest dzielone przy zmianie dnia.

• Otwórz latest.log w przeglądarce. W zakładce „Pliki” wejdź do logs i kliknij „Edytuj” przy latest.log. Bardzo długi log otwiera się ucięty i nie da się go zapisać; do takich użyj „Pobierz”.
• Czytaj spakowany log na swoim komputerze. Kliknij „Pobierz” przy pliku .log.gz i otwórz go dowolnym programem do archiwów; w środku jest zwykły log tekstowy.
• Na serwerze z modami zajrzyj do debug.log. Logowanie samej vanilli zapisuje tylko latest.log. Forge i NeoForge dodają obok debug.log z linijkami debug, i to ten plik mają na myśli autorzy modów, gdy proszą o Twój debug log.

Przeszukuj zakładkę Konsola zamiast przewijać

Dla ostatnich kilku minut zakładka „Konsola” jest szybsza niż każdy plik:

• „Szukaj w logach...” zostawia tylko linijki zawierające to, co wpiszesz, na przykład nazwę gracza, nazwę pluginu albo Exception.
• Menu poziomu przełącza między „Wszystkie poziomy”, „Info”, „Ostrzeżenia” i „Błędy”. „Błędy” pokazuje linijki oznaczone ERROR, SEVERE albo FATAL.
• „Pobierz wyjście konsoli”, przycisk ze strzałką pobierania, zapisuje każdą linijkę z okna jako plik tekstowy, bez kodów kolorów, nawet gdy wyszukiwanie jest aktywne.
• „Wyczyść” opróżnia okno i nic więcej. Linijki zostają w latest.log.

Okno trzyma nie więcej niż 2000 linijek. Jeden długi crash ze zrzutem wątków może wypchnąć początek historii poza widok, i wtedy miejscem do czytania jest latest.log.

Z czego składa się raport crasha

Raport crasha to plik tekstowy w crash-reports z datą i godziną w nazwie, na przykład crash-2026-09-14_21.07.33-server.txt. Za każdym razem składa się z tych samych bloków, w tej kolejności:

---- Minecraft Crash Report ----
// Who set us up the TNT?

Time: 2026-09-14 21:07:33
Description: <what the game was doing>

<exception type>: <message>
	at <the line where it broke>
Caused by: <an earlier exception>

A detailed walkthrough of the error, its code path and all known details is as follows:

-- Head --
Thread: Server thread
Stacktrace:

-- System Details --
Details:
	Minecraft Version: 26.2
	Java Version: ...

Crashe podczas startu mają własne typowe przyczyny, opisane w poradniku o serwerze, który nie startuje.

Idź po stack trace do moda albo pluginu

Stack trace czyta się od góry w dół. Pierwsza linijka podaje rodzaj wyjątku i jego komunikat. Każda linijka at pod nią to jeden krok w kodzie: najwyższa to miejsce, gdzie się zepsuło, a niższe to droga, którą serwer tam doszedł.

• `Caused by:` zaczyna drugi trace: wyjątek, który wywołał ten powyżej. Może ich być kilka z rzędu, a ostatni Caused by: jest najbliżej prawdziwego problemu.
• `... 12 more` znaczy, że pozostałe kroki są takie same jak w trace powyżej. Nic ważnego nie zostało ucięte.
• Nazwa pakietu na początku każdej linijki at mówi, do kogo należy kod tego kroku. W ten sposób trace wskazuje mod albo plugin.

Schodź po trace, aż dojdziesz do pierwszego pakietu, który nie jest grą, oprogramowaniem serwera ani Javą. Porównaj tę nazwę z plikami w folderze plugins albo mods; nazwa projektu często pojawia się w obu. Potem zaktualizuj ten plugin albo mod, sprawdź jego config albo przenieś go do zapasowego folderu i zobacz, czy crash wraca.

Watchdog, który zatrzymuje zawieszony serwer

Serwer, który zawiesza się wewnątrz jednego ticku, nie może odpowiadać graczom ani komendom, więc gra trzyma osobny wątek watchdog, który pilnuje zegara. Gdy jeden tick trwa dłużej niż limit, watchdog rezygnuje z serwera i go zatrzymuje:

A single server tick took <seconds> seconds (should be max <seconds>)
Considering it to be crashed, server will forcibly shutdown.
This crash report has been saved to: <path>

Raport, który zapisuje, ma opis Watching Server i zrzut wątków: trace każdego wątku w chwili zatrzymania. Patrz na trace Server thread, bo to ten się zaciął.

Ustawienie w zakładce Ustawienia

Na serwerach vanilla, Fabric, Forge i NeoForge limit to „Watchdog (ms)” w grupie „Wydajność” zakładki „Ustawienia”, zapisywany jako max-tick-time w server.properties. Domyślnie to 60000, jedna minuta, a pole przyjmuje wartości od 1000 do 600000.

Paper, Purpur i Spigot wyłączają tego watchdoga i uruchamiają własnego, więc tam pole nic nie zmienia. Ich limit to timeout-time pod settings w spigot.yml, liczony w sekundach, domyślnie 60.

Zrzut wątków Papera, gdy serwer przestaje odpowiadać

Paper nie czeka całej minuty w ciszy. Gdy serwer przez 10 sekund nie skończy ticku, wypisuje zrzut wątków, i kolejny co 5 sekund, dopóki zawieszenie trwa:

--- DO NOT REPORT THIS TO PAPER - THIS IS NOT A BUG OR A CRASH  - <version> ---
The server has not responded for 10 seconds! Creating thread dump

Te wczesne zrzuty pojawiają się także wtedy, gdy serwer dochodzi do siebie, więc piętnastosekundowe zawieszenie zostawia jeden w latest.log bez żadnego crasha. Szukaj w logu not responded, żeby je znaleźć.

Gdy zawieszenie dojdzie do timeout-time, Paper zatrzymuje serwer z ostatnim, pełnym zrzutem:

The server has stopped responding! This is (probably) not a Paper bug.
Server thread dump (Look for plugins here before reporting to Paper!):

• Pakiet pluginu blisko góry wątku serwera wskazuje ten plugin. Komunikat samego Papera wymienia zapytania do sieci i pracę z bazą danych jako typowych podejrzanych.
• Zapis albo edycja świata blisko góry znaczy, że serwer dostał naraz dużo więcej pracy, niż może udźwignąć, na przykład ogromną operację WorldEdit. Dziel takie zadania na mniejsze części.
• Te same linijki w kilku zrzutach z rzędu pokazują, gdzie serwer utknął, więc to miejsce jest pierwszym do sprawdzenia.

watchdog:
  early-warning-delay: 10000
  early-warning-every: 5000

Obie wartości są w milisekundach i rzadko trzeba je zmieniać.

Udostępnij log, nie udostępniając za dużo

Ktoś, kto Ci pomaga, potrzebuje całego pliku, a nie zrzutu ekranu z ostatnimi linijkami. Log zapisuje o Twoich graczach więcej, niż można się spodziewać, więc najpierw szybko go przejrzyj.

1. 1

   Pobierz kopię

   Kliknij „Pobierz” przy pliku w zakładce „Pliki”. Przy kilku plikach zaznacz ich pola, naciśnij „Zip”, żeby spakować je do jednego archiwum, i pobierz je. Zmiany rób w kopii na swoim komputerze, nigdy w pliku na serwerze.

2. 2

   Usuń adresy graczy

   Każde wejście zapisuje linijkę taką jak Kai[/<address>:<port>] logged in with entity id ..., z adresem IP gracza w nawiasach. Zastąp każdy adres czymś takim jak x.x.x.x.

3. 3

   Sprawdź komendy wpisane przez graczy

   Paper i Spigot zapisują każdą komendę jako <playername> issued server command: <command>. Przejrzyj te linijki pod kątem czegoś prywatnego i przeszukaj plik pod kątem słów takich jak password i token.

4. 4

   Resztę zostaw

   Zostaw wersje, szczegóły systemu i linijki wokół błędu; pomocnicy ich potrzebują.

Żeby adresy w ogóle nie były zapisywane, wyłącz „Log player IP addresses” w grupie „Zaawansowane” zakładki „Ustawienia”. Działa to dla linijek zapisanych od następnego startu; starsze pliki zachowują adresy, które już mają.