Klient pisze, że sklep "go nie wpuszcza". Zobaczył stronę Cloudflare z czterocyfrowym kodem, zrezygnował i kupił gdzie indziej. W logach serwera nic nie ma, bo żądanie nie przeszło przez Cloudflare. Zdarza się to w sklepach WooCommerce, na firmowych stronach WordPress zbierających zapytania, na frontendach headless w Astro albo Next.js i w każdej aplikacji schowanej za proxy Cloudflare. Przyczyną prawie zawsze jest reguła w twojej własnej strefie, a Cloudflare zapisuje, która to była.
Poniżej kolejność, która się sprawdza: zdobyć Ray ID, wyszukać je, odczytać, która funkcja zadziałała, a potem zawęzić ją tak, żeby przestała łapać kupujących i powiadomienia z bramek płatności. Każde opisane tu zachowanie pochodzi z dokumentacji deweloperskiej Cloudflare według stanu na październik 2026.
Co oznacza błąd Cloudflare 1015, 1020 i 1009
Kod mówi, gdzie szukać. Wpis na r/CloudFlare z 21 października 2026 zebrał te kody w jednym miejscu, a każdy z nich zgadza się z oficjalnymi stronami pomocy Cloudflare:
- 1015 (HTTP 429): zadziałała reguła rate limiting. Cloudflare radzi przejrzeć progi, a jeśli reguła zlicza żądania w bardzo krótkim okresie, na przykład jednej sekundy, spróbować 10 sekund.
- 1020 (HTTP 403): reguła bezpieczeństwa z akcją Block bez własnej odpowiedzi. Strona o błędzie 1020 jako przykłady podaje walidację schematu API Shield i walidację JWT, i zaznacza, że reguły własne WAF i reguły zarządzane już nie zwracają 1020. Pokazują wtedy stronę blokady WAF.
- 1009 (HTTP 403): blokada kraju lub regionu ustawiona w IP Access rules. Blokowanie krajów w tym miejscu jest dostępne tylko w planie Enterprise. W pozostałych planach blokada kraju to reguła własna, a ta pokazuje stronę blokady WAF.
- 1010 (HTTP 403): Browser Integrity Check odrzucił sygnaturę przeglądarki.
- “Just a moment…” albo strona z wyzwaniem: Managed Challenge z reguły własnej, reguły rate limiting, Bot Fight Mode albo Under Attack Mode.
Szczegół z 1020 oszczędza godziny. Jeśli przekopujesz reguły własne w poszukiwaniu tej, która zwróciła 1020, szukasz na złej liście.
Gdzie znaleźć Ray ID na stronie błędu Cloudflare
Poproś klienta o zrzut ekranu całej strony błędu. Jest na nim kod, Ray ID i znacznik czasu w UTC. Autor tamtego wątku dopisał w odpowiedzi:
kod to ta łatwa część, ludzie przeoczają ray id na tym samym ekranie. wklejasz go w security events i widzisz, która z twoich własnych reguł zadziałała.
(u/Hot_Bee_5451, r/CloudFlare, 22 października 2026, tłumaczenie własne)
Ray ID dostaje każde żądanie przechodzące przez Cloudflare i trafia ono do twojego serwera w nagłówku cf-ray. Cloudflare zastrzega, że Ray ID nie muszą być unikalne, więc sprawdź też czas i adres IP. Jeśli klient nie może przysłać zrzutu, poproś o jego publiczny adres IP, przybliżoną godzinę i kraj. Przy nieudanych wyzwaniach jest jeszcze druga droga, podsunięta w innym wątku:
No możesz podać administratorowi strony RayID, który powstaje przy tym teście, a on sprawdzi dokładny powód, dla którego go nie przeszedłeś.
(u/Logvin, r/CloudFlare, 21 października 2026, tłumaczenie własne)
Jak wyszukać Ray ID w Security Events
W panelu otwórz Security > Analytics i kartę Events. Dodaj filtr po Ray ID albo po IP klienta i ustaw zakres czasu obejmujący zgłoszenie. Najpierw przelicz czas UTC ze strony błędu na swoją strefę czasową, na co strona Cloudflare o błędzie 1020 zwraca wprost uwagę.
Z dokumentacji Security Events ważne są tu dwa ograniczenia. Dane są przechowywane do 31 dni. Lista korzysta z logów próbkowanych, więc w strefie z dużym ruchem pojedyncze żądanie może się nie pojawić. Jeśli wyszukiwanie po Ray ID nic nie zwraca, zawęź okno czasu do kilku minut i filtruj po IP: im mniejsze okno, tym więcej zdarzeń widać. Jedno żądanie może też wygenerować kilka zdarzeń, jeśli zajęło się nim kilka funkcji.
Która reguła Cloudflare zablokowała klienta
Rozwiń zdarzenie. Pole Service podaje nazwę funkcji, a przy regułach dostajesz też nazwę lub identyfikator reguły. Co zwykle oznacza każda wartość:
- Reguły własne (custom rules): twoje własne wyrażenie. Typowi winowajcy to blokady krajów, blokady ASN wymierzone w firmy hostingowe (łapiące przy okazji użytkowników VPN) i zbyt szerokie reguły na ścieżki
/wp-login.phpalbo/checkout. - Reguły zarządzane (managed rules): sygnatura Cloudflare albo OWASP dopasowała coś w żądaniu. Uruchamiają je długie zapytania w wyszukiwarce, pola formularzy z fragmentami kodu i niektóre dane wysyłane przez page buildery.
- Reguły rate limiting: przypadek 1015. Kupujący za jednym adresem IP biura albo operatora komórkowego dzielą licznik, gdy reguła zlicza po IP.
- Bot Fight Mode albo Super Bot Fight Mode: produkty do walki z botami. Dokumentacja botów Cloudflare podaje, że oba mogą wystawiać wyzwania ruchowi z API albo aplikacji mobilnych.
- Security Level albo Under Attack Mode: ekran pośredni dla całej strefy.
Usunięta reguła wyświetla się jako “Rule unavailable”. Kto ją usunął albo zmienił, sprawdzisz w dzienniku audytu.
Jak dodać wyjątek w WAF Cloudflare, nie otwierając całej strony
Rozwiązaniem jest reguła własna z akcją Skip (reguła pomijająca), umieszczona nad regułą, która zablokowała, i dopasowana wyłącznie do ruchu, któremu ufasz. Opcje pomijania pozwalają pominąć wszystkie pozostałe reguły własne, wszystkie reguły rate limiting, wszystkie reguły zarządzane i wszystkie reguły Super Bot Fight Mode. Przez API możesz też pominąć Browser Integrity Check, Security Level, User Agent Blocking, Zone Lockdown i Hotlink Protection. Reguły własne wykonują się po kolei, więc pozycja ma znaczenie.
Trzymaj wyrażenie wąsko. Rozszerzenie Stripe dla WooCommerce używa jako punktu odbioru webhooków wyłącznie /?wc-api=wc_stripe:
(http.request.uri.query contains "wc-api=wc_stripe" and ip.src in $stripe_webhooks)$stripe_webhooks to lista IP, którą tworzysz z opublikowanych adresów IP webhooków Stripe. Dla integracji sklepu, która woła REST API WooCommerce ze stałego serwera:
(starts_with(http.request.uri.path, "/wp-json/wc/") and ip.src in $erp_servers)Przy fałszywym alarmie, który trafił prawdziwych kupujących, często lepiej poprawić pierwotną regułę zamiast dokładać wyjątek: wydłużyć okres rate limitingu, ograniczyć blokadę kraju do /wp-login.php albo zamienić Block na Managed Challenge. W regule pomijającej zostaw włączone Log matching requests, żeby widzieć, że działa.
Dlaczego Cloudflare blokuje webhooki Stripe i REST API WooCommerce
Wywołania serwer-serwer nie mają przeglądarki, więc nie rozwiążą wyzwania JavaScript. Każda funkcja, która zamiast blokować wystawia wyzwanie, i tak je psuje. Właściciel sklepu opisał dokładnie to na r/CloudFlare:
Kiedy włączam Under Attack Mode, ruch z Singapuru znika z GA4. Ale Under Attack Mode spowalnia stronę, a moje wywołania API serwer-serwer (WooCommerce REST API) dostają wyzwanie Cloudflare “Just a moment…” i przez to nie przechodzą.
(u/lastoneinbatumi, r/CloudFlare, 19 października 2026, tłumaczenie własne)
Skutki zależą od dostawcy. Stripe ponawia nieudany webhook z wykładniczym odstępem przez maksymalnie trzy dni w trybie live, więc zamówienia wiszące jako “oczekujące na płatność” zwykle wracają do normy po poprawieniu reguły. Shopify ponawia do ośmiu razy w ciągu czterech godzin, a potem usuwa subskrypcję. To ważne, jeśli twoja aplikacja albo backend headless odbiera webhooki Shopify za strefą Cloudflare. Po każdej zmianie zabezpieczeń sprawdź w panelu każdego dostawcy nieudane dostarczenia.
Under Attack Mode to ostateczność na czas ataku. Strona o Security Level zaleca włączanie i wyłączanie go regułą konfiguracyjną dla API albo dowolnej innej części domeny. Trzymaj go wyłączonego dla /wp-json/, ścieżek webhooków i hosta API.
Z tego samego wątku płynie druga lekcja. Jeśli zablokowany ruch dalej pojawia się w analityce, sprawdź, czy w ogóle przechodzi przez Cloudflare:
Czy twój hosting jest ustawiony tak, żeby przyjmować ruch tylko z i do Cloudflare? Inaczej da się do niego wejść bezpośrednio po ip
(u/Wilbo007, r/CloudFlare, 19 października 2026, tłumaczenie własne)
Dokumentacja adresów IP Cloudflare zaleca blokowanie na serwerze ruchu, który nie pochodzi z Cloudflare ani od zaufanych partnerów. W tej zaporze na serwerze dopuść też adresy swoich operatorów płatności.
Czy reguła WAF ominie Bot Fight Mode
Nie. Strona o Bot Fight Mode mówi, że nie da się go obejść ani pominąć regułami własnymi WAF ani Page Rules, bo nie działa na Ruleset Engine, więc Skip, Bypass i Allow nic nie zmieniają. Strona z opcjami pomijania powtarza, że pominąć można tylko Super Bot Fight Mode. Udokumentowany jest jeden wyjątek: Bot Fight Mode nie zadziała, jeśli żądanie wcześniej dopasuje reguła IP Access.
W planie Free, gdy Bot Fight Mode wystawia wyzwania operatorowi płatności, systemowi ERP albo monitoringowi dostępności, masz więc trzy wyjścia: regułę IP Access dopuszczającą adresy tego dostawcy, wyłączenie Bot Fight Mode albo przejście na płatny plan, w którym Super Bot Fight Mode przyjmuje reguły pomijające. Super Bot Fight Mode ma też ustawienie Optimize for WordPress, które przepuszcza żądania loopback WordPressa, co usuwa błędy w Site Health bez pisania reguły własnej.
Blokada Cloudflare: objaw, przyczyna i poprawka w tabeli
| Co widzi klient albo log | Prawdopodobna reguła | Poprawka |
|---|---|---|
| Błąd 1015, HTTP 429 | Reguła rate limiting | Dłuższy okres zliczania, wyższy próg albo pominięcie rate limitingu dla zaufanych IP |
| Strona blokady WAF, HTTP 403, bez kodu 1xxx | Reguła własna WAF albo reguła zarządzana | Znajdź regułę po Ray ID; zawęź wyrażenie albo dodaj nad nią regułę Skip |
| Błąd 1020, HTTP 403 | Inny Block bez własnej odpowiedzi (na przykład API Shield) | Szukaj w Security Events, nie w regułach własnych |
| Błąd 1009 | Blokada kraju w IP Access rules | Dopuść IP odwiedzającego albo przenieś geoblokadę do zawężonej reguły własnej |
| Błąd 1010 | Browser Integrity Check | Pomiń go dla danej ścieżki przez API albo wyłącz |
| Pętla wyzwań na każdej stronie | Under Attack Mode albo Security Level | Wyłącz albo ogranicz regułą konfiguracyjną |
| Webhook albo REST API nie działa, bez udziału człowieka | Bot Fight Mode, Under Attack Mode albo reguła z wyzwaniem | Dopuszczenie w IP Access albo reguła Skip dla Super Bot Fight Mode; UAM wyłączony na ścieżkach API |
| Nic w Security Events | Próbkowanie, zła strefa czasowa albo żądanie nie dotarło do Cloudflare | Mniejsze okno czasu, filtr po IP; sprawdź DNS i zaporę na serwerze |
Jak monitorować blokady Cloudflare po poprawce
Nie kończ na jednym kliencie. W Security Events ustaw filtr Action równy Block albo Managed Challenge i pogrupuj po ścieżce. Żądania do /checkout, /cart, /my-account, /wp-json/ albo do endpointu formularza kontaktowego to te, które kosztują pieniądze. Adres przefiltrowanego widoku można udostępnić, więc współpracownik zobaczy to samo. Do 500 próbkowanych zdarzeń da się wyeksportować jako JSON.
Potem sprawdź drugą stronę: nieudane dostarczenia w Stripe, PayPal albo Shopify, zamówienia WooCommerce wiszące jako oczekujące i liczbę wysłanych formularzy kontaktowych dziennie. Spadek dzień po zmianie zabezpieczeń wskazuje prosto na dodaną regułę. Takie przeglądy reguł obejmuje nasza usługa Cloudflare edge, a opieka techniczna WooCommerce zawiera ten monitoring dla sklepów.
Do poczytania dalej: czy ustawienia botów AI w Cloudflare zatrzymują też roboty wyszukiwarek, opisuje wpis czy Cloudflare blokuje Googlebota. Ile ruchu na małej stronie generują automaty i dlaczego kusi to do zbyt ostrych reguł dla botów, pokazuje nasz pomiar 72% naszego ruchu to nie przeglądarka. O przenoszeniu logiki na brzeg sieci przeczytasz w poradniku Cloudflare Workers i WooCommerce.
