Zanim zaczniesz
Zapisz Java lub Bedrock, wersje klienta i serwera, adres z portem oraz dokładną godzinę. Zachowaj konsolę i ostatnie zmiany. Przed modyfikacją światów, modów czy plików przygotuj kopię możliwą do odtworzenia i przechowuj oryginalny stan oddzielnie.
Potwierdź edycję i adres
Java i Bedrock są różnymi rodzajami serwera: Java zwykle używa TCP, a Bedrock UDP. Inny port nie sprawia, że edycje stają się zamienne. Użyj przydzielonego adresu z panelu i sprawdź cel DNS lub rekordu SRV Java. Dostępna administracja nie potwierdza testowania właściwej gry; domyślne porty nie są obietnicą przydziału na współdzielonym nodzie.
Rozgrywka Java zazwyczaj wykorzystuje punkt końcowy TCP, podczas gdy rozgrywka serwerowa Bedrock wykorzystuje UDP. Typowe wartości domyślne nigdy nie zastępują przydziału paneli. W węźle współdzielonym kopiowanie domyślnego portu z samouczka może powodować konflikt z inną instancją. Test TCP nie może sprawdzić łączności Bedrock UDP.
Testuj tylko połączenie TCP Java z Windows
Test-NetConnection -ComputerName 192.0.2.10 -Port 25565Podstaw rzeczywisty adres i port usługi. TcpTestSucceeded=True potwierdza jedynie zestawienie TCP, nie UDP Bedrock, uwierzytelnianie Minecraft ani wydajność. Przy False porównaj nasłuchiwanie, uruchamianie serwera i reguły tego konkretnego portu.
Sprawdź zakończenie uruchamiania
Proces może działać podczas ładowania świata. Znajdź komunikat o gotowości i błędy Java, konfiguracji, pluginów lub modów. Jeżeli serwer stale się uruchamia ponownie, zbadaj najpierw ten cykl. Szybkie restarty zwiększają obciążenie i mogą ukryć wskazówki. Zachowaj komunikaty i nie zmieniaj jednocześnie świata, wersji oraz wszystkich dodatków bez ustalenia konkretnej przyczyny.
Po dodaniu wtyczki lub moda sprawdź jego zależności i kompatybilność z silnikiem. Paper, Fabric, Forge i NeoForge nie ładują automatycznie tych samych rozszerzeń. Użyj kopii testowej i usuń tylko zidentyfikowany dodatek; usunięcie świata nie jest sposobem na zdiagnozowanie błędu oprogramowania.
Testuj właściwy protokół
Sprawdź autoryzowane połączenie publicznego IP z portem gry. Test TCP nie potwierdza portu Bedrock UDP. Bedrock z widocznością LAN może otwierać dodatkowe standardowe porty także przy niestandardowym porcie; na wspólnym hoście musi to pasować do konfiguracji operatora. Nie otwieraj samodzielnie dodatkowych portów ani przydzielonych innym klientom. Proxy musi faktycznie obsługiwać tę edycję.
Następnie porównaj z innego autoryzowanego połączenia. W przypadku awarii tylko jednej sieci zapisz jej dostawcę i czasy, zamiast natychmiast zmieniać konfigurację globalną. Zablokowany ping ICMP nie stwierdza, że gra jest nieosiągalna; odpowiedź na polecenie ping również nie oznacza, że port gry jest otwarty.
Sprawdź DNS Java bez zmiany strefy
dig +short A play.example.com
dig +short SRV _minecraft._tcp.play.example.comRekord SRV Java może wskazywać inny cel i port. Rozwiąż również zwróconą nazwę i porównaj ją z przydziałem. SRV nie jest potrzebny, jeżeli klient używa już poprawnego adresu i portu. To nie jest test UDP Bedrock.
Porównaj wersje i zależności
Sprawdź wersję gry, oprogramowanie serwera oraz loader. Modpack może wymagać takiej samej kombinacji po stronie klienta i serwera. Gdy błąd nastąpił po zmianie, badaj tę zależność, zachowując kopię. Starsza wersja lub inny świat mogą być niezgodne z danymi. Nie usuwaj oryginału ani wszystkich modów na próbę; utrzymuj oddzielny punkt odzyskiwania i zapis zmian.
Bedrock wykrywanie sieci LAN może także otwierać swoje zwykłe porty oprócz portu niestandardowego. Na węźle współdzielonym użyj dostosowanej konfiguracji panelu i poproś o sprawdzenie konfliktu alokacji. W przypadku serwera proxy Java lub bramy typu crossplay sprawdź każdy etap ścieżki, a nie tylko adres publiczny.
Mierz podczas problemu
Obserwuj CPU, pamięć i konsolę w tym samym czasie. Przeciążony główny wątek może blokować grę przy niskiej średniej całego hosta. W Paper spark pomaga profilować występujący problem. Sprawdź odległość widzenia i symulacji oraz nadpisania przez inne pliki konfiguracyjne. Więcej RAM nie usuwa automatycznie tej pracy; ważne są ustawienia faktycznie stosowane, nie tylko wpis w jednej konfiguracji.
Jeśli jest to możliwe, sprofiluj serwer podczas występowania problemu za pomocą kompatybilnego narzędzia. Najnowsze wersje Paper obejmują spark. Raport z pustego serwera jest mniej przydatny niż ten zarejestrowany w czasie spowolnienia. Powiąż nagranie i chroń łącza diagnostyczne, które mogą zawierać poufne informacje.
Przygotuj odtwarzalną diagnozę
Porównaj drugie łącze i ustal, których graczy dotyczy błąd. Zachowaj godzinę, endpoint i komunikaty bez sekretów oraz prywatnych danych. Timeout może pochodzić z routingu, filtrów, złego protokołu lub niegotowego serwera. Wskaż atak albo brak zasobów dopiero wtedy, gdy potwierdzają to dane sieci i aplikacji. Samo odłączenie gracza nie wystarcza do takiego rozpoznania.
Podejrzewana aktywność DDoS wymaga korelacji z pomiarami ruchu lub zdarzeniami łagodzącymi. Samo przekroczenie limitu czasu nie jest wystarczającym dowodem. Unikaj powtarzających się restartów i agresywnych skanów: zwiększają obciążenie i utrudniają diagnozę. Przetestuj poprawkę, korzystając z normalnego połączenia, a następnie sprawdź, czy zwykli gracze mogą wrócić.
Co zrobić w Twojej sytuacji
| Sytuacja | Następny krok |
|---|---|
| Niewłaściwa edycja | Wybierz Java lub Bedrock i rzeczywisty endpoint. Zmiana portu nie konwertuje edycji. |
| Problem po modach lub świecie | Sprawdź wersje i zależności, zachowując osobną kopię poprzedniego stanu. |
| Problem tylko pod obciążeniem | Profiluj główny wątek i chunki podczas awarii przed zwiększeniem planu. |
Oficjalne źródła
Te źródła opisują wymienione protokoły i ustawienia. Sprawdź dokumentację właściwą dla używanej wersji.