23 pytań w tym temacie
Rozwiń pytanie, żeby zobaczyć odpowiedź. Treść jest widoczna w HTML i może być indeksowana przez wyszukiwarki.
301. Co zrobić przy błędzie 400?
Błąd 400 diagnozujemy od adresu URL, godziny wystąpienia, zakresu problemu i ostatnich zmian w aplikacji. Część błędów wynika z uprawnień, część z PHP/CMS, limitów LVE, DNS, ModSecurity albo zewnętrznych usług.
W zgłoszeniu podaj URL, zrzut lub treść błędu, swój adres IP, godzinę i informację, czy problem występuje wszystkim użytkownikom czy tylko części.
302. Co zrobić przy błędzie 401?
Błąd 401 diagnozujemy od adresu URL, godziny wystąpienia, zakresu problemu i ostatnich zmian w aplikacji. Część błędów wynika z uprawnień, część z PHP/CMS, limitów LVE, DNS, ModSecurity albo zewnętrznych usług.
W zgłoszeniu podaj URL, zrzut lub treść błędu, swój adres IP, godzinę i informację, czy problem występuje wszystkim użytkownikom czy tylko części.
303. Co zrobić przy błędzie 403?
Błąd 403 oznacza brak dostępu do zasobu. Przyczyny: złe uprawnienia plików/katalogów, brak pliku index, blokada w .htaccess, Directory Privacy, ModSecurity/WAF/Imunify360, blokada IP albo próba listowania katalogu. Standardowo katalogi mają 755, pliki 644, a public_html musi być dostępny dla serwera WWW. Szczegóły zwykle są w cPanel → Errors lub error_log.
304. Co zrobić przy blokadzie ModSecurity?
Blokada ModSecurity oznacza, że zapora aplikacyjna uznała żądanie za podobne do ataku, np. SQL injection, XSS albo podejrzany formularz. Jeśli legalna operacja jest blokowana, nie wyłączaj ochrony globalnie bez analizy.
Podaj supportowi URL, godzinę, swój adres IP, treść komunikatu i opis czynności. Support sprawdzi regułę i oceni, czy to false positive, błąd aplikacji czy realne zagrożenie.
305. Co zrobić przy błędzie 404?
Błąd 404 oznacza, że serwer nie znalazł wskazanego URL. Należy sprawdzić, czy plik istnieje w prawidłowym document root, czy domena wskazuje właściwy katalog, czy nie ma błędnych przekierowań i czy aplikacja ma poprawne reguły rewrite. W WordPressie często pomaga zapisanie Ustawienia → Bezpośrednie odnośniki albo odtworzenie .htaccess. W cPanelu warto sprawdzić Domains, File Manager i Errors.
306. Co zrobić przy błędzie 405?
Błąd 405 diagnozujemy od adresu URL, godziny wystąpienia, zakresu problemu i ostatnich zmian w aplikacji. Część błędów wynika z uprawnień, część z PHP/CMS, limitów LVE, DNS, ModSecurity albo zewnętrznych usług.
W zgłoszeniu podaj URL, zrzut lub treść błędu, swój adres IP, godzinę i informację, czy problem występuje wszystkim użytkownikom czy tylko części.
307. Co zrobić przy błędzie 500?
Błąd 500 diagnozujemy od adresu URL, godziny wystąpienia, zakresu problemu i ostatnich zmian w aplikacji. Część błędów wynika z uprawnień, część z PHP/CMS, limitów LVE, DNS, ModSecurity albo zewnętrznych usług.
W zgłoszeniu podaj URL, zrzut lub treść błędu, swój adres IP, godzinę i informację, czy problem występuje wszystkim użytkownikom czy tylko części.
308. Co zrobić przy błędzie 502?
Błąd 502 diagnozujemy od adresu URL, godziny wystąpienia, zakresu problemu i ostatnich zmian w aplikacji. Część błędów wynika z uprawnień, część z PHP/CMS, limitów LVE, DNS, ModSecurity albo zewnętrznych usług.
W zgłoszeniu podaj URL, zrzut lub treść błędu, swój adres IP, godzinę i informację, czy problem występuje wszystkim użytkownikom czy tylko części.
309. Co zrobić przy błędzie 503?
Błąd 503 oznacza, że aplikacja lub proces obsługujący stronę chwilowo nie jest dostępny. Najczęstsze przyczyny to przekroczenie limitów zasobów, zbyt wiele procesów PHP, problem z PHP-FPM/Passenger, prace serwisowe aplikacji albo awaria zależności. Klient powinien sprawdzić cPanel → Errors/error_log oraz Resource Usage, a następnie wyłączyć podejrzane wtyczki, cache lub zadania cron. Przy powtarzalnych 503 warto zoptymalizować stronę albo zmienić pakiet.
310. Co zrobić przy błędzie 504?
Błąd 504 diagnozujemy od adresu URL, godziny wystąpienia, zakresu problemu i ostatnich zmian w aplikacji. Część błędów wynika z uprawnień, część z PHP/CMS, limitów LVE, DNS, ModSecurity albo zewnętrznych usług.
W zgłoszeniu podaj URL, zrzut lub treść błędu, swój adres IP, godzinę i informację, czy problem występuje wszystkim użytkownikom czy tylko części.
311. Co zrobić, gdy strona działa tylko u części użytkowników?
Dla tematu „co zrobić, gdy strona działa tylko u części użytkowników” najpierw sprawdź ustawienie w logach strony, DNS, SSL i ostatnich zmianach w aplikacji.
Jeżeli problem występuje tylko u części użytkowników albo tylko w wybranej funkcji strony, trzeba rozdzielić DNS, cache przeglądarki, cache aplikacji, CDN/proxy, sesje, formularze, bazę danych i integracje zewnętrzne.
W zgłoszeniu podaj kroki odtworzenia, konto testowe jeśli jest potrzebne, URL, godzinę, przeglądarkę, adres IP i ostatnie zmiany w CMS lub sklepie.
312. Co zrobić, gdy po migracji widać starą stronę?
Dla tematu „co zrobić, gdy po migracji widać starą stronę” najpierw sprawdź ustawienie w logach strony, DNS, SSL i ostatnich zmianach w aplikacji.
Jeżeli problem występuje tylko u części użytkowników albo tylko w wybranej funkcji strony, trzeba rozdzielić DNS, cache przeglądarki, cache aplikacji, CDN/proxy, sesje, formularze, bazę danych i integracje zewnętrzne.
W zgłoszeniu podaj kroki odtworzenia, konto testowe jeśli jest potrzebne, URL, godzinę, przeglądarkę, adres IP i ostatnie zmiany w CMS lub sklepie.
313. Co zrobić, gdy cache DNS lub przeglądarki pokazuje starą wersję?
Dla tematu „co zrobić, gdy cache DNS lub przeglądarki pokazuje starą wersję” najpierw sprawdź ustawienie w logach strony, DNS, SSL i ostatnich zmianach w aplikacji.
Jeżeli problem występuje tylko u części użytkowników albo tylko w wybranej funkcji strony, trzeba rozdzielić DNS, cache przeglądarki, cache aplikacji, CDN/proxy, sesje, formularze, bazę danych i integracje zewnętrzne.
W zgłoszeniu podaj kroki odtworzenia, konto testowe jeśli jest potrzebne, URL, godzinę, przeglądarkę, adres IP i ostatnie zmiany w CMS lub sklepie.
314. Co zrobić, gdy strona okresowo zwalnia?
Dla tematu „co zrobić, gdy strona okresowo zwalnia” najpierw sprawdź ustawienie w logach strony, DNS, SSL i ostatnich zmianach w aplikacji.
Jeżeli problem występuje tylko u części użytkowników albo tylko w wybranej funkcji strony, trzeba rozdzielić DNS, cache przeglądarki, cache aplikacji, CDN/proxy, sesje, formularze, bazę danych i integracje zewnętrzne.
W zgłoszeniu podaj kroki odtworzenia, konto testowe jeśli jest potrzebne, URL, godzinę, przeglądarkę, adres IP i ostatnie zmiany w CMS lub sklepie.
315. Co zrobić, gdy panel CMS działa, a frontend nie?
Dla tematu „co zrobić, gdy panel CMS działa, a frontend nie” najpierw sprawdź ustawienie w logach strony, DNS, SSL i ostatnich zmianach w aplikacji.
Jeżeli problem występuje tylko u części użytkowników albo tylko w wybranej funkcji strony, trzeba rozdzielić DNS, cache przeglądarki, cache aplikacji, CDN/proxy, sesje, formularze, bazę danych i integracje zewnętrzne.
W zgłoszeniu podaj kroki odtworzenia, konto testowe jeśli jest potrzebne, URL, godzinę, przeglądarkę, adres IP i ostatnie zmiany w CMS lub sklepie.
316. Co zrobić, gdy frontend działa, a panel CMS nie?
Dla tematu „co zrobić, gdy frontend działa, a panel CMS nie” najpierw sprawdź ustawienie w logach strony, DNS, SSL i ostatnich zmianach w aplikacji.
Jeżeli problem występuje tylko u części użytkowników albo tylko w wybranej funkcji strony, trzeba rozdzielić DNS, cache przeglądarki, cache aplikacji, CDN/proxy, sesje, formularze, bazę danych i integracje zewnętrzne.
W zgłoszeniu podaj kroki odtworzenia, konto testowe jeśli jest potrzebne, URL, godzinę, przeglądarkę, adres IP i ostatnie zmiany w CMS lub sklepie.
317. Co zrobić, gdy formularz kontaktowy nie działa?
Dla tematu „co zrobić, gdy formularz kontaktowy nie działa” najpierw sprawdź ustawienie w logach strony, DNS, SSL i ostatnich zmianach w aplikacji.
Jeżeli problem występuje tylko u części użytkowników albo tylko w wybranej funkcji strony, trzeba rozdzielić DNS, cache przeglądarki, cache aplikacji, CDN/proxy, sesje, formularze, bazę danych i integracje zewnętrzne.
W zgłoszeniu podaj kroki odtworzenia, konto testowe jeśli jest potrzebne, URL, godzinę, przeglądarkę, adres IP i ostatnie zmiany w CMS lub sklepie.
318. Co zrobić, gdy upload plików nie działa?
Dla tematu „co zrobić, gdy upload plików nie działa” najpierw sprawdź ustawienie w logach strony, DNS, SSL i ostatnich zmianach w aplikacji.
Jeżeli problem występuje tylko u części użytkowników albo tylko w wybranej funkcji strony, trzeba rozdzielić DNS, cache przeglądarki, cache aplikacji, CDN/proxy, sesje, formularze, bazę danych i integracje zewnętrzne.
W zgłoszeniu podaj kroki odtworzenia, konto testowe jeśli jest potrzebne, URL, godzinę, przeglądarkę, adres IP i ostatnie zmiany w CMS lub sklepie.
319. Co zrobić, gdy sesje/logowanie w aplikacji nie działają?
Dla tematu „co zrobić, gdy sesje/logowanie w aplikacji nie działają” najpierw sprawdź ustawienie w logach strony, DNS, SSL i ostatnich zmianach w aplikacji.
Jeżeli problem występuje tylko u części użytkowników albo tylko w wybranej funkcji strony, trzeba rozdzielić DNS, cache przeglądarki, cache aplikacji, CDN/proxy, sesje, formularze, bazę danych i integracje zewnętrzne.
W zgłoszeniu podaj kroki odtworzenia, konto testowe jeśli jest potrzebne, URL, godzinę, przeglądarkę, adres IP i ostatnie zmiany w CMS lub sklepie.
320. Co zrobić, gdy sklep nie finalizuje zamówień?
Dla tematu „co zrobić, gdy sklep nie finalizuje zamówień” najpierw sprawdź ustawienie w logach strony, DNS, SSL i ostatnich zmianach w aplikacji.
Jeżeli problem występuje tylko u części użytkowników albo tylko w wybranej funkcji strony, trzeba rozdzielić DNS, cache przeglądarki, cache aplikacji, CDN/proxy, sesje, formularze, bazę danych i integracje zewnętrzne.
W zgłoszeniu podaj kroki odtworzenia, konto testowe jeśli jest potrzebne, URL, godzinę, przeglądarkę, adres IP i ostatnie zmiany w CMS lub sklepie.
321. Co zrobić, gdy API zewnętrzne przestało odpowiadać?
Dla tematu „co zrobić, gdy API zewnętrzne przestało odpowiadać” najpierw sprawdź ustawienie w logach strony, DNS, SSL i ostatnich zmianach w aplikacji.
Jeżeli problem występuje tylko u części użytkowników albo tylko w wybranej funkcji strony, trzeba rozdzielić DNS, cache przeglądarki, cache aplikacji, CDN/proxy, sesje, formularze, bazę danych i integracje zewnętrzne.
W zgłoszeniu podaj kroki odtworzenia, konto testowe jeśli jest potrzebne, URL, godzinę, przeglądarkę, adres IP i ostatnie zmiany w CMS lub sklepie.
322. Jakie dane klient ma zawsze podac w zgloszeniu awarii?
W zgłoszeniu awarii zawsze podaj: adres strony, dokładny URL, godzinę problemu, komunikat błędu, swój adres IP, ostatnie zmiany, używaną przeglądarkę oraz informację, czy problem dotyczy wszystkich użytkowników.
Jeżeli chodzi o pocztę, dodaj nadawcę, odbiorcę, temat, zwrotkę SMTP i nagłówki. Jeżeli chodzi o CMS/sklep, dodaj ostatnie aktualizacje, wtyczki i logi, jeśli są dostępne.
10281. Jak skonfigurować własne strony błędów?
Własne strony błędów konfiguruje się w cPanel → Advanced → Error Pages albo ręcznie w .htaccess przez dyrektywę ErrorDocument, np. ErrorDocument 404 /404.html. Plik strony błędu musi istnieć w katalogu strony i nie powinien sam generować błędów. W aplikacjach CMS często lepiej skonfigurować stronę 404 w motywie lub wtyczce, aby zachować wygląd serwisu.