429 Too Many Requests w WordPressie – przyczyny i diagnostyka

429 Too Many Requests oznacza, że klient wykonał zbyt wiele żądań w określonym czasie według zasad rate limitingu obowiązujących na danej warstwie. W przypadku WordPressa ograniczenie może pochodzić z CDN/WAF, hostingu, pluginu bezpieczeństwa, własnej aplikacji albo zewnętrznego API.

Sam kod 429 nie mówi jeszcze, jaki limit został przekroczony ani jak liczony jest ruch. Reguła może dotyczyć adresu IP, konkretnego endpointu, użytkownika, tokenu API albo kombinacji kilku cech.

Przy 429 najpierw ustal, kto zwrócił odpowiedź i według jakiej reguły liczone są żądania. Nie zwiększaj limitu ani nie wyłączaj ochrony tylko dlatego, że widzisz ten kod.

Co oznacza 429 Too Many Requests?

Kod 429 jest przeznaczony do sytuacji, w której klient przekroczył dopuszczalną częstotliwość żądań. Odpowiedź może zawierać nagłówek Retry-After informujący, kiedy klient powinien podjąć kolejną próbę.

Objaw	Pierwszy trop
429 pojawia się tylko przy logowaniu	Rate limit dla loginu, ochrona brute force lub WAF
429 dotyczy REST API	Limit endpointu, tokenu, IP albo zewnętrznego proxy
Tylko jedno IP dostaje 429	Reguła liczona per IP lub czasowa blokada
Wszyscy użytkownicy dostają 429	Globalna reguła, błędna konfiguracja licznika albo limit zewnętrznej usługi
Po chwili problem znika bez zmian	Okno rate limitingu lub mitigation timeout

Ważne jest rozróżnienie między rate limitingiem a zwykłym przeciążeniem. Serwer może być całkowicie zdrowy, a mimo to celowo odrzucać część żądań po przekroczeniu skonfigurowanego progu.

Najpierw ustal, która warstwa generuje 429

W typowej instalacji żądanie może przechodzić przez kilka systemów:

użytkownik / bot
    ↓
CDN / WAF
    ↓
serwer WWW / hosting
    ↓
WordPress / plugin
    ↓
zewnętrzne API

Każda z tych warstw może stosować własny rate limit. Dlatego przy diagnozie sprawdź nagłówki i treść odpowiedzi 429, logi WAF/CDN, logi serwera i pluginów bezpieczeństwa oraz miejsce, w którym pojawia się problem.

Istotne jest również to, czy błąd dotyczy publicznej strony, logowania, REST API, pojedynczego requestu AJAX czy zapytania wysyłanego przez WordPress do zewnętrznej usługi. Jeżeli zwykła strona HTML działa, ale jeden endpoint zwraca 429, diagnozę zacznij od tego requestu, a nie od całej instalacji WordPressa.

Rate limit nie musi być liczony wyłącznie po adresie IP

Popularny model to „N żądań z jednego IP w X sekund”, ale nie jest to jedyna możliwość. Reguła może uwzględniać między innymi:

• adres IP,
• ścieżkę URL,
• użytkownika,
• token lub klucz API,
• nagłówek,
• kraj lub inną cechę ruchu,
• kombinację kilku parametrów.

Ma to znaczenie przy ruchu za NAT, proxy albo w sieci firmowej. Kilkudziesięciu użytkowników może wychodzić do internetu przez jeden publiczny adres IP i wspólnie przekroczyć limit liczony per IP. Z kolei limit oparty na tokenie API może objąć requesty z wielu różnych adresów, jeżeli wszystkie korzystają z tego samego klucza.

CDN i WAF często nakładają rate limit przed WordPressem

Warstwa bezpieczeństwa może odrzucić request, zanim dotrze on do originu. WordPress i PHP nie zobaczą wtedy takiego żądania.

Reguła może chronić na przykład:

• /wp-login.php,
• /wp-json/,
• formularz kontaktowy,
• wyszukiwarkę,
• checkout,
• inny endpoint podatny na automatyczne nadużycia.

W Cloudflare reguła rate limitingu określa między innymi warunki dopasowania ruchu, sposób prowadzenia liczników, okres, liczbę requestów oraz czas obowiązywania akcji po przekroczeniu progu. Przy akcji Block domyślnym kodem odpowiedzi jest 429, ale można skonfigurować inny kod z zakresu 400–499.

Jeżeli w logach originu nie ma problematycznego requestu, a warstwa CDN/WAF pokazuje aktywację reguły rate limitingu, szukanie przyczyny w PHP prowadzi w złą stronę.

Login i REST API wymagają innego spojrzenia niż zwykłe odsłony

Kilkadziesiąt żądań do strony produktu może być normalnym ruchem, podczas gdy kilkadziesiąt prób logowania w kilka sekund może odpowiadać wzorcowi brute force. Endpoint API wykorzystywany przez integrację może z kolei legalnie obsługiwać dużo requestów i wymagać innej polityki niż ruch użytkowników.

Przy 429 liczy się więc nie tylko liczba żądań. Trzeba wiedzieć, do jakiej ścieżki trafiały, kto je wykonywał, czy ruch był interaktywny czy automatyczny i czy odpowiadał normalnemu sposobowi pracy aplikacji.

Jeżeli jeden poprawny proces automatyczny wpada w limit, globalne zwiększenie progów nie musi być najlepszym rozwiązaniem. Czasem wystarczy dokładniej określić zakres reguły albo oddzielić ten endpoint od pozostałego ruchu.

Jak klient powinien reagować na 429?

Odpowiedź 429 może zawierać nagłówek Retry-After. Wartość może być podana jako liczba sekund do kolejnej próby albo jako konkretna data w formacie HTTP-date. Nie każdy serwer zwraca ten nagłówek przy 429.

HTTP/1.1 429 Too Many Requests
Retry-After: 60

Retry-After jest wskazówką dla klienta, a nie gwarancją, że po wskazanym czasie zniknie każda możliwa blokada. RFC nie narzuca sposobu identyfikowania klienta ani metody liczenia requestów, dlatego zachowanie zależy również od konkretnej implementacji rate limitingu.

Klient API powinien respektować Retry-After, jeżeli nagłówek występuje, i ograniczyć częstotliwość kolejnych prób. Natychmiastowe ponawianie requestu po każdym 429 może samo podtrzymywać problem albo spowodować ponowne przekroczenie limitu zaraz po otwarciu kolejnego okna.

W automatycznych integracjach stosuje się więc ograniczenie tempa requestów, backoff pomiędzy próbami oraz kolejkowanie zadań zamiast wysyłania dużego burstu jednocześnie. Jeżeli problem pojawia się przy cronie, imporcie albo synchronizacji WooCommerce, sprawdź również, czy jedna operacja nie uruchamia wielu równoległych requestów do tego samego endpointu.

RFC 6585 wymaga również, aby odpowiedź z kodem 429 nie była przechowywana przez cache. Jeżeli poprawnie działająca infrastruktura nadal zwraca 429 po ustaniu wzmożonego ruchu, przyczyny należy szukać przede wszystkim w nadal aktywnym limicie, czasie blokady lub innej warstwie ochrony, a nie w standardowym cache'owaniu samej odpowiedzi 429.

429 z zewnętrznego API nie oznacza problemu z hostingiem WordPressa

WordPress może działać poprawnie, a plugin otrzymywać 429 od zewnętrznego dostawcy: systemu płatności, ERP, API kurierskiego, platformy marketingowej czy innej integracji.

W takiej sytuacji znaczenie ma limit ustalony przez tę usługę. Może być liczony na użytkownika, token, IP, endpoint albo określone okno czasowe.

Niektóre API zwracają dodatkowe nagłówki opisujące limit, pozostały budżet lub czas resetu. Ich nazwy nie są jednak uniwersalne, dlatego trzeba odnieść je do dokumentacji konkretnej usługi.

Jeżeli to zewnętrzne API zwraca 429, zwiększenie CPU, RAM czy liczby workerów WordPressa nie usuwa źródła problemu.

Nie podnoś limitu bez sprawdzenia, dlaczego został osiągnięty

Rate limiting chroni przed nadużyciami i może ograniczać obciążenie infrastruktury. Zbyt niski próg będzie blokował poprawny ruch, ale zbyt wysoki może osłabić funkcję ochronną reguły.

Przed zmianą ustawień porównaj normalny ruch z tym, który prowadzi do 429. Potrzebne są przede wszystkim:

• liczba requestów w danym okresie,
• endpoint, którego dotyczą,
• cechy używane do prowadzenia licznika,
• źródło ruchu — użytkownik, bot albo własna integracja,
• informacja, czy próg blokuje poprawny przypadek użycia, czy rzeczywiste nadużycie.

W Cloudflare osobny licznik jest prowadzony dla każdej unikalnej kombinacji wartości określonych jako characteristics. Liczniki nie są jednym globalnym licznikiem dla całej sieci: Cloudflare uwzględnia również identyfikator centrum danych cf.colo.id, a liczniki co do zasady nie są współdzielone pomiędzy centrami danych poza centrami przypisanymi do tej samej lokalizacji geograficznej.

Sam kod 429 nie wystarcza więc do dobrania nowego progu. Najpierw trzeba ustalić konkretną regułę i sposób, w jaki jej licznik powstaje.

Bezpieczna procedura diagnozy 429

1. Zapisz dokładny URL, godzinę i operację wywołującą 429.
2. Sprawdź nagłówki oraz treść odpowiedzi.
3. Ustal, czy odpowiedź pochodzi z CDN/WAF, originu, WordPressa czy zewnętrznego API.
4. Sprawdź, według jakiej cechy liczony jest ruch: IP, użytkownik, token, endpoint czy inna kombinacja.
5. Ustal próg, okno czasowe i czas obowiązywania blokady.
6. Jeżeli występuje Retry-After, uwzględnij go w kliencie lub integracji.
7. Sprawdź, czy własny cron, bot albo integracja nie generuje burstu requestów.
8. Porównaj poprawny ruch z ruchem uruchamiającym limit.
9. Dopiero potem zmień próg, zakres reguły albo zachowanie klienta.

Jeżeli zamiast 429 widzisz problemy wynikające z czasu wykonania requestu, przejdź do poradnika o 504 Gateway Timeout. Jeżeli podejrzewasz ogólne przeciążenie hostingu, pomocna będzie Diagnostyka zasobów hostingu.

Najważniejsze wnioski

• 429 oznacza przekroczenie zasad rate limitingu, a nie automatycznie przeciążenie serwera;
• limit może być liczony po IP, użytkowniku, tokenie, endpointcie lub kilku cechach jednocześnie;
• CDN/WAF może odrzucić request przed WordPressem;
• różne endpointy mogą wymagać różnych progów;
• Retry-After może określać czas oczekiwania w sekundach albo konkretną datę HTTP;
• natychmiastowe retry w pętli może pogłębiać problem;
• odpowiedzi 429 nie mogą być przechowywane przez cache zgodnie z RFC 6585;
• 429 z zewnętrznego API nie oznacza problemu zasobów hostingu;
• próg należy zmieniać dopiero po zrozumieniu poprawnego wzorca ruchu i sposobu działania konkretnej reguły.

Źródła

1. RFC 6585 — 429 Too Many Requests — definicja kodu 429, Retry-After, sposób identyfikowania klienta i zakaz przechowywania odpowiedzi 429 przez cache.
2. RFC 9110 — Retry-After — format nagłówka jako liczba sekund albo HTTP-date.
3. Cloudflare — Error 429 — praktyczne znaczenie 429 i rate limiting.
4. Cloudflare — Rate limiting rules — zakres, progi, characteristics i mitigation timeout.
5. Cloudflare — Rate limiting parameters — parametry reguł i kod odpowiedzi.
6. Cloudflare — Request rate calculation — sposób prowadzenia liczników i characteristics.