Rate limiting botów bez spowalniania Googlebota

Żeby bezpiecznie ograniczać boty, najpierw zweryfikuj Googlebota i wyłącz go z limitów, potem dławij całą resztę per IP przez nginx limit_req i zwracaj 429 Too Many Requests każdemu klientowi, który przekroczy limit. To cały przepis. Ten poradnik jest dla administratorów, których serwer źródłowy zasypują scrapery i którzy chcą je spowolnić, nie tracąc crawlowania przez wyszukiwarkę. Haczyk? Limit nałożony na wszystkich łapie też prawdziwego Googlebota. A fałszywe crawlery wysyłają user agent Googlebota właśnie po to, żeby prześlizgnąć się przez twoje reguły, więc sam ciąg user agent niczego nie dowodzi.

Dlaczego limit dla wszystkich może zaszkodzić crawlowaniu

Google odczytuje serię odpowiedzi 429, 500 lub 503 jako „zwolnij, proszę”, więc limit, który łapie Googlebota, obniża tempo crawlowania całej nazwy hosta. Nie tylko jednej ścieżki. Według poradnika Google o ograniczaniu crawlowania spowolnienie obejmuje całą nazwę hosta, na przykład subdomain.example.com. Rzadziej crawlowane są więc także adresy URL, które zwracają zupełnie normalną treść, razem z tymi, które sypały błędami. Crawlowanie samo wraca do normy, gdy błędów ubywa. Moim zdaniem 429 wysłane do Googlebota ma być narzędziem, po które sięgasz celowo, a nigdy skutkiem ubocznym reguły na scrapery.

Jak zweryfikować Googlebota po IP, zanim wyłączysz go z limitów?

Żądanie naprawdę pochodzi od Googlebota tylko wtedy, gdy jego IP rozwiązuje się na nazwę hosta Google, a ta nazwa rozwiązuje się z powrotem na to samo IP, albo gdy IP mieści się w opublikowanych przez Google zakresach crawlerów. Weryfikacja DNS w obie strony wygląda tak:

1. Wykonaj odwrotne zapytanie DNS (reverse DNS) dla IP, z którego przyszło żądanie.
2. Sprawdź, czy domena to googlebot.com, google.com lub googleusercontent.com.
3. Wykonaj zwykłe zapytanie DNS (forward DNS) dla otrzymanej nazwy hosta.
4. Porównaj wynik z pierwotnym IP. Brak zgodności oznacza, że to nie Google.

Nazwy hostów mają wzorce w rodzaju crawl-***-***-***-***.googlebot.com lub geo-crawl-***-***-***-***.geo.googlebot.com, jak pokazuje instrukcja Google do weryfikacji crawlerów. Wolisz zakresy niż DNS? Możesz zamiast tego porównywać IP z listami publikowanymi przez Google. Tylko odświeżaj je regularnie (wystarczy zadanie cron), zamiast wpisać je na sztywno i o nich zapomnieć. Jeśli odwrotna część sprawdzenia wydaje ci się trochę mglista, tu wyjaśniamy, jak działają zapytania PTR.

Konfiguracja nginx limit_req dla niezweryfikowanych botów

nginx limit_req ogranicza żądania według klucza, a pusty klucz nigdy nie jest liczony, więc zweryfikowane crawlery omijają limit, a wszyscy pozostali są śledzeni per IP. Ta drobna osobliwość robi tu większość roboty. Minimalna konfiguracja ma cztery elementy: blok geo, który oznacza zweryfikowane zakresy Google, map, który zamienia tę flagę na pustą wartość albo $binary_remote_addr, limit_req_zone na tym kluczu oraz limit_req z burst i nodelay w bloku location.

geo $google_verified {
    default 0;
    include /etc/nginx/google-ranges.conf;  # odświeżane przez zadanie cron
}
map $google_verified $limit_key {
    1 "";
    0 $binary_remote_addr;
}
limit_req_zone $limit_key zone=bots:10m rate=YOUR_RATE;

server {
    limit_req_status 429;
    location / {
        limit_req zone=bots burst=YOUR_BURST nodelay;
    }
}

Ustaw limit_req_status 429, żeby dławieni klienci dostawali 429 Too Many Requests zamiast domyślnego w nginx 503, i wysyłaj razem z nim nagłówek Retry-After. Kosztowne ścieżki, takie jak wyszukiwarka, filtry i feedy, zasługują na osobną, ciaśniejszą strefę. Zasobom statycznym wystarczy luźniejsza. Te ustawienia dotyczą twojego własnego serwera źródłowego lub serwera NGINX. A wartości limitów? Zależą od twojego ruchu i sprzętu, więc dostrajaj je na podstawie logów. Kopiowanie liczb z przypadkowego wpisu na blogu (tego też) to prosta droga do dławienia prawdziwych użytkowników.

Wyłapywanie fałszywych Googlebotów i agresywnych scraperów

Wszystko, co w user agencie podaje się za Googlebota, ale nie przechodzi weryfikacji DNS ani zakresów IP, trafia do najostrzejszej strefy limitów albo jest od razu blokowane. Bez drugiej szansy. W logu dostępu zdradzają to takie sygnały:

• user agent Googlebota z IP spoza Google,
• duża liczba żądań z jednego IP lub jednej podsieci,
• crawlowanie adresów z parametrami, takich jak warianty sortowania, filtrów i sesji,
• ignorowanie robots.txt, którego prawdziwe crawlery Google zawsze przestrzegają przy automatycznym crawlowaniu.

Trzymaj wyniki reverse DNS w cache, inaczej weryfikacja dokłada zapytanie do każdego pojedynczego żądania. Słabo. Loguj też dławione żądania do osobnego pliku, żeby łatwo wyłapać fałszywe alarmy. Do przeglądania tego pliku świetnie nadaje się to samo podejście, którego używamy do weryfikacji Googlebota w logach.

Co się zmienia, gdy ruch przechodzi przez reverse proxy z rotacją IP?

Za reverse proxy serwer źródłowy widzi adres proxy zamiast adresu crawlera, więc weryfikacja po IP i limity per IP na serwerze źródłowym przestają działać, chyba że prawdziwe IP klienta jest przekazywane dalej. Rotujące adresy proxy jeszcze to komplikują. Jeden odwiedzający może pojawić się pod kilkoma adresami, a wielu odwiedzających może dzielić jeden. Liczniki per IP się rozjeżdżają, a sprawdzenia reverse DNS trafiają w niewłaściwy host. Rozwiązaniem jest nagłówek z przekazanym IP klienta plus lista zaufanych adresów proxy, a dokładnie tym zajmuje się moduł nginx real_ip. Tylko że weryfikacja jest dokładnie tak wiarygodna jak ten nagłówek. Jeśli twój ruch idzie przez reverse proxy z rotacją IP, sprawdź, który adres faktycznie trafia do twoich stref limitów.

Kiedy naprawdę trzeba zmniejszyć tempo crawlowania Googlebota

Jeśli to sam Googlebot przeciąża serwer, możesz przez krótki czas zwracać jego żądaniom 500, 503 lub 429, a Google będzie crawlować mniej, dopóki błędy nie ustaną. Kluczowe słowo to „krótki”. Dokumentacja Google o tempie crawlowania opisuje to jako doraźny środek na krótki okres, na przykład parę godzin albo 1-2 dni. Nie możesz serwować błędów? Wtedy możesz złożyć specjalne zgłoszenie o nietypowo wysokim tempie crawlowania. Nie próbuj w ten sposób prosić o wyższe tempo, bo nie do tego służy, a jego rozpatrzenie i tak może potrwać kilka dni. Tak czy inaczej, to celowe i ograniczone w czasie spowolnienie. Trzymaj je osobno od opisanych wyżej limitów na scrapery.

Podsumowanie

Kolejność ma tu znaczenie: zweryfikuj Googlebota, wyłącz go z limitów, klientów, którzy nie przeszli weryfikacji, dławij przez limit_req i 429, a potem pilnuj logów pod kątem pomyłek. Za proxy z rotującymi adresami logika per IP na serwerze źródłowym jest dokładnie tak dobra jak przekazane IP klienta. Jeśli chcesz wejść głębiej, więcej znajdziesz w naszych wpisach o crawlowaniu i indeksowaniu. Ograniczaj boty w ten sposób, a scrapery zwolnią do żółwiego tempa, podczas gdy crawlowanie przez wyszukiwarkę zachowa normalny rytm.

FAQ