Problem z blokowaniem botów – serwer nadal przeciążony

Dlaczego serwer nadal jest przeciążony mimo blokowania botów?

Blokada może działać, a strona WordPress nadal odpowiadać powoli lub zwracać błędy 503. Być może zatrzymuje tylko część ruchu, działa dopiero po uruchomieniu PHP albo problem wcale nie leży w botach. Przyczyną bywają też wolne zapytania do bazy, zadania cykliczne lub brak pamięci.

Zanim dodasz kolejną regułę, porównaj ruch i obciążenie w tym samym czasie. Ustal, które adresy i procesy zużywają zasoby oraz na jakim etapie żądania są odrzucane.

Identyfikacja źródła ruchu – analiza logów serwera

Znajdź przedział, w którym wystąpiło przeciążenie, i sprawdź log dostępu oraz log błędów właściwej domeny. Na hostingu ich lokalizację podaje panel lub administrator; na VPS zależy ona od konfiguracji serwera. Jeśli używasz CDN, zestaw zdarzenia zapory z logami serwera źródłowego.

• Porównaj liczbę żądań, kody odpowiedzi i najczęściej wywoływane ścieżki, szczególnie dynamiczne adresy, takie jak wp-login.php, xmlrpc.php czy wp-admin/admin-ajax.php.
• Sprawdź częstotliwość żądań, adresy źródłowe i User-Agent, ale nie uznawaj żadnej z tych cech za samodzielny dowód ataku. Powtarzane wywołania mogą pochodzić również z integracji lub monitoringu.
• Porównaj godziny skoku ruchu ze zużyciem CPU, pamięci, dysku i pracą PHP oraz bazy. Jeśli nie pokrywają się w czasie, szukaj także poza ruchem HTTP.

GoAccess może ułatwić analizę logów, a htop pokazuje procesy i zużycie zasobów. Google Analytics nie zastępuje logów: nie każde żądanie uruchamia kod analityczny.

Rodzaje botów – które warto przepuszczać?

Roboty wyszukiwarek i narzędzia tworzące podglądy linków mogą być potrzebne stronie. Z drugiej strony automatyczne próby logowania, spam w formularzach czy intensywne pobieranie stron mogą wymagać ograniczenia. Samo automatyczne pobieranie danych nie przesądza jednak o złośliwości ruchu.

Nagłówek User-Agent można podrobić. Przed wyjątkiem dla Googlebota zweryfikuj adres zgodnie z dokumentacją Google. Plik robots.txt jest wskazówką dla współpracujących robotów, a nie blokadą dostępu.

Sprawdzenie skuteczności blokad – czy filtry działają?

1. Zapisz stan przed zmianą: liczbę żądań do problematycznej ścieżki, błędy 5xx, czas odpowiedzi i obciążenie w wybranym okresie.
2. Sprawdź w zdarzeniach CDN lub WAF, która reguła zadziałała i jaki był jej wynik. Następnie porównaj liczbę żądań docierających do serwera i PHP w porównywalnym okresie.
3. Po zmianie sprawdź stronę, logowanie i używane integracje. Zwróć uwagę na nieoczekiwane odpowiedzi 403 i 429 oraz zgłoszenia użytkowników.

Duża liczba blokad sama w sobie nie oznacza mniejszego obciążenia. Wtyczka WordPress może odrzucić żądanie dopiero po uruchomieniu PHP; blokada na CDN lub serwerze WWW może zatrzymać je wcześniej. Testy aktywne wykonuj wyłącznie w uzgodnionym środowisku i zakresie.

Problemy z konfiguracją firewalla i rate limiting

Zacznij od możliwie wąskiej reguły dla zaobserwowanej ścieżki i wzorca ruchu, zamiast blokować całe kraje lub szerokie zakresy IP. Limity ustaw na podstawie rzeczywistego ruchu: z jednego adresu może korzystać wiele osób, a wywołania API mogą pochodzić z systemów partnerów.

Sprawdź kolejność i sposób oceny reguł w używanym produkcie. Jeśli dostępny jest tryb obserwacji, użyj go przed blokadą. Zapisz poprzednie ustawienia i sposób cofnięcia zmiany, a po wdrożeniu kontroluj fałszywe blokady. Nie stosuj zasady „blokuj wszystko” do publicznej strony bez zaplanowanych wyjątków i testów.

Boty maskowane jako ludzie

Bot może używać przeglądarki, zmieniać adresy i rozkładać żądania w czasie. Dlatego oceniaj łącznie ścieżki, tempo i skutki ruchu, zamiast ufać jednej cesze. Weryfikacja JavaScript lub CAPTCHA może pomóc przy wybranych formularzach, ale może też utrudnić dostęp ludziom i zepsuć integracje. Stosuj ją punktowo i sprawdź dostępność.

Problemy z CDN – czy ruch omija ochronę?

Jeśli domena przechodzi przez CDN, porównaj jego zdarzenia z logami serwera. Rozbieżność wymaga sprawdzenia konfiguracji, ale nie musi sama oznaczać obejścia: logi mogą obejmować różne okresy lub rodzaje żądań. Sprawdź również odpowiednie subdomeny i rekordy DNS.

Publiczny adres serwera źródłowego może pozwalać na pominięcie CDN. Ograniczenie dostępu do originu wymaga planu dla usług, monitoringu i wyjątków oraz aktualnej listy adresów dostawcy. Na współdzielonym serwerze reguła sieciowa może dotknąć inne domeny lub usługi: przed zmianą ustal zakres i sposób wycofania z administratorem. Nagłówkom z adresem klienta ufaj tylko od skonfigurowanych, zaufanych proxy.

Optymalizacja serwera i WordPressa

• Cache: sprawdź, czy publiczne strony i pliki statyczne są skutecznie buforowane. Koszyk, płatności, panel klienta i inne odpowiedzi zależne od sesji nie mogą być udostępniane z publicznego cache.
• PHP i baza: sprawdź zajętość procesów PHP-FPM oraz wolne zapytania. Nie zwiększaj limitu procesów w ciemno: każdy zużywa pamięć. Indeksy i zmiany konfiguracji bazy dobieraj dopiero po analizie konkretnego problemu.
• Zadania i wtyczki: sprawdź, czy obciążenie nie pokrywa się z zadaniami cyklicznymi, kopiami zapasowymi lub pracą konkretnej wtyczki. Zmiany testuj pojedynczo.

Nie zakładaj, że migracja z Apache do Nginx albo dodanie zasobów rozwiąże problem. Najpierw znajdź wąskie gardło; dodatkowa moc może pomóc, ale nie usuwa przyczyny nadmiarowych żądań.

Monitorowanie w czasie rzeczywistym

Ustaw alerty na utrzymujące się wysokie obciążenie, błędy 5xx i wydłużony czas odpowiedzi. Obserwuj również liczbę żądań do problematycznych ścieżek, 403/429 oraz aktywność PHP i bazy. Progi dopasuj do normalnego ruchu strony, a nie do uniwersalnej liczby.

Logi mogą zawierać adresy IP i dane w adresach URL. Ogranicz dostęp do nich, ustal czas przechowywania i nie publikuj ich bez sprawdzenia zawartości.

Podsumowanie – co zrobić najpierw?

Najpierw ustal, co obciąża serwer i czy problem pokrywa się z ruchem botów. Następnie sprawdź, gdzie działają obecne blokady, wprowadź jedną precyzyjną zmianę i porównaj wyniki. Przy każdej regule sprawdź dostęp użytkowników, robotów wyszukiwarek oraz integracji.

Najczęstsze pytania

Jak ograniczyć częstotliwość zapytań botów?

Zacznij od limitu dla konkretnej ścieżki, która powoduje obciążenie. Jeśli to możliwe, zastosuj go na CDN lub serwerze WWW, zanim żądanie trafi do PHP. Dobierz próg na podstawie logów i sprawdź, czy nie ogranicza użytkowników oraz integracji.

Czy blokada IP wystarczy?

Niekoniecznie. Ruch może pochodzić z wielu zmiennych adresów, a jeden adres może być współdzielony przez wielu użytkowników. Łącz analizę adresów ze ścieżkami, częstotliwością żądań i działaniem reguł.

Jak odróżnić Googlebota od podszywającego się pod niego bota?

Sam nagłówek User-Agent nie potwierdza tożsamości. Zweryfikuj adres IP według dokumentacji Google, używając odwrotnego DNS i ponownego sprawdzenia DNS albo opublikowanych zakresów adresów Googlebota.

Czy robots.txt blokuje niechciane boty?

Nie. Plik przekazuje wskazówki współpracującym robotom, ale nie jest mechanizmem kontroli dostępu. Bot może go zignorować.

Czy blokowanie botów może zaszkodzić SEO?

Tak, jeśli reguła zablokuje prawidłowe roboty wyszukiwarek lub ważne zasoby. Po zmianie sprawdź zdarzenia zapory i dostęp do istotnych adresów w Google Search Console.

Czy Cloudflare zawsze zatrzymuje ruch przed serwerem?

Nie. Ochrona dotyczy ruchu przechodzącego przez usługę i zależy od konfiguracji. Jeśli serwer źródłowy jest publicznie dostępny, żądania mogą do niego trafić z pominięciem CDN.