Gdy strona za Cloudflare nie wstaje, winnych może być kilku: cała sieć, jeden jej komponent, twój serwer albo twoje łącze. Zanim cokolwiek zmienisz, sprawdź oficjalną stronę statusu, porównaj dwie sieci i dopiero potem wybierz działanie. Ten tekst prowadzi cię przez te trzy kroki po kolei.
Nie znajdziesz tu statusu na żywo. Zobaczysz, jak czytać komunikat właściciela usługi i jak nie ogłosić globalnej awarii na podstawie jednego błędu. Jeśli zawiódł inny dostawca niż Cloudflare, przejdź do sprawdzania statusu zewnętrznych usług.
Poniedziałek rano. Sklep internetowy Marty stoi za Cloudflare. Klienci piszą, że zamiast koszyka widzą błąd 502 z logo Cloudflare, a wspólnik dzwoni z gotową diagnozą, że Cloudflare padło i trzeba przenosić domenę. Marta zamiast tego otwiera stronę statusu - wszystkie komponenty zielone. Zagląda w logi swojego serwera i widzi, że po nocnej zmianie w sklepie aplikacja już nie wstała. Winny był jej serwer, nie Cloudflare. Gdyby pod presją zmieniła DNS, dołożyłaby sobie drugą awarię do pierwszej.
Gdzie sprawdzić, czy Cloudflare ma awarię?
Oficjalnym źródłem jest Cloudflare System Status. Sam nagłówek strony to za mało - znajdź komponent, z którego korzysta twoja strona lub aplikacja:
- CDN i cache, gdy publiczna strona zwraca błąd albo nie ładuje zasobów;
- Authoritative DNS, gdy domena nie zamienia się na adres;
- Dashboard lub API, gdy nie możesz zarządzać strefą;
- Workers, Pages albo R2, gdy błąd dotyczy tylko tej jednej funkcji;
- lokalizację sieciową, gdy problem widać z jednego regionu.
Otwórz też opis czynnego incydentu i historię wpisów. Wpis o gorszej pracy jednego komponentu nie oznacza awarii całej sieci. Z kolejnych wpisów wyczytasz, czy właściciel dopiero bada zgłoszenie, czy już wdraża poprawkę.
Ekran z logo Cloudflare i kodem 502 albo 504 nie wskazuje jeszcze winnego. Taki ekran dostarcza Cloudflare, ale przyczyna może siedzieć na twoim serwerze - dokładnie jak w sklepie Marty. Co znaczą oba kody i jak je naprawić, opisujemy osobno w tekstach o 502 Bad Gateway i 504 Gateway Timeout.
Jak sprawdzić, czy problem jest tylko u ciebie?
Zanim zaczniesz, zapisz pełny adres, kod HTTP, treść błędu i czas ze strefą. Bez tych danych nie porównasz prób i nie złożysz zgłoszenia. Potem wykonaj trzy testy, bez zmian w konfiguracji produkcyjnej:
- Otwórz ten sam adres przez swoje łącze i przez internet w telefonie. Błąd widoczny tylko w jednej sieci pasuje do problemu z lokalnym DNS, filtrem albo trasą operatora, nie do globalnej awarii.
- Sprawdź stronę na drugim urządzeniu, a na pierwszym w oknie prywatnym przeglądarki. Tak odcinasz rozszerzenia, ciasteczka i starą sesję. Jeśli panel Cloudflare nie otwiera się tylko w jednej przeglądarce, szukaj po stronie klienta, nie w sieci dostawcy.
- Jeśli zarządzasz domeną, porównaj ekran błędu z logami serwera źródłowego. Błąd podany na ekranie Cloudflare może pochodzić z twojej aplikacji. Własny serwer diagnozuj według runbooków błędów serwera.
Nie wyłączaj proxy ani ochrony tylko po to, żeby zrobić szybki test. Taka zmiana zostawia stronę bez osłony i myli wyniki kolejnych prób.
Co wolno wnioskować z trzech sygnałów?
Werdykt składa się z trzech niezależnych odczytów: oficjalnego statusu, zgłoszeń innych osób i twojego testu. Pojedynczy odczyt nie wystarcza do decyzji.
| Oficjalny status | Zgłoszenia z zewnątrz | Twój test | Wniosek | Następny krok |
|---|---|---|---|---|
| Incydent wskazuje twój komponent lub region | Wiele osób opisuje podobny objaw | Błąd widać w obu sieciach | Dostawca potwierdził incydent zgodny z obserwacją | Śledź wpisy o komponencie i wstrzymaj zmiany |
| Brak pasującego incydentu | Zgodne zgłoszenia rosną | Błąd widać w obu sieciach | Jest sygnał szerszego problemu bez potwierdzenia | Zbierz identyfikator żądania, region, czas i zgłoś problem |
| Brak pasującego incydentu | Cisza | Błąd tylko w jednej sieci lub przeglądarce | Zakres wygląda na lokalny | Sprawdź resolver, rozszerzenia, sesję i sieć firmową |
| Brak odczytu | Brak odczytu | Test niewykonany | Nie ma danych do werdyktu | Wykonaj odczyty, zanim cokolwiek zmienisz |
Zgłoszenia innych osób to wskaźnik, nie dowód przyczyny. Jedna poprawna odpowiedź też niczego nie zamyka - nie dowodzi, że działa każdy region i każdy komponent.
Co robić w czasie potwierdzonej awarii?
Ogranicz zmiany, które trudno cofnąć. Nie zmieniaj DNS pod presją bez gotowej i przećwiczonej procedury przejścia - pamięć resolverów potrafi mieszać ruch jeszcze długo po tym, jak usługa wróci.
Jeżeli padł panel, a ruch klientów działa, odłóż zmiany reguł na później i zapisz ich plan lokalnie. Jeżeli szwankuje dostarczanie treści, utrzymaj serwer źródłowy i zbieranie logów. Nie wyłączaj WAF, kontroli dostępu ani TLS jako obejścia na skróty - po awarii musiałbyś sprzątać po własnym obejściu.
Ludziom w firmie przekaż krótki komunikat, zanim znajdziesz przyczynę. Napisz, które domeny i funkcje nie działają, od kiedy, czy błąd widać w dwóch sieciach i gdzie pojawi się kolejna wiadomość. Taki komunikat gasi telefony i kupuje ci czas na diagnozę.
Co przekazać do supportu Cloudflare?
Dołącz do zgłoszenia domenę, pełny adres, czas ze strefą, kod HTTP, treść błędu, identyfikator żądania z ekranu błędu, nazwę operatora, region i wynik testu w drugiej sieci. Jeśli błąd dotyczy jednej usługi, nazwij ją w tytule zgłoszenia - "nie działa zapis do R2" mówi więcej niż "Cloudflare nie działa".
Tokeny API, hasła, klucze serwera i pełne ciasteczka zostają u ciebie. Support ich nie potrzebuje, a raz wysłane sekrety trzeba wymienić.
Pytania o awarie Cloudflare
Czy zielony status Cloudflare oznacza, że moja strona działa?
Nie. Zielony status opisuje stan komponentów widziany przez dostawcę. Twoja domena wciąż może mieć błąd serwera źródłowego, DNS, certyfikatu albo lokalnej trasy. Po odczycie statusu zrób test w drugiej sieci i zajrzyj do własnych logów.
Jak sprawdzić, czy awaria Cloudflare dotyczy Polski?
Na stronie statusu znajdź lokalizacje sieciowe w Polsce i w sąsiednich regionach oraz opis czynnego incydentu. Porównaj dostęp przez dwóch operatorów. Różny wynik wskazuje na problem trasy lub operatora, a zasięg potwierdza dopiero wpis właściciela usługi.
Czy podczas awarii Cloudflare zmieniać DNS?
Nie jako pierwszy ruch. Zmiana bez planu rozdzieli ruch między stare i nowe wpisy, a powrót będzie trudniejszy niż sama awaria. Przełączenie ma sens, gdy firma przygotowała zapasowy cel, wartości DNS i procedurę powrotu jeszcze przed incydentem.
Co zapisać przed zgłoszeniem problemu?
Czas ze strefą, domenę, pełny adres, kod i treść błędu, identyfikator żądania, nazwę operatora, region i wynik z drugiej sieci. Dołącz nazwę komponentu ze strony statusu. Hasła, tokeny i ciasteczka usuń z materiału przed wysyłką.
Gdzie sprawdzić historię incydentów Cloudflare?
Na oficjalnej stronie Cloudflare System Status, przy bieżących i zamkniętych zdarzeniach. Czytaj wpisy dla swojego komponentu, bo wspólny nagłówek potrafi objąć tylko część usługi. Historia pomaga porównać objaw, zasięg i etap obsługi incydentu.