Куда на самом деле уезжают данные посетителей вашего сайта

MAATRIX

Вы разместили сайт на сервере в России, настроили 152-ФЗ-совместимое хранение базы данных и мысленно закрыли вопрос с персональными данными. А тем временем при каждой загрузке страницы браузер посетителя тихо отправляет десяток запросов в обход вашего сервера — к зарубежным CDN шрифтов, аналитическим платформам, рекламным сетям и виджетам чатов. Эта статья — практическое руководство, как увидеть эти запросы своими глазами и что с ними делать.

Почему сервер в России не значит, что данные остаются в России

Логика «мой сервер в РФ — значит, я в порядке» разваливается на одном простом факте: сайт — это не только ваш backend. Это HTML-страница, в которую вставлены ссылки на десятки внешних ресурсов — шрифты, скрипты аналитики, иконки соцсетей, пиксели, виджеты чата. Когда браузер посетителя получает эту страницу, он не спрашивает разрешения у вашего сервера — он напрямую открывает соединения с каждым доменом, упомянутым в <script src="...">, <link href="...">, @import url(...) и десятках мест, куда сторонние SDK дописывают код динамически.

Каждое такое соединение уносит с собой минимум: реальный IP-адрес посетителя, User-Agent, заголовок Referer (то есть URL страницы, которую он смотрит), а часто ещё и cookie, которые этот сторонний сервис уже успел поставить в предыдущий визит на любой другой сайт, где стоит тот же виджет. Ваш backend в этот момент вообще не участвует — соединение идёт от браузера посетителя напрямую к серверам третьей стороны, физически расположенным где угодно, и вы как владелец сайта можете об этом даже не знать.

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

Шесть категорий кода, которые чаще всего «звонят домой»

На практике почти весь трафик к сторонним доменам сводится к нескольким повторяющимся категориям.

• Веб-аналитика. Счётчики посещаемости почти всегда шлют на сервер аналитической платформы полный набор: IP, UA, referrer, разрешение экрана, язык браузера, а с включённым отслеживанием событий — ещё и клики, скролл, время на странице.
• Шрифты с внешних CDN. Самая недооценённая категория: подключение шрифта — это HTTP-запрос к чужому серверу при каждой загрузке страницы, притом что функционально шрифт прекрасно раздаётся с вашего собственного сервера.
• Виджеты соцсетей. Кнопки «поделиться», встроенные посты, блоки комментариев — всё это iframe или скрипт, который тянет данные с серверов соцсети и параллельно сообщает ей, что конкретный браузер (со своими cookie от предыдущей авторизации в этой соцсети) сейчас находится на такой-то странице вашего сайта.
• Рекламные и ретаргетинговые пиксели. По конструкции существуют именно для того, чтобы передавать рекламной платформе факт визита и связать его с профилем пользователя — это не побочный эффект, а прямое назначение.
• Виджеты чатов поддержки. Часто недооценённый источник утечки: помимо технических метаданных, через такой виджет иногда уходит содержимое переписки, включая email, телефон, а порой и скриншоты, которые пользователь прикладывает к обращению.
• Сторонние JS-библиотеки с публичных CDN. Иконки, графики, карты, видеоплееры, подключаемые через <script src="https://cdn.стороннего-сервиса/..."> — формально не про аналитику, но каждый такой запрос всё равно светит IP посетителя перед сервером CDN.

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

Практический аудит: как увидеть, что реально грузит ваш сайт

Первый и самый честный источник правды — вкладка Network в DevTools браузера, а не документация вендора виджета.

1. Откройте сайт в режиме инкогнито (чтобы не тащить старые cookie и кэш).
2. Откройте DevTools → вкладка Network, включите «Disable cache».
3. Перезагрузите страницу и дайте ей полностью прогрузиться, включая отложенные скрипты (подождите 5–10 секунд — многие трекеры и чаты подгружаются с задержкой намеренно, чтобы не тормозить первую отрисовку).
4. Отсортируйте список запросов по колонке Domain — так сразу видно, сколько разных хостов участвует в загрузке одной страницы.
5. Сохраните весь список через правый клик → «Save all as HAR with content» — получите файл, который можно грепать скриптом и хранить как снимок «было на такую-то дату».

Второй способ — быстрый и грубый, из терминала, для статических ссылок в HTML/CSS (он не поймёт то, что скрипты дописывают в DOM динамически, но как первая прикидка годится):

curl -s https://ваш-сайт.ru/ \
  | grep -oE '(src|href)="https?://[^"]+"' \
  | sed -E 's/^(src|href)="//; s/"$//' \
  | awk -F/ '{print $3}' \
  | sort -u

Для точного списка, включая всё, что скрипты добавляют динамически (а это большинство трекеров и чатов), нужен headless-браузер. Минимальный скрипт на Node с Puppeteer:

// audit.js
const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  const hosts = new Set();

  page.on('request', req => {
    try {
      hosts.add(new URL(req.url()).hostname);
    } catch (_) {}
  });

  await page.goto('https://ваш-сайт.ru', { waitUntil: 'networkidle2', timeout: 30000 });
  await new Promise(r => setTimeout(r, 5000)); // добор отложенных скриптов

  console.log([...hosts].sort().join('\n'));
  await browser.close();
})();

Запускается так:

npm install puppeteer
node audit.js

На выходе — чистый список доменов, к которым реально обращался браузер при загрузке страницы. Прогоните так 3–5 ключевых страниц сайта (главную, карточку товара, страницу с формой) — набор виджетов на разных типах страниц часто отличается.

Как читать список доменов: свои, российские, зарубежные

Полученный список стоит разложить на три группы.

Свои домены и поддомены. Основной домен, CDN-поддомен, который вы сами настроили (static.ваш-сайт.ru) — это нормально, данные остаются под вашим контролем.

Домены в российской юрисдикции. Сервисы вроде yandex.ru, mail.ru, vk.com и их поддоменов — это тоже сторонние домены с собственным сбором данных, но по крайней мере формально подпадающие под российское законодательство. Это не означает автоматической «безопасности» — у каждого такого сервиса своя политика логирования, которую стоит прочитать отдельно, если объём трафика значимый.

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

Отдельная ловушка — маскировка. Домен в списке запросов не всегда говорит правду о том, куда данные летят на самом деле: некоторые трекеры сознательно проксируются через поддомен вашего же сайта (так называемый server-side tagging или reverse-proxy трекинг), чтобы выглядеть «своим» доменом и обходить блокировщики. В этом случае в Network-панели вы увидите свой домен, а реальный получатель виден только по пути запроса или по содержимому payload. Если сомневаетесь — откройте сам запрос и посмотрите тело: обычно там остаётся идентификатор исходного вендора.

Замена 1: self-hosted шрифты вместо внешнего CDN

Шрифты — самая простая и самая безболезненная замена, потому что здесь нет никакого функционального компромисса: self-hosted шрифт работает идентично, только без постороннего запроса на каждой загрузке страницы.

Шаг 1 — скачайте файлы шрифта. Если шрифт сейчас подключён через внешний CDN, откройте DevTools → Network → фильтр Font, перезагрузите страницу и сохраните файлы .woff2 напрямую из вкладки.

Шаг 2 — при необходимости сделайте subset (уберите ненужные символы, оставив, например, только кириллицу и базовую латиницу — это ещё и уменьшит вес файла):

pip install fonttools brotli
pyftsubset inter-variable.ttf \
  --output-file=inter-cyrillic.woff2 \
  --flavor=woff2 \
  --unicodes="U+0000-00FF,U+0400-04FF,U+2116"

Шаг 3 — положите файл на свой сервер и подключите через @font-face:

@font-face {
  font-family: "Inter";
  src: url("/assets/fonts/inter-cyrillic.woff2") format("woff2");
  unicode-range: U+0000-00FF, U+0400-04FF, U+2116;
  font-display: swap;
  font-weight: 400 700;
}

Шаг 4 — настройте кэширование на своей стороне, раз уж теперь это ваша зона ответственности:

location ~* \.(woff2?|ttf)$ {
    add_header Cache-Control "public, max-age=31536000, immutable";
    access_log off;
}

Результат: ни один посетитель больше не делает запрос к постороннему серверу только ради того, чтобы отрисовался текст. Дополнительный бонус — страница чаще грузится быстрее, потому что убирается лишнее DNS-разрешение и TLS-хендшейк к внешнему хосту.

Замена 2: аналитика, чаты и пиксели — что реально можно перенести на свой сервер

Здесь компромиссов больше, но и пространство для манёвра шире.

Аналитика. Есть два практичных пути. Первый — self-hosted открытые платформы (например, Matomo, Plausible, Umami, PostHog — у каждой свои сильные стороны и объём ресурсов под неё, сравнивайте под свою нагрузку), которые вы разворачиваете на собственном VPS через Docker и данные физически не покидают ваш сервер:

# фрагмент docker-compose.yml, конкретные образы и переменные — по документации выбранного проекта
services:
  analytics-db:
    image: postgres:16
    restart: unless-stopped
    volumes:
      - ./pgdata:/var/lib/postgresql/data
  analytics:
    image: <образ_выбранной_платформы>
    restart: unless-stopped
    depends_on:
      - analytics-db
    ports:
      - "127.0.0.1:3000:3000"

Второй путь — аналитика от сервиса с размещением данных в России (например, Яндекс.Метрика как самый известный вариант) — проще во внедрении, не требует своего сервера под аналитику, но данные всё равно уходят в инфраструктуру стороннего оператора, просто внутри РФ-юрисдикции.

Чаты поддержки. SaaS-виджеты чата удобны, но именно они чаще всего сливают контактные данные и содержимое переписки за периметр. Если объём обращений оправдывает содержание своей инфраструктуры — разверните self-hosted решение на своём сервере; например, пошаговая установка Rocket.Chat на VPS — рабочий вариант, если вы готовы взять на себя администрирование взамен на полный контроль над данными переписки.

Рекламные пиксели. Самая сложная категория для замены, потому что их прямое назначение — сообщать данные о посетителе рекламной платформе, и без этого ретаргетинг просто не работает. Частичная мера — server-side tagging: событие сначала попадает на ваш backend, а он уже сам решает, что и в каком виде переслать рекламной платформе, не раскрывая напрямую браузеру посетителя адрес и не позволяя блокировщикам его вырезать. Это не устраняет передачу данных как таковую — конечная точка получения данных остаётся той же, меняется только технический путь и то, что именно утекает (например, можно не пересылать полный User-Agent). Честно: это полумера, а не решение вопроса приватности, и некоторые рекламные платформы регулируют такой способ интеграции собственными условиями использования — прежде чем внедрять, проверьте, что это не нарушает договор с конкретной площадкой.

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