Возвращение 402 Payment Required: что коды статуса HTTP говорят о ботовом трафике

Большинство решений веб-аналитики принимаются на стороне клиента, после того как страница загрузилась и отработал JavaScript. Эта модель молчаливо предполагает, что каждый запрос, дошедший до вашего сервера, стоит того, чтобы его посчитали. Это не так. Значительная доля сырого трафика вообще ничего не рендерит, никогда не принадлежит человеку и никогда не должна попадать в ваши дашборды. Самый ясный и самый ранний сигнал для его фильтрации — то, что вы уже генерируете на каждом запросе: код статуса HTTP.

Коды статуса — полноценный сигнал аналитики

Спецификация семантики HTTP (RFC 9110) определяет коды статуса как трёхзначное целое число, описывающее результат запроса, сгруппированное в пять классов: 1xx информационные, 2xx успешные, 3xx перенаправления, 4xx клиентские ошибки и 5xx серверные ошибки. Поскольку Monoid работает на edge-инфраструктуре Cloudflare, мы видим код статуса, который возвращает источник (или сам edge), ещё до того, как выполнится какой-либо клиентский скрипт. Этот порядок важен. Просмотр страницы, зафиксированный браузерным beacon-ом, может существовать только если документ действительно был отдан с кодом 2xx и разобран. Но поток запросов включает гораздо больше, чем успешные документы.

Подумайте, что типичный источник возвращает за день: успешные HTML-документы, ответы 304 Not Modified на условные запросы, редиректы 301/308 из-за канонизации, 404 от сканеров-зондов и всплески 5xx во время инцидентов. Учитывать только успешно отрендеренные документы, игнорируя остальное, значит выбрасывать контекст, объясняющий аномалии на вашей кривой трафика.

Где боты прячутся в распределении статусов

Автоматизированные клиенты ведут себя иначе, чем браузеры, и коды статуса дёшево обнажают эту разницу. Сканеры уязвимостей создают плотные кластеры ответов 404 и 403, зондируя админ-панели и известные пути CMS. Агрессивные краулеры игнорируют 429 Too Many Requests — определённый в RFC 6585 как ответ для ограничения частоты запросов — и продолжают долбить, создавая сигнатуру, которую не создаёт ни одна человеческая сессия. Наивные скрейперы часто следуют по цепочкам редиректов, которые реальный браузер сократил бы через bfcache или историю.

Код 402 Payment Required здесь показателен. RFC 9110 прямо отмечает, что он зарезервирован для будущего использования и не имеет стандартизированной семантики, однако недавно получил новое внимание в контексте тарифицируемого доступа к API и агентам. Если ваш источник начинает выдавать 402, этот трафик почти наверняка программный, а не человек, просматривающий страницы. Пайплайн, осведомлённый о статусах, может пометить его соответствующим образом, вместо того чтобы молча раздувать метрику.

Почему аналитика только на стороне клиента ошибается здесь

Инструмент, работающий исключительно на JavaScript, буквально не может наблюдать большую часть этого. Если запрос возвращает 403, ни один скрипт аналитики не запускается, поэтому событие невидимо — но нагрузка на вашу инфраструктуру реальна, а намерение за ней (разведка, credential stuffing, скрейпинг) зачастую как раз то, что вы и хотите узнать. И наоборот, инструменты, считающие строки серверных логов без разбивки по статусу, завышают показатели, трактуя каждый переход 301 и каждый зонд 404 как «хит».

Полезная золотая середина — классификация статуса на уровне edge, питающая privacy-first модель подсчёта:

• 2xx text/html с реальной навигацией — кандидат на просмотр страницы.
• 3xx следует относить к пункту назначения, а не считать дважды.
• 4xx — это диагностика, а не аудитория, показывайте отдельно.
• 5xx относится к панели надёжности, коррелируя с любым падением успешных просмотров.

Как делать это, никого не отслеживая

Ничто из этого не требует идентификации посетителя. Код статуса, метод, класс ответа и грубый тайминг — это свойства обмена запрос-ответ, а не человека. Monoid никогда не устанавливает cookie, никогда не читает localStorage и никогда не занимается фингерпринтингом устройств. Нам не нужен стабильный идентификатор, чтобы понять, что всплеск 429 в 03:00 UTC — результат автоматизации, а не аудитории: распределение статусов говорит об этом само по себе. Это минимизация данных, работающая в нашу пользу: наименее личный сигнал оказывается и одним из самых честных для оценки качества трафика.

Есть и польза для комплаенса. Фильтрация нечеловеческого трафика на edge означает, что в хранилище аналитики вообще попадает меньше ложных событий, а записанные данные плотнее соответствуют заявленной цели. Согласно принципам ограничения хранения и ограничения цели GDPR (статьи 5(1)(c) и 5(1)(e)), не собирать мусор строго лучше, чем собрать его, а затем выбросить.

Практические выводы

Если вы создаёте или оцениваете аналитику, задайте три вопроса. Видит ли она код статуса или только отрендеренные документы? Отделяет ли она сигналы надёжности (5xx) от сигналов аудитории (2xx)? И достигает ли она фильтрации ботов без идентификатора? Пайплайн, отвечающий «да» на все три, даёт вам одновременно более чистые цифры и меньшую поверхность приватности — что, на этот раз, оказывается одним и тем же решением.

Источники

• RFC 9110: HTTP Semantics (Status Codes)
• RFC 6585: Additional HTTP Status Codes (429, 431)
• MDN: HTTP response status codes
• GDPR Article 5: Principles relating to processing of personal data