Обмежуйте дорогий шлях, а не краулера

Блокувати ботів легко і зазвичай неправильно. Пошукові системи приводять вам відвідувачів, попередні перегляди посилань приносять кліки, і навіть агресивні AI-краулери часто є трафіком, який ви радше сповільнили б, ніж перекрили. Кращий підхід: знайти, де краулери насправді коштують вам грошей, а це жменька некешованих шляхів з важкими запитами до бази даних, і керувати швидкістю там, на балансувальнику. Ось як це робимо ми.

З’ясуйте, що дороге, перш ніж писати правило

Вартість живе на шляхах, які минають кеш і доходять до PHP та бази даних: карти сайту, що генеруються на льоту, пошук, фасетна навігація, де кожна комбінація фільтрів є свіжим запитом, і все, що має рядок запиту, якого кеш не знає.

Ваш журнал доступу вже каже, які саме. Якщо журнал записує час запиту (наприклад, $request_time nginx як останнє поле), підсумуйте витрачений час за шляхами:

awk '{split($7, p, "?"); t[p[1]] += $NF; n[p[1]]++}
     END {for (u in t) printf "%10.1f s %8d req  %s\n", t[u], n[u], u}' access.log \
  | sort -rn | head -20

Потім подивіться, хто його витрачає, за user agent, на цих шляхах:

awk -F'"' '$2 ~ /sitemap|search|filter=/ {print $6}' access.log \
  | sort | uniq -c | sort -rn | head -20

Два списки, один вечір роботи, і ви точно знаєте, де правило окупиться.

Обмежуйте через stick tables HAProxy

HAProxy вміє рахувати частоту запитів на клієнта і на user agent у пам’яті, на швидкості лінії, і діяти за ними. Мінімальна конфігурація, що захищає лише дорогі шляхи:

backend st_src
    stick-table type ipv6 size 200k expire 10m store http_req_rate(10s)

backend st_ua
    stick-table type string len 128 size 20k expire 10m store http_req_rate(10s)

frontend fe_web
    # bind lines and certificates as usual
    acl expensive path_beg /sitemap /search
    acl expensive url_sub -i filter=
    http-request track-sc0 src table st_src if expensive
    http-request track-sc1 req.fhdr(user-agent) table st_ua if expensive
    http-request deny deny_status 429 hdr Retry-After 60 if expensive { sc_http_req_rate(0) gt 20 }
    http-request deny deny_status 429 hdr Retry-After 60 if expensive { sc_http_req_rate(1) gt 60 }

Тут важать три проєктні рішення. Відстежуються лише дорогі шляхи, тож нічого іншого на сайті не зачеплено. Відповідь є кодом 429 із заголовком Retry-After, який добре виховані краулери розуміють як «сповільнись і повернися», а не як помилку, за яку вас треба покарати. А друга таблиця рахує за user agent, що ловить краулера, розкиданого по багатьох адресах, який прослизнув би під лімітом на адресу. Пороги вище є заглушками: встановіть свої з того, що шлях насправді може віддати без кешу.

Ідентифікуйте краулерів обережно

Зіставляйте user agent нестрого

Краулери змінюють формат рядків user agent, додаючи токени версій, URL чи нові назви продуктів. Правило, яке точно зіставляє весь рядок, перестає працювати в день зміни. Зіставлення підрядка за стабільною частиною (hdr_sub(user-agent) -i <name>) працює далі.

Не заблокуйте пошукову систему випадково

Перевіряйте краулера, перш ніж поводитися з ним особливо. Великі пошукові системи публікують, як саме: зворотний DNS-запит за адресою клієнта має повернути ім’я хоста в їхньому домені, а прямий запит за цим іменем має повернути ту саму адресу.

host <client-address>        # should return a name in the engine's published domain
host <name-returned-above>   # should return the same client address

Справжні краулери тоді отримують обмеження на дорогих шляхах, як і всі інші, і далі вільно обходять решту сайту. Самозванці не отримують жодних поблажок.

Відкидайте форми, які ніколи не бувають легітимними

Деякі шаблони запитів не мають легітимного застосування: URL, перекодовані знову і знову, доки не стануть завдовжки в тисячі символів, неможливі комбінації параметрів, одне й те саме percent-кодування, застосоване тричі. Одне правило на edge відкидає їх, перш ніж вони щось коштуватимуть:

http-request deny deny_status 400 if { url_sub -i %2525 }

Підлаштуйте шаблон під те, що показують ваші журнали. Суть у тому, що балансувальник є найдешевшим місцем у стеку, щоб сказати «ні».

Захистіть PHP від того, що проходить

Жодне правило на edge не ідеальне, тож рівень застосунку потребує власних лімітів. У кожному пулі PHP-FPM тайм-аут завершення не дає одному патологічному запиту тримати worker хвилинами, а стеля пам’яті не дає йому рости без меж:

request_terminate_timeout = 60s
php_admin_value[memory_limit] = 256M
pm.max_requests = 500

Встановлюйте їх разом із правилами на edge, щоб обидва рівні погоджувалися в тому, як виглядає розумний запит. Тим часом Varnish і далі віддає кешовані сторінки, тож читачі та покупці нічого з цього не відчувають.

Як ми це запускаємо

На новинних і e-commerce ресурсах, якими ми керуємо, шляхи карти сайту, пошуку та відфільтрованих списків отримують обмеження швидкості з першого дня, розраховані на те, що кожен сайт може віддати без кешу. Нові правила пишуться з журналів доступу, розгортаються на кожен edge ресурсу і записуються з числами «до» і «після» для клієнта. Коли з’являється новий краулер, цільове правило зазвичай можна поставити на кожен edge протягом хвилин після виявлення шаблону.

Перевірте власний edge

• Які п’ять шляхів коштували найбільше часу PHP і бази даних минулого тижня?
• Хто їх запитував, за user agent?
• Чи діють ваші ліміти лише там, де є вартість, чи на весь сайт?
• Чи відповідаєте ви кодом 429 і Retry-After, чи блокуванням?
• Коли востаннє хтось підтверджував, що правила досі відповідають живому трафіку?

Якщо краулери з’їдають вашу потужність, ми можемо прочитати ваші журнали разом з вами і написати правила. Поговоріть з інженером

Related

• /what-we-do/operations/edge-traffic-control/
• /what-we-do/data-web/high-availability-web-tiers/
• /what-we-do/data-web/performance-audits/