Jak ograniczyć liczbę zapytań na IP w PrestaShop, nie blokując Google

Poniedziałek rano. Sklep padł w niedzielę dwa razy, log dostępu pokazuje trzy adresy, z których każdy poprosił o osiemdziesiąt tysięcy stron, a Ty blokujesz je na serwerze. Spokój. We wtorek jest czterdzieści nowych adresów, które robią dokładnie to samo.

Blokowanie po adresie to pierwsza reakcja każdego i ta, która najkrócej działa. Nie dlatego, że to zły pomysł, tylko dlatego, że problemem nie jest to, kto pyta, tylko ile pyta. A to się mierzy, a nie zgaduje.

Dlaczego blokowanie adresów nigdy się nie kończy?

Robot, który przechodzi przez Twój katalog, nie przychodzi z jednego adresu: przychodzi z sieci, albo kilku, i je zmienia. Kiedy odetniesz jeden, kontynuuje z następnego bez zatrzymania. Tak samo z nazwami: przedstawiają się jako zwykła przeglądarka, co tydzień zmieniają tożsamość, a co miesiąc pojawiają się trzy nowe. Lista blokad rośnie, a obciążenie nie spada.

Czego nie da się ukryć, to tempa. Człowiek, który robi zakupy, otwiera kategorię, zaznacza dwa filtry, przechodzi na jedną stronę dalej i wchodzi w kartę produktu: trzy czy cztery kosztowne wyszukiwania w ciągu całej wizyty. Robot robi trzy czy cztery na sekundę, z każdego adresu, którego używa. Policzenie, ile kosztownych wyszukiwań robi każde źródło w ciągu minuty, odróżnia jednych od drugich bez potrzeby znania ich nazw.

Czym jest limit zapytań na IP i dlaczego także na sieć?

Ograniczenie na IP to ustawienie sufitu: ile zapytań sklep przyjmuje z tego samego adresu w danym oknie czasowym — zwykle sześćdziesięciu sekund. Poniżej sufitu wszystko przechodzi; powyżej zapytanie dostaje „wróć za chwilę”, którego obsłużenie nic nie kosztuje.

Z samym tym robot, który rozkłada pracę na dwieście adresów z tej samej sieci, na każdym z nich zostaje pod sufitem. Dlatego drugi limit jest na sieć: adresy, które mają wspólne trzy pierwsze bloki (technik nazwie to /24), liczą się razem. Tak może wyglądać operator komórkowy, więc ten sufit jest wyżej niż limit na adres, ale zmienianie adresów przestaje być darmowe. A trzeci hamulec, dla całego sklepu, działa jak limit awaryjny: gdy suma wyszukiwań na minutę przekracza to, co Twój serwer spokojnie obsługuje, przechodzą tylko odwiedzający, którzy już udowodnili, że są ludźmi.

Gdzie ustawić limit: na serwerze czy w sklepie?

Są trzy miejsca, w których można liczyć, i nie widzą one tego samego.

• W CDN (na przykład reguły ograniczania liczby zapytań w Cloudflare). Liczy na adres i na wzorzec URL. Nie wie, które zapytanie jest drogie, a które jest obrazkiem, nie wie, czy odwiedzający jest zalogowany, i traktuje Googlebota jak każdego innego. Na szczyt jednego popołudnia działa; żeby tak żyć, albo za mocno hamujesz klientów, albo za słabo boty.
• Na serwerze WWW (moduły ograniczania zapytań w Apache czy nginx albo fail2ban czytający log). Liczy wszystko, co wchodzi, łącznie z CSS i zdjęciami, więc sufit musi być tak wysoki, że prawie nie hamuje. A żeby go ruszyć, musisz umieć administrować serwerem, czego na hostingu współdzielonym nawet nie wolno.
• W samym sklepie, zanim PrestaShop zacznie szukać. To jedyne miejsce, które wie, co jest drogie: wyszukiwanie z filtrami, pole wyszukiwania, strona listy, zmiana sortowania. Tylko to liczy się do limitu. Wie, czy odwiedzający jest zalogowany — i wtedy go nie ogranicza — i może sprawdzić, czy ten, kto podaje się za Googlebota, naprawdę nim jest. Tam umieszcza go Ochrona przed botami dla PrestaShop i dlatego limit może być niski, nie przeszkadzając nikomu, kto kupuje.

Jak wpuścić Google?

To obawa, która powstrzymuje większość ludzi, i słusznie: źle ustawiony limit sam usunie Cię z Google. Odpowiedzią nie jest lista nazw, bo każdy może przedstawić się jako Googlebot, tylko zapytanie sieci. Każde zapytanie, które twierdzi, że pochodzi od Google, jest sprawdzane odwrotnym zapytaniem DNS, a jeśli adres nie należy do Google, to zapytanie nie jest od Google, cokolwiek by mówiło.

Zweryfikowane wyszukiwarki wchodzą z własnym limitem, oddzielnym od limitu odwiedzających, i dostają strony filtrów oznaczone jako nieindeksowane. To dokładnie to, co Google zaleca dla nawigacji fasetowej: kombinacje filtrów nie powinny zamieniać się w tysiące powtórzonych stron. Kiedy przestajesz zużywać na nie jego czas, zaczyna lepiej odwiedzać te, które są dla Ciebie ważne.

Co się dzieje, gdy ktoś przekroczy limit?

Skrypt dostaje „za dużo zapytań” z czasem, po którym może wrócić, a Twoją bazę danych nic to nie kosztuje. Ale limit na adres ma jeden niewygodny przypadek: biuro z trzydziestoma osobami za jednym łączem albo klient, który bardzo szybko filtruje. Takich nie należy wyrzucać: trzeba sprawdzić, czy to ludzie.

Działa ta weryfikacja, której nikt nie widzi. Proof of work — małe obliczenie, które przeglądarka sama rozwiązuje w milisekundy, bez łamigłówek i pól do zaznaczania — i przepustka na godzinę. Przepustka nie zwalnia całkowicie, bo rozwiązanie tego zadania jest tanie także dla skryptu: kto ją ma, nadal ma sufit na adres, tylko dziesięć razy wyższy.

Od jakich liczb zacząć?

Przy oknie sześćdziesięciu sekund trzydzieści kosztownych wyszukiwań na adres, dziewięćdziesiąt na sieć i sześćset dla całego sklepu obsługują ogromną większość sklepów, a żaden klient nigdy tego nie zauważy. Szybki klient robi dwadzieścia na minutę; trzydzieści to już ktoś, kto nie patrzy, co filtruje.

Jeśli jeszcze temu nie ufasz, jest tryb obserwacji: limit patrzy i zapisuje, co by zatrzymał, ale wszystko przepuszcza. Tydzień w tym trybie, a panel powie Ci, ile zapytań zostałoby przed drzwiami i skąd przychodziły, i decydujesz na podstawie danych.

Jak sprawdzić, czy limit jest dobrze ustawiony?

Limit, którego się nie mierzy, to limit, który pewnego dnia przeszkodzi klientowi, a Ty się o tym nie dowiesz. Co tydzień warto patrzeć na trzy rzeczy: ile kosztownych wyszukiwań obsłużono, a ile zatrzymano, które źródła zatrzymywano najczęściej i dlaczego, i czy któreś z nich jest Twoje — Twój monitoring dostępności, plik dla porównywarki cen, klient, który się skarżył. Takie źródło dostaje jedno kliknięcie zaufania i już nigdy nie jest liczone.

A na wątpliwości jest sprawdzarka: wklejasz adres i przeglądarkę z logu oraz stronę, o którą prosiły, a ona mówi Ci dokładnie, co zrobiłaby teraz z tym zapytaniem i dlaczego. To sposób na ruszenie limitu bez ruszania go na ślepo.

Wszystko to — trzy sufity, odbicie przez cookie, Google weryfikowany przez DNS, niewidoczna weryfikacja, tryb obserwacji i panel ze sprawdzarką — robi Ochrona przed botami dla PrestaShop od minuty instalacji, na PrestaShop od 1.7.6 do 9 i za Cloudflare. A jeśli najpierw chcesz wiedzieć, czy to Twój problem, wyślij nam log dostępu ze złego dnia przez formularz kontaktowy: za darmo powiemy Ci, ile z tych zapytań to ludzie, a ile szum.