Dlaczego hosting Magento nie działa? Jak znaleźć przyczynę

Zakres objawu wskazuje pierwszą warstwę do sprawdzenia podczas diagnozy Magento. Zapisz adres, czas i komunikat, a następnie otwórz osobno stronę główną, produkt, koszyk, checkout i panel administratora.

Tabela wiąże objaw z pierwszym obszarem kontroli i danymi, które pomogą odtworzyć problem. Kod HTTP opisuje odpowiedź serwera, ale sam nie rozstrzyga, kto spowodował błąd.

Komunikat strony może różnić się od kodu zwracanego przez serwer. Odczytaj status HTTP w narzędziach deweloperskich przeglądarki albo w logu serwera i zestaw go z wpisem z tej samej minuty.

Jeśli diagnoza pokazuje, że sklep wymaga przebudowy lub zmiany platformy, sklep internetowy na WooCommerce może być punktem wyjścia do rozmowy o katalogu i wymaganych integracjach.

Przed czyszczeniem cache, aktualizacją lub przywracaniem kopii zapisz stan sklepu i czas wystąpienia awarii. Zestawienie objawu z ostatnimi zmianami ułatwia administratorowi wskazanie możliwej przyczyny.

Przygotuj wydanie Magento, wersje PHP dla WWW i CLI, silnik bazy danych, adres błędu, kod HTTP oraz czas ze strefą czasową. Dopisz, które funkcje są niedostępne i czy przed awarią wdrażano moduł, zmieniano konfigurację lub uruchamiano import.

W Magento sprawdź `var/log/system.log` i `var/log/exception.log`. Logi WWW i PHP-FPM znajdują się w lokalizacji ustalonej przez dostawcę hostingu. Zachowaj wpisy z czasu awarii i usuń dane klientów oraz sekrety.

Przed zmianą potwierdź, że istnieje aktualna kopia plików i bazy danych oraz że można ją odtworzyć. Wprowadzaj pojedyncze zmiany, żeby dało się ocenić ich wpływ.

Serwer spełnia wymagania Magento wtedy, gdy wersje PHP, bazy danych, wyszukiwarki, rozszerzeń i usług odpowiadają macierzy zgodności dokładnego wydania. Sprawdź konfigurację WWW i CLI osobno, ponieważ te środowiska mogą korzystać z różnych wersji PHP.

Tabela pokazuje, gdzie odczytać wersje komponentów i co zestawić z dokumentacją Adobe. Nazwa planu hostingowego nie potwierdza zgodności środowiska.

Adobe publikuje macierz wymagań systemowych Adobe Commerce z kombinacjami zależności przypisanymi do wydań. Wymagania zmieniają się wraz z wersją Magento; dokumentację sprawdziliśmy w październiku 2026 roku. Adobe opisuje również ustawienia PHP.

Rozbieżność między PHP WWW i CLI może powodować błędy podczas żądań przeglądarki, wdrożeń, indeksowania lub aktualizacji. Przekaż administratorowi dokładne wydanie Magento i poproś o odczyt obu konfiguracji.

Przy błędzie 500, 502 lub 503 sprawdź log warstwy zwracającej błąd, a następnie logi Magento z tego samego przedziału czasu. Taka kolejność ogranicza ryzyko szukania przyczyny w niepowiązanych wpisach.

1. Zapisz URL, kod HTTP, godzinę i identyfikator żądania, jeśli serwer go zwraca.
2. Sprawdź log Nginx lub Apache pod kątem błędu upstream, limitu czasu i odmowy dostępu.
3. Sprawdź PHP-FPM lub dziennik PHP pod kątem błędu fatalnego albo przekroczenia pamięci.
4. Sprawdź `var/log/exception.log` i `var/log/system.log` w katalogu Magento.
5. Porównaj pierwszy pasujący wpis z historią wdrożeń i zmian konfiguracji.

Kod 500 oznacza wewnętrzny błąd serwera, 502 wskazuje problem z odpowiedzią backendu, a 503 oznacza czasową niedostępność usługi. Każdy kod zawęża diagnozę, ale przyczynę potwierdza dopiero log lub powtarzalny test.

W Adobe Commerce on Cloud logi można przeglądać przez Cloud Console, system plików i Cloud CLI. W środowisku klastrowym ustal, na którym węźle wystąpił błąd, ponieważ log aplikacji i log usługi mogą znajdować się w różnych miejscach.

Brak zasobów jest prawdopodobną przyczyną awarii, gdy logi pokazują wyczerpanie limitu albo pomiary z czasu problemu wskazują brak miejsca, pamięci lub wolnych procesów. Porównaj kilka odczytów z okresu awarii, aby odróżnić stały limit od chwilowego wzrostu obciążenia.

W panelu hostingu sprawdź wolne miejsce, liczbę inode, pamięć, CPU, procesy PHP, połączenia i limity bazy danych. Poproś dostawcę o historię wykorzystania limitów. Serwer może ograniczać procesy lub czas CPU niezależnie od pojemności dysku.

Sprawdź `memory_limit` osobno dla WWW i CLI. Komunikat `Allowed memory size exhausted` oznacza, że proces PHP osiągnął skonfigurowany limit. Log powinien wskazać, czy limit osiągnęło żądanie, import czy zadanie konsolowe.

Brak miejsca może uniemożliwić zapis logów, sesji, cache lub plików tymczasowych. Nie usuwaj katalogów `var` bez sprawdzenia ich zawartości, bo mogą zawierać dane potrzebne do diagnozy.

Cache, indeksy, kolejki i cron sprawdź, gdy sklep odpowiada, ale pokazuje nieaktualny katalog, opóźnia zamówienia, nie wysyła wiadomości albo nie kończy importu. Te mechanizmy obsługują różne procesy, dlatego kontroluj je osobno.

Z katalogu Magento uruchom `bin/magento cache:status`, aby sprawdzić status typów cache, oraz `bin/magento indexer:status`, aby odczytać status indeksów. Polecenia wymagają dostępu do właściwego środowiska i odpowiednich uprawnień. Nie uruchamiaj czyszczenia cache ani pełnego reindeksowania na produkcji jako testu, jeśli nie znasz ich wpływu na obciążenie.

Zadania cron sprawdź w `var/log/cron.log` i tabeli `cron_schedule`. Dokumentacja Adobe wskazuje, że informacje cron trafiają do osobnego `cron.log`, a tabela `cron_schedule` przechowuje historię zadań. Informacje sprawdziliśmy w październiku 2026 roku: konfiguracja i logowanie cron w Adobe Commerce.

Przy kolejkach sprawdź dostępność brokera, działanie konsumentów i liczbę oczekujących komunikatów. Jeśli problem dotyczy jednej integracji, zachowaj identyfikator komunikatu i odpowiedź API przed próbą ponownego przetworzenia.

Aktualizacja lub integracja mogła wywołać awarię, jeśli początek błędu pokrywa się z wdrożeniem, zmianą konfiguracji albo odpowiedzią zewnętrznego API. Porównaj czas problemu z historią prac i logami funkcji, która przestała działać.

Po aktualizacji modułu sprawdź jego zgodność z wydaniem Magento oraz wyjątki związane z obsługiwaną funkcją. Po zmianie PHP porównaj wersję z macierzą Adobe i zweryfikuj rozszerzenia. Jeśli błąd ogranicza się do płatności, wysyłki lub importu, sprawdź odpowiedź integracji przed uznaniem, że nie działa cały hosting.

Wycofuj zmianę tylko wtedy, gdy znasz jej zakres, masz sprawdzoną procedurę cofnięcia i aktualną kopię. Przy zmianie bazy samo przywrócenie plików może nie odtworzyć zgodnego stanu sklepu. Określ warunek przerwania operacji i oceniaj skutek po każdej zmianie.

Administratorowi przekaż domenę, URL błędu, kod HTTP, czas wystąpienia, wersje środowiska i fragmenty logów z tego samego okresu. Dodaj informację, które funkcje sklepu są niedostępne i jak awaria wpływa na klientów.

Dane do zgłoszenia

• Domena, URL i sposób odtworzenia problemu.
• Data, godzina i strefa czasowa.
• Wersja Magento, PHP dla WWW i CLI oraz silnik bazy danych.
• Wpisy z logów WWW, PHP i Magento, w tym `exception.log` lub `system.log`.
• Ostatnia zmiana, po której problem mógł wystąpić.
• Oczekiwany rezultat, na przykład przywrócenie checkoutu.

Nie wysyłaj haseł, tokenów API, pełnych danych klientów ani konfiguracji zawierającej sekrety. Poproś o opis przyczyny, wykonanej poprawki i kontroli po zmianie.

Po naprawie przejdź ścieżkę klienta i sprawdź produkt, koszyk oraz checkout. Zamówienie testowe wykonaj na środowisku testowym albo w trybie testowym operatora płatności, który nie obciąża klienta. Potwierdź wynik w panelu, status zamówienia i logi.

Perspektywa KC Mobile: Diagnoza incydentu powinna odtworzyć konkretną operację, która zawiodła. Sama strona główna nie potwierdza poprawnego działania checkoutu, płatności ani aktualizacji stanów.

Jeśli awarie skłaniają Cię do zmiany platformy, zespół tworzący sklepy internetowe na WooCommerce może ocenić katalog i wymagane integracje. Po przywróceniu sprzedaży opieka nad sklepem internetowym może objąć kontrolę aktualizacji i działania witryny.

• Dlaczego sklep Magento nie działa poprawnie w Polsce? Lista przyczyn i diagnostyka
• Obsługa sklepu Magento: co obejmuje stała opieka techniczna
• Dlaczego budowa sklepu na Shopify nie działa i jak znaleźć przyczynę
• Magento 1 w firmie: jak ocenić ryzyko i zaplanować dalsze działanie