TrafficVeil
Боты 8 мин21 августа 2026 г.

Chrome Prefetch Proxy в логах: не бот, а фича браузера

В логах это выглядит как ещё один автоматический клиент, но на деле — встроенный механизм Chrome, который предзагружает страницы из поисковой выдачи Google ещё до клика пользователя, пряча его IP через собственный прокси. Разбираемся, почему тут бессилен обычный robots.txt, чем его заменяет файл traffic-advice и когда предзагрузку действительно стоит ограничивать.

TV
TrafficVeil Team
Эксперты по защите веб-трафика
Содержание статьи
  1. 1. Что такое Chrome Prefetch Proxy на самом деле
  2. 2. Зачем Chrome Prefetch Proxy приходит на сайт
  3. 3. Нагрузка и особенности, которые стоит учитывать
  4. 4. Как найти Chrome Prefetch Proxy в логах
  5. 5. Как на самом деле управлять доступом: traffic-advice, а не robots.txt
  6. 6. Жёсткая блокировка через сервер и TrafficVeil (если действительно нужна)
  7. 7. Что делать: короткий алгоритм
  8. 8. С кем не путать Chrome Prefetch Proxy
  9. 9. Стратегия allow/deny для Chrome Prefetch Proxy
DDoS L7

DDoS атака что это простыми словами и как защитить сайт

Разобрали виды атак, признаки DDoS, последствия, уровни защиты, L7 DDoS и схему подключения TrafficVeil через DNS/reverse proxy.

Читать про DDoS

Энциклопедия ботов TrafficVeil

618 ботов с описаниями, паттернами User-Agent и фильтром по категориям — открытый справочник для аудита логов и настройки защиты.

Открыть справочник

Chrome Privacy Preserving Prefetch Proxy в логах — не бот в привычном смысле и не сторонний сервис, а часть самого браузера Chrome. Реальный человек листает поисковую выдачу Google или участвующий в программе сайт, а Chrome заранее подгружает страницы, которые он может открыть, скрывая при этом IP пользователя от вашего сервера через собственный proxy-механизм Google. И управляется этот трафик не через robots.txt, а через отдельный файл, о котором часто просто не знают.

1. Что такое Chrome Prefetch Proxy на самом деле

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

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

Параметр Значение
Название Chrome Privacy Preserving Prefetch Proxy (Private Prefetch Proxy)
Природа Встроенная функция браузера Chrome, а не отдельный краулер или сервис
User-Agent / паттерн содержит Chrome Privacy Preserving Prefetch Proxy; заголовок намеренно урезан и несёт меньше данных, чем обычный UA Chrome — это часть той же приватности, что скрывает IP
Оператор Google; связанный диапазон — 66.102.6.0/24 (обратные DNS вида google-proxy-*.google.com, домен googlezip.net)
Роль Предзагружает страницу до клика пользователя по ссылке в поиске Google или на партнёрском сайте, чтобы ускорить переход
Официальная документация developer.chrome.com — раздел Privacy & Security, "Private prefetch proxy in Chrome"
Управление доступом Не через robots.txt, а через файл /.well-known/traffic-advice
Влияние на SEO Нет — это не поисковый краулер, ранжирование не затрагивает
Пометка TrafficVeil Легитимный / Прочие краулеры и сервисы

2. Зачем Chrome Prefetch Proxy приходит на сайт

Срабатывание привязано к реальному действию человека — не к автономному расписанию сканирования:

  • пользователь открыл страницу результатов Google, и в выдаче показалась ваша ссылка — Chrome может заранее подгрузить её содержимое на случай клика;
  • то же самое может произойти на других участвующих в программе площадках, а не только в поиске Google;
  • подгружаются в первую очередь ресурсы для отображения страницы — HTML, критичные для отрисовки ассеты; данные из кук и локального состояния пользователя намеренно не используются, чтобы не раскрыть личность посетителя до фактического перехода.

Типичный случай: в логах регулярно всплывают запросы к /.well-known/traffic-advice, за которыми иногда следует, а иногда не следует обращение к самой странице. Если пользователь так и не кликнул по превью в выдаче — предзагруженная страница просто не будет использована, а сервер уже потратил ресурсы на её отдачу. Это ожидаемое поведение механизма, а не сбой и не признак вредоносной активности.

3. Нагрузка и особенности, которые стоит учитывать

Главный практический риск — не мусорный трафик от автоматизации, а расход ресурсов на предзагрузки, которыми пользователь в итоге не воспользуется: часть таких запросов не превращается в реальный визит. На высоконагруженных сайтах с большим потоком из поиска Google это может быть заметная доля CPU/bandwidth origin-сервера.

Второй нюанс — искажение аналитики по User-Agent: поскольку заголовок при префетче специально урезан и не совпадает с обычной строкой браузера пользователя, автоматические системы аналитики могут неверно классифицировать такие хиты как ботовые, хотя за ними стоит реальный интерес живого человека к вашей странице.

Третий нюанс — если на сайте есть контент-фильтрация на уровне сети (родительский контроль, корпоративный прокси), она может не сработать при переходе по предзагруженной ссылке, поскольку обычный DNS-запрос в момент клика не происходит. Google предусмотрел для этого отдельный сигнальный механизм: если DNS-проверка для dns-tunnel-check.googlezip.net показывает, что администратор сети нуждается в видимости таких переходов, Chrome при клике всё равно выполнит обычный DNS-запрос перед использованием кэша.

4. Как найти Chrome Prefetch Proxy в логах

Ищите не общий токен «bot», а конкретную строку UA и обращения к служебному пути, который использует именно этот механизм.

# Базовый поиск по UA
grep -i "chrome privacy preserving prefetch proxy" /var/log/nginx/access.log

# Обращения к файлу traffic-advice — маркер именно этого механизма
grep -i "traffic-advice" /var/log/nginx/access.log

# Топ URL, которые предзагружает Chrome
grep -i "chrome privacy preserving prefetch proxy" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head

# Топ IP — сверяйте с диапазоном 66.102.6.0/24
grep -i "chrome privacy preserving prefetch proxy" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

# Суточная активность — обычно коррелирует с пиками органического трафика из поиска
grep -i "chrome privacy preserving prefetch proxy" /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f1 | sort | uniq -c

Верификация. Строку UA подделать может любой скрипт, но у этого механизма есть более надёжный признак — реальный трафик Google идёт с известного диапазона и имеет обратный DNS вида google-proxy-*.google.com:

IP="66.102.6.X"
whois -h whois.cymru.com " -v $IP"
dig +short -x "$IP"

5. Как на самом деле управлять доступом: traffic-advice, а не robots.txt

Ключевая ошибка, которую стоит исключить сразу: правило Disallow в robots.txt на этот UA технически ничего не значит для данного механизма — Google описал для него отдельный, аналогичный по идее, но иначе устроенный файл /.well-known/traffic-advice с MIME-типом application/trafficadvice+json.

# Разрешить весь префетч-трафик (100%)
[{"user_agent": "prefetch-proxy", "fraction": 1.0}]

# Постепенный ролл-аут — пропускать только часть запросов
[{"user_agent": "prefetch-proxy", "fraction": 0.3}]

# Полностью запретить предзагрузку
[{"user_agent": "prefetch-proxy", "disallow": true}]

Файл запрашивает не браузер конечного пользователя, а сам прокси Google, и кэширует ответ по обычным правилам HTTP-кэширования. Если файла нет — сервер будет постоянно отдавать 404 на этот путь, что просто означает нереализованный контроль, а не блокировку.

Пример конфигурации для Nginx, отдающего файл с правильным MIME-типом:

location = /.well-known/traffic-advice {
    default_type "application/trafficadvice+json";
    return 200 '[{"user_agent":"prefetch-proxy","fraction":1.0}]';
}

6. Жёсткая блокировка через сервер и TrafficVeil (если действительно нужна)

Traffic-advice — вежливый, документированный способ. Если требуется гарантированно закрыть доступ на уровне сервера, применяется обычная блокировка по UA:

Nginx:

if ($http_user_agent ~* "chrome privacy preserving prefetch proxy") {
    return 403;
}

Apache (.htaccess):

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} "chrome privacy preserving prefetch proxy" [NC]
RewriteRule ^ - [F,L]

TrafficVeil:

  • найдите Chrome Prefetch Proxy в разделе ботов домена или в /system/bots;
  • если цель — просто снизить нагрузку от неиспользуемых предзагрузок, начните с настройки fraction в traffic-advice, а не с полного запрета в TrafficVeil;
  • полный deny в TrafficVeil имеет смысл, только если сайт систематически перегружен именно этим трафиком, а не отдельными пиками;
  • после изменения сверьте логи: доля запросов к /.well-known/traffic-advice и предзагрузок должна снизиться пропорционально выбранной fraction, органический трафик из поиска — остаться на месте.

7. Что делать: короткий алгоритм

  • Сайт получает заметный трафик из поиска Google, ресурсы позволяют — оставьте fraction: 1.0 или не трогайте вовсе: это ускоряет переходы для реальных пользователей и не портит аналитику при правильной настройке;
  • Origin ощутимо перегружен предзагрузками без последующих переходов — снижайте fraction постепенно (0.3 → 0.6 → 1.0), а не отключайте сразу полностью;
  • Нужна сетевая видимость переходов (родительский контроль, корпоративная фильтрация) — не блокируйте функцию, используйте штатный сигнальный DNS-механизм Chrome, он для этого и создан;
  • Нужен именно жёсткий запрет — сочетайте disallow: true в traffic-advice и блокировку по UA на сервере, чтобы закрыть оба канала;
  • Не путайте это правило с общим User-agent: * в robots.txt — оно не имеет отношения к данному механизму и не заменяет traffic-advice.

8. С кем не путать Chrome Prefetch Proxy

Бот / сосед Кластер Комментарий
Facebook External Hit, Discordbot, Twitterbot Fetcher-и превью ссылок В отличие от Chrome Prefetch Proxy это сторонние сервисы соцсетей и мессенджеров, которые разово забирают Open Graph-метаданные под карточку превью, а не встроенная функция браузера
Googlebot Поисковый краулер Полноценный поисковый обход для индексации — влияет на ранжирование, в отличие от prefetch-proxy
2ip Bot Прочие краулеры и сервисы легитимный
AccessStatus Прочие краулеры и сервисы легитимный
AgentReadinessScanner Прочие краулеры и сервисы легитимный

9. Стратегия allow/deny для Chrome Prefetch Proxy

Ситуация Действие
Стабильный трафик из поиска Google, ресурсы сервера в порядке Allow, fraction 1.0 в traffic-advice или файл вообще не настраивать
Заметная нагрузка от неиспользуемых предзагрузок Снизить fraction постепенно, не отключать резко
Требуется сетевая фильтрация контента для конечных пользователей Не блокировать функцию — задействовать штатный DNS-сигнальный механизм Chrome
Нужен полный и гарантированный запрет disallow: true в traffic-advice + блокировка по UA на сервере или в TrafficVeil
Подозрение на подделку UA Не доверять строке UA целиком — сверять IP с диапазоном 66.102.6.0/24 и обратный DNS

Частые вопросы

Chrome Prefetch Proxy — это краулер или бот-сканер?

Нет, это встроенная функция самого браузера Chrome, которая предзагружает страницы по факту реального интереса пользователя, а не автономный обход по расписанию.

Почему robots.txt не блокирует этот трафик?

Механизм управляется не через robots.txt, а через отдельный файл /.well-known/traffic-advice с собственным JSON-форматом и MIME-типом.

Как проверить, что запрос действительно от Google, а не подделка UA?

Сверьте IP с диапазоном 66.102.6.0/24 и обратный DNS вида google-proxy-*.google.com, не полагаясь только на строку User-Agent.

Влияет ли Chrome Prefetch Proxy на позиции сайта в поиске?

Нет, это не поисковый краулер, и на ранжирование в Google он не влияет.

Что делать, если предзагрузки создают заметную нагрузку на сервер?

Снижать долю пропускаемого трафика через поле fraction в traffic-advice постепенно, а не отключать функцию полностью и резко.

Можно ли настроить фильтрацию контента в сети, если пользователь переходит по предзагруженной ссылке?

Да, для этого у Chrome есть отдельный DNS-сигнальный механизм, который не требует блокировки самой функции предзагрузки.

#Chrome Prefetch Proxy#traffic-advice#User-Agent#Google#антибот#robots.txt#TrafficVeil
TV
TrafficVeil Team

Команда TrafficVeil разрабатывает инструменты защиты сайтов от ботов, DDoS и веб-атак.

Похожие статьи

Skype (общий токен): не один бот, а минимум три разных

Общий поиск по слову «skype» в логах цепляет сразу несколько разных, исторически связанных механизмов Microsoft — от закрытого в мае 2025 года превью-бота до активной внутренней инфраструктуры Teams, унаследовавшей кодовое имя SkypeSpaces. Разбираемся, почему общее правило блокировки по этому слову рискованно, и как разделить разные варианты в своих логах.

7 мин

Fedicabot: превью-fetcher Fedica, а не краулер Fediverse

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

6 мин

Amazon Kendra: возможно, ваш корпоративный поиск

Amazon Kendra — реальный сервис корпоративного поиска AWS, и его коннектор Web Crawler обходит только те конкретные URL, которые явно указал клиент AWS при настройке источника данных — то есть это не свободный обход, а целевая индексация по чьему-то заданию. Разбираемся, почему первый шаг здесь — проверить, не настроен ли на вашем сайте (или у партнёра) такой поисковый индекс, прежде чем блокировать бота как постороннего.

6 мин

Проверьте защиту своего сайта

Подключение занимает несколько минут. Начните с анализа трафика и включайте блокировки после проверки логов.