Обнаружение ботов: как выявляют ботов и краулеров

Сайты выявляют ботов и краулеров, объединяя множество слабых сигналов в один уверенный вердикт: флаги автоматизации вроде navigator.webdriver, утечки headless-браузеров, поведенческие закономерности (например, нечеловеческий тайминг движения мыши), несоответствия в браузерном отпечатке, сетевые сигнатуры TLS/HTTP-2, репутация IP и интерактивные испытания вроде CAPTCHA. Ни одна проверка не является решающей сама по себе, поэтому современные системы детекции оценивают десятки признаков вместе. Это руководство объясняет основные техники, как они работают и где каждая из них даёт сбой.

Раньше у этого вердикта было только два возможных исхода — человек или бот, — но теперь это не так. Значение имеют четыре класса: настоящий человек; бот, который криптографически заявляет о себе и доказывает, каким оператором он управляется; незадекларированная автоматизация, пытающаяся сойти за человека; и ИИ-агент, действующий от имени настоящего залогиненного пользователя. Каждая техника ниже по-прежнему отвечает на часть вопроса «человек ли это», но то, в какой из этих четырёх классов попадёт сессия, всё больше зависит от того, может ли она предъявить доказательство, а не просто ускользнуть от вероятностных догадок детектора.

Почему обнаружение ботов важно

Автоматизированный трафик не является плохим по своей сути. Краулеры поисковых систем, мониторинги аптайма и вспомогательные технологии для людей с ограниченными возможностями — это всё боты, и большинство сайтов хотят их видеть. Проблема в вредоносной автоматизации: переборе украденных учётных данных, скупке товаров, скрапинге контента за платными стенами, рекламном мошенничестве и создании фейковых аккаунтов. Обнаружение ботов существует, чтобы отделить настоящих людей и полезных ботов от абьюзивной автоматизации — в идеале не наказывая реальных пользователей постоянными испытаниями.

Поскольку злоумышленники непрерывно адаптируют свои инструменты, делая их более похожими на человека, детекция превращается в игру в кошки-мышки. Защитники редко полагаются на один приём — они наслаивают клиентские сигналы, поведенческий анализ и серверную сетевую разведку, так что обхода одного слоя оказывается недостаточно.

Флаги автоматизации: navigator.webdriver и его собратья

Самый дешёвый сигнал — это когда браузер сам себя выдаёт. Когда браузером управляет протокол WebDriver (Selenium, классическая автоматизация), стандартизированное свойство navigator.webdriver устанавливается в true. Многие наивные скрипты забывают его замаскировать, поэтому оно остаётся полезным первым фильтром.

Помимо этого единственного свойства, фреймворки автоматизации часто оставляют следы в глобальной области видимости: внедрённые объекты, необычные свойства window или специфичные для драйвера переменные. Скрипты детекции прощупывают эти известные артефакты.

// Минимальная клиентская проверка распространённых сигналов автоматизации.
function detectAutomationSignals() {
  const signals = {
    webdriver: navigator.webdriver === true,
    // Headless Chrome исторически сообщал о нулевом числе плагинов.
    noPlugins: navigator.plugins.length === 0,
    // Настоящие браузеры выставляют массив languages; некоторые боты оставляют его пустым.
    noLanguages: !navigator.languages || navigator.languages.length === 0,
    // Известные артефакты автоматизации, попавшие на страницу.
    cdpArtifacts: '__nightmare' in window || '_phantom' in window,
  };
  signals.suspicious = Object.values(signals).some(Boolean);
  return signals;
}

Эти проверки легко подделать. Опытный оператор может пропатчить navigator.webdriver и внедрить фейковые плагины, поэтому флаги автоматизации лучше рассматривать как один из множества входных сигналов, но никогда — как самостоятельное доказательство.

Эта хрупкость пронизывает каждый клиентский сигнал в этом руководстве, а не только этот: все они выводятся из поведения, которое скрипт рано или поздно сможет подделать. Именно поэтому индустрия стандартизирует слой, который вообще не строится на выводе, — см. раздел про криптографическую идентификацию бота ниже.

Обнаружение headless-браузеров

Headless Chrome и схожие среды выполнения обеспечивают значительную долю скрапинга и автоматизации. Самая очевидная подсказка никуда не делась — headless-режим Chrome по умолчанию пишет HeadlessChrome в строку User-Agent, — но подменить User-Agent можно одной строкой кода, и любая автоматизация, которую вообще имеет смысл ловить, это давно сделала. Поэтому реальная детекция переместилась к более тонким несоответствиям, которые клиенту переписать не так дёшево.

Отсутствующие или несогласованные свойства

Headless-среды часто отрисовывают страницу иначе, чем обычный десктопный браузер. Распространённые признаки включают пустой или необычный список плагинов, отсутствие медиакодеков, API permissions, возвращающий противоречивые состояния (например, сообщающий об уведомлениях одновременно как denied и prompt), а также строки рендерера WebGL, указывающие на программный растеризатор вроде SwiftShader, а не на реальное GPU-оборудование.

Аномалии рендеринга и возможностей

Настоящий браузер на реальном оборудовании выдаёт согласованные результаты в API Canvas, WebGL и аудио. Headless- или виртуализированные конфигурации часто расходятся — например, заявляя топовый GPU в User-Agent, в то время как WebGL сообщает об обобщённом программном рендеринге. Эти противоречия являются сильными сигналами бота. Наши подробные разборы — как Canvas-фингерпринтинг идентифицирует ваше устройство и детали WebGL-фингерпринтинга — объясняют, как эти же сигналы рендеринга работают изнутри.

Для подробного разбора конкретных сигналов, которые утекают из каждого фреймворка, — глобальных переменных CDP, GPU-артефакта SwiftShader и ограничений stealth-плагинов — см. Обнаружение headless-браузеров: как Selenium и Playwright оказываются раскрыты. Ещё глубже, на уровне самого протокола управления: наша статья об обнаружении автоматизации через Chrome DevTools Protocol (CDP) разбирает побочный канал сериализации консоли при Runtime.enable, который раскрывает подключённый клиент Puppeteer или Playwright независимо от каких-либо артефактов конкретного фреймворка.

Поведенческий анализ

Как только сессия прошла статические проверки, защитники наблюдают, как она ведёт себя. Люди шумны и неточны; скрипты чисты и детерминированы. Поведенческий анализ превращает эту разницу в оценку.

• Движение мыши — настоящие курсоры следуют по изогнутым, дрожащим траекториям с переменной скоростью. Боты часто перемещаются по прямым линиям или телепортируются прямо к цели.
• Тайминг и ритм — люди делают паузы, колеблются и варьируют ритм печати. Идеально равные интервалы между нажатиями клавиш или отправка формы быстрее 100 мс выглядят автоматизированными.
• Энтропия взаимодействия — подлинные сессии включают прокрутку, простои и случайные клики. Сессия, которая идёт прямо к цели без единого лишнего движения, выглядит подозрительно.
• Паттерны навигации — краулеры склонны запрашивать страницы в порядке обхода в ширину или по алфавиту и игнорируют контент, отрисованный через JavaScript, который человек естественным образом активировал бы.

Поведенческий анализ силён именно тем, что его сложно убедительно подделать в масштабе, но ему нужно достаточно данных о взаимодействии, чтобы работать, и он может давать ложные срабатывания для пользователей со вспомогательными технологиями или необычными привычками. Отраслевой тренд, который иллюстрирует система Cloudflare «Precursor», представленная в 2026 году, — оценивать эти сигналы непрерывно на протяжении всей сессии, а не в одной контрольной точке; подробнее в нашем материале про поведенческое обнаружение ботов о том, что такое поведенческий сигнал и почему именно корреляция между сигналами позволяет поймать скриптовый ввод.

Та же телеметрия движений мыши и нажатий клавиш встречается и на другой стороне веб-индустрии, только направлена она на людей, а не на ботов: скрипты session replay вроде FullStory и Hotjar фиксируют те же самые сигналы, чтобы воссоздать визуальное воспроизведение сессии реального посетителя для UX-исследований.

Сигналы фингерпринтинга, используемые для выявления ботов

Браузерный фингерпринтинг — подробно рассмотренный в нашем руководстве по браузерному фингерпринтингу — также является инструментом обнаружения ботов. Цель здесь не в том, чтобы отследить одного пользователя по разным сайтам, а в том, чтобы выявить внутреннюю несогласованность и кластеризацию.

Несогласованный отпечаток (Windows-овский User-Agent, сообщающий о наборе шрифтов macOS, или мобильный User-Agent с десктопным разрешением экрана) указывает на спуфинг. Кластеризация — это вторая половина: когда у тысяч «разных» посетителей оказывается один и тот же редкий отпечаток, за ними почти наверняка стоит один и тот же инструмент автоматизации, отштампованный из единого шаблона.

Фингерпринтинг сетевого уровня

Некоторые из самых сильных сигналов вообще не касаются JavaScript. Они живут в том, как клиент согласовывает соединение, что делает их сложными для подделки изнутри песочницы браузера.

Уровень	Техника	Что раскрывает
TLS	Сигнатура JA3 / JA4	Порядок и набор шифронаборов и расширений в рукопожатии; идентифицирует базовую TLS-библиотеку
HTTP/2	Отпечаток фреймов и заголовков	Приоритеты потоков, порядок заголовков и settings-фреймы, различающиеся у настоящих браузеров и HTTP-клиентов
HTTP-заголовки	Порядок и регистр заголовков	Библиотеки автоматизации выдают заголовки в ином порядке или регистре, чем Chrome или Firefox
IP	Репутация и ASN	Диапазоны дата-центров, известные пулы прокси и история злоупотреблений — в отличие от резидентных адресов

Запрос, чей User-Agent утверждает, что это Chrome, но чьё TLS-рукопожатие совпадает с клиентом на Python requests или Go net/http, — это вопиющее несоответствие. Фингерпринтинг в стиле JA3 ловит именно такую автоматизацию, которая полирует слой JavaScript, но игнорирует сетевой уровень.

Репутация IP и ограничение частоты запросов

IP-разведка — старейшая линия обороны и до сих пор одна из самых эффективных. Трафик из ASN дата-центров (облачные провайдеры, хостинговые компании) статистически гораздо вероятнее является автоматизированным, чем трафик резидентных интернет-провайдеров, поэтому к нему применяют дополнительную проверку. Известные выходные узлы прокси и VPN, ретрансляторы Tor и адреса с прошлой историей злоупотреблений — всё это повышает оценку риска.

Ограничение частоты запросов дополняет репутацию: даже чистый резидентный IP становится подозрительным, если он запрашивает сотни страниц в минуту. Сочетание скорости с репутацией позволяет защитникам притормаживать очевидный скрапинг, не затрагивая обычный сёрфинг. Именно поэтому изощрённые злоупотребления переходят в сети резидентных прокси — чтобы позаимствовать репутацию настоящих домашних подключений.

CAPTCHA и системы испытаний

Когда пассивные сигналы неоднозначны, сайты эскалируют до активного испытания. Традиционные графические CAPTCHA просят пользователя напрямую доказать свою человечность, тогда как современные системы (невидимые испытания, головоломки proof-of-work и управляемые страницы испытаний) пытаются проверить легитимность с минимальными неудобствами для пользователя, анализируя те же поведенческие и фингерпринт-сигналы в фоновом режиме.

Испытания — это крайняя мера, а не первая линия, потому что они портят опыт реальных пользователей, а сервисы ручного распознавания капч решают их массово и дёшево. Лучшие системы детекции используют испытания экономно, запуская их только тогда, когда совокупная оценка риска пересекает порог.

Появляющаяся альтернатива вообще обходится без CAPTCHA и оценки отпечатка: криптографическое доказательство. Анонимные удостоверения позволяют клиенту доказать, что он легитимный человек, без того, чтобы сайт строил отслеживаемый профиль ради этого вердикта. Аналог для ботов — доказать, какому оператору принадлежит запрос, вместо того чтобы оценивать, насколько он «похож на человека», — это Web Bot Auth, о котором дальше.

У мобильных приложений уже есть куда более сильный криптографический инструмент, чем всё, что доступно браузеру: аттестация устройства. Вместо оценки десятков слабых сигналов, аппаратный корень доверия подписывает токен, доказывающий подлинность устройства и приложения, — именно поэтому приложения с высоким риском мошенничества полагаются на Play Integrity и App Attest, а не на фингерпринт-скоринг в стиле браузера.

Криптографическая идентификация бота: Web Bot Auth

Всё описанное выше — это вывод: защитник наблюдает сигнал и предполагает, что его породило. Web Bot Auth устроен принципиально иначе — это криптографическое утверждение. Оператор бота владеет закрытым ключом, публикует соответствующий открытый ключ и подписывает каждый HTTP-запрос с помощью HTTP Message Signatures (RFC 9421) — механизма, на котором черновик архитектуры Web Bot Auth в IETF строит формализацию этого подхода. Сайт проверяет подпись по опубликованному ключу и с криптографической достоверностью узнаёт, каким ключом подписан запрос, — а значит, какой оператор за него отвечает.

Это принципиально иной тип сигнала по сравнению со всем остальным в этом руководстве. Флаг navigator.webdriver, TLS-отпечаток или поведенческая оценка — всё это сигналы, которые выводятся и могут быть подделаны: располагающий достаточными ресурсами злоумышленник рано или поздно подделает любой из них. Подпись же утверждается и проверяется: подделать её без закрытого ключа — это задача из области криптографии, а не браузерной автоматизации. Внедрение Web Bot Auth компанией Cloudflare позволяет известным операторам краулеров — сейчас это в основном ИИ-компании и поисковые системы — подписывать свои запросы, чтобы сайты могли явно их пропускать, а не гадать по строке User-Agent и диапазонам IP — то есть именно по тому слою, который остальная часть этого руководства раз за разом показывает самым лёгким для подделки.

Web Bot Auth не заменяет описанные выше техники — сайту они по-прежнему нужны для гораздо большей популяции автоматизации, у которой нет причин заявлять о себе. Что он добавляет — это третий, доказуемый исход: вместо «вероятно человек» или «вероятно бот» запрос теперь может прийти как «доказанно бот именно этого оператора», и именно этого недостаёт, чтобы обращаться с задекларированной и незадекларированной автоматизацией по-разному, а не оценивать их по одним и тем же поддающимся подделке сигналам.

Подпись — лишь один из нескольких способов проверить заявленную личность, а не единственный: см. как сайты проверяют краулера, назвавшегося Googlebot — о том, как прямо-подтверждённый обратный DNS, опубликованные диапазоны IP и реестры операторов по-разному отвечают на один и тот же вопрос, и почему злоумышленнику, подделавшему User-Agent, придётся преодолеть ещё три проверки.

Новая переменная: ИИ-агенты, действующие от имени реальных пользователей

Все техники выше строятся на предположении, что автоматизация нежелательна. ИИ-браузерные агенты ломают это предположение: они управляют настоящим браузером, используя учётные данные настоящего, залогиненного пользователя, чтобы сделать то, о чём этот пользователь явно попросил. Это по-прежнему автоматизированный трафик, но не тот, для остановки которого создавалось обнаружение ботов, — а значит, добавляется четвёртый класс помимо «человека», «верифицированного бота» и «нежелательной автоматизации». Смотрите как сайты учатся отличать ИИ-агентов от ботов и людей о том, что остаётся от описанных выше клиентских сигналов теперь, когда «управляется автоматизацией» больше не означает «нежелательно», а также анонимные удостоверения — эквивалентную идею доказательства человечности с другой, человеческой стороны того же сдвига.

Собираем всё воедино с BrowserInsight

Ни один сигнал не надёжен сам по себе, поэтому реальные системы оценивают их в совокупности. Многие из этих клиентских сигналов вы можете увидеть на самом себе с помощью инструмента обнаружения ботов от BrowserInsight: он показывает состояние вашего navigator.webdriver, headless- и автоматизационные артефакты, согласованность отпечатка и другие индикаторы, чтобы вы могли точно понять, что видит система детекции, когда вы подключаетесь.

Если хотите увидеть подобные отдельные проверки в деле одним взглядом, публичные тестовые страницы вроде bot.sannysoft.com и CreepJS запускают многие из тех же проб и показывают сырые результаты «пройдено/не пройдено» — см. Страницы для проверки на бота: Sannysoft и CreepJS, чтобы узнать, как их читать и почему прохождение статической тестовой страницы — не то же самое, что прохождение реальной, оценивающей системы детекции.

Тот же приём — пассивно наблюдать за таймингом загрузки, событиями ошибок и поведением ответа, вместо того чтобы напрямую читать содержимое — лежит и в основе совсем другой техники, направленной не на ботов, а на людей: см. Определение входа в аккаунт: как сайты узнают, где вы авторизованы о том, как страница может выяснить, в какие ещё сайты вы вошли, ни разу не тронув ваши куки.

Часто задаваемые вопросы

Можно ли доверять navigator.webdriver для обнаружения ботов?

Сам по себе — нет. Он ловит ленивую автоматизацию, которая забывает его замаскировать, но это свойство тривиально переопределить. Рассматривайте его как один слабый сигнал, который обретает смысл только в сочетании с headless-утечками, поведенческими данными и сетевыми отпечатками.

Как сайты обнаруживают headless-браузеры, если User-Agent подделан?

Через поиск несоответствий, которые User-Agent не может скрыть: программный рендеринг WebGL, противоречивые состояния permissions, отсутствующие кодеки и необычный рендеринг Canvas или аудио. Поддельный User-Agent, расходящийся с фактической средой рендеринга, сам по себе является сильной подсказкой.

Обнаружение ботов — это то же самое, что блокировка всех ботов?

Нет. Детекция классифицирует трафик; политика решает, что с ним делать. Сайты обычно пропускают полезных ботов (поисковые краулеры, мониторинги), притормаживают агрессивных, а явно абьюзивную автоматизацию отправляют на проверку или блокируют. Цель — отделить вредоносный трафик от настоящих людей и желанных ботов.

Почему обнаружение ботов называют игрой в кошки-мышки?

Потому что каждая техника детекции приглашает контрмеру. Когда сайты проверяли User-Agent, злоумышленники его подделывали; когда они проверяли navigator.webdriver, злоумышленники его патчили. Защитники отвечают, добавляя сигналы сетевого уровня и поведенческие сигналы, которые сложнее подделать. Ни одна из сторон никогда не «побеждает» окончательно.

Что такое Web Bot Auth и чем он отличается от CAPTCHA?

CAPTCHA просит посетителя доказать что-то о своём поведении или восприятии; Web Bot Auth просит оператора бота подписать каждый запрос закрытым ключом, чтобы сайт мог проверить, какой оператор его отправил. Он не пытается судить, «похож ли запрос на человеческий», — он криптографически идентифицирует того, кто его отправил. Именно поэтому он работает для верифицированного бота, который не может решить CAPTCHA так, как это делает человек, а не заменяет CAPTCHA для анонимного человеческого трафика.

Рекомендуем прочитать

• Страницы для проверки на бота: Sannysoft и CreepJS
• Браузерный фингерпринтинг простыми словами: как защитить приватность
• Обнаружение Canvas-отпечатка: как сайты идентифицируют ваше устройство
• Глубокое погружение в WebGL-фингерпринтинг: идентификация устройства на основе GPU
• Обнаружение автоматизации через Chrome DevTools Protocol (CDP)
• Поведенческое обнаружение ботов: нечеловеческие движения мыши
• Session Replay: как сайты записывают каждое ваше действие
• Аттестация устройств: Play Integrity против App Attest
• Определение входа в аккаунт: как сайты узнают, где вы авторизованы
• Фейковый Googlebot: как сайты проверяют личность краулера