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

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

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

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

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

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

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