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 |