Один запрос, пять наблюдателей: что сайт, провайдер, DNS и VPN узнают, когда вы открываете страницу

Фраза «у меня HTTPS, значит провайдер ничего не видит» звучит убедительно ровно до тех пор, пока не спросить: а что именно считать «ничем»?

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

Я хочу разобрать один обычный запрос. Без всякой чуши про тотальную слежку и без обещаний абсолютной невидимости.

Допустим, пользователь открывает адрес:

https://news.example/articles/privacy?from=mail

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

Маршрут у запроса примерно такой:

браузер ── DNS-запрос ──> DNS-резолвербраузер ── TLS/HTTPS ──> сайт или его CDN

Роутер и провайдер находятся на пути обоих соединений. Но одинаковый маршрут ещё не означает одинаковую видимость.

Браузер знает полный адрес и решает, что к нему приложить

До первого сетевого пакета браузер уже знает полный URL: домен, путь /articles/privacy и параметр from=mail. Он также хранит состояние, которое осталось от прошлых посещений: cookies, данные сайтов, авторизации, разрешения, историю для самого пользователя.

Но браузер не отправляет весь этот набор каждому сайту подряд. Он применяет правила.

Для news.example он может приложить cookies, которые относятся к этому домену и подходят под условия отправки. Если пользователь вошёл в аккаунт, в запрос часто уходит сессионный идентификатор или заголовок авторизации. Сервер по нему связывает запрос с учётной записью.

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

• localStorage одного сайта недоступен другому сайту: хранилище разделено по origin;

• cookie с флагом HttpOnly сайт получает в HTTP-запросе, но JavaScript на странице его не прочитает;

• сайт не получает список всех вкладок и всю историю браузера по одному факту открытия страницы.

Эти ограничения часто теряются в пересказах. Получается две одинаково неверные крайности: «сайт видит вообще всё» и «сайт видит только IP».

Cookies и Web Storage устроены гораздо приземлённее: браузер хранит данные, а затем отдаёт их в рамках конкретных правил.

DNS-резолвер узнаёт имя, которому нужен IP-адрес

Чтобы подключиться к news.example, браузеру нужен IP-адрес. Для этого он спрашивает DNS-резолвер: «какой адрес у news.example?»

Если используется обычный незашифрованный DNS, такой запрос по пути может видеть локальная сеть и провайдер. Сам резолвер видит имя домена и IP-адрес клиента, с которого пришёл запрос. Но DNS не содержит путь /articles/privacy, текст страницы или пароль из формы: его задача — сопоставить имя с адресом.

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

DNS over HTTPS и DNS over TLS шифруют участок между устройством и выбранным резолвером. Провайдер тогда видит соединение с DNS-сервисом, но не имя, которое передаётся внутри него. Сам резолвер никуда не исчезает — он всё так же получает доменное имя. Просто доверенная сторона меняется.

DNS over HTTPS описывает передачу DNS-запросов внутри HTTPS, а DNS over TLS — тот же принцип поверх TLS.

Провайдер видит маршрут и метаданные, но не содержание HTTPS-страницы

Когда IP-адрес найден, браузер устанавливает соединение с сервером. Для HTTPS он сначала договаривается о шифровании через TLS, а уже затем отправляет HTTP-запрос.

Провайдер в обычной ситуации видит:

• IP-адрес абонента и время соединения;

• IP-адрес, к которому установлено соединение;

• порт — для HTTPS обычно 443;

• объём трафика, длительность и характер обмена;

• DNS-запросы, если они не защищены;

• имя из SNI в TLS ClientHello, если ECH не используется.

Последний пункт требует оговорки. HTTPS давно шифрует HTTP-данные: путь страницы, параметры запроса, заголовки, пароли и текст ответа не должны быть видны наблюдателю в сети. Однако до появления Encrypted Client Hello имя сервера нередко оставалось в открытой части TLS-рукопожатия через SNI.

ECH шифрует внутренний ClientHello, включая настоящее имя сервера. Но для этого нужны поддержка браузера, DNS-инфраструктуры и самого сайта. Даже при ECH наблюдатель всё равно видит IP-адрес назначения, объём трафика и время соединения. По этим метаданным иногда строят предположения, но предположение — не то же самое, что чтение URL.

На этом месте полезно помнить ещё одну вещь: один IP-адрес часто обслуживает много доменов, особенно за CDN. По IP нельзя автоматически и безошибочно назвать сайт.

TLS 1.3 описан в RFC 8446, классический SNI — в RFC 6066, а ECH — в RFC 9849.

Сайт получает больше всех данных, которые нужны именно ему

На другом конце соединения находится не абстрактный «интернет», а сайт, его CDN, балансировщик или прокси. Эта сторона расшифровывает HTTPS, потому что именно с ней браузер установил защищённое соединение.

Сервис обычно получает:

• IP-адрес, с которого пришёл запрос;

• путь страницы и параметры URL;

• заголовки HTTP, включая Referer, если браузер решил его отправить;

• cookies, относящиеся к этому сайту;

• данные авторизации;

• сведения, которые браузер раскрывает через User-Agent и Client Hints;

• данные, собранные скриптами на странице;

• всё, что пользователь сам ввёл в форму или отправил сообщением.

Заголовок Referer тоже не стоит переоценивать. Его содержимое зависит от перехода и политики Referrer-Policy: сайт может получить полный адрес предыдущей страницы, только origin или вообще ничего. HTTP Semantics описывает этот механизм, включая ограничения на передачу чувствительных частей URL.

Если пользователь вошёл в аккаунт, вопрос «узнает ли сайт меня после смены IP?» обычно перестаёт быть технической загадкой. Аккаунт уже даёт сервису устойчивую связь с человеком. Смена IP здесь меняет адрес доставки пакетов, но не отменяет авторизацию.

Cookies работают похожим образом. Сервер может сохранить в браузере случайный идентификатор и встретить его при следующем визите. HttpOnly полезен против кражи cookie через JavaScript, но сам сайт всё равно получает этот cookie вместе с запросом.

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

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

Одна страница часто знакомит браузер сразу с несколькими компаниями

Адресная строка говорит news.example, но загруженная страница может запросить картинки у CDN, шрифты у другого домена, аналитику, рекламные блоки, видеоплеер или виджет комментариев.

У каждого такого запроса будет свой получатель, свой набор заголовков, свои cookies и свои правила хранения. Поэтому вопрос «что видит сайт?» лучше уточнять: какой именно участник страницы?

Основной сервис не получает cookies аналитического домена. Зато аналитический домен получает запрос к своему ресурсу и может увидеть собственный идентификатор, если браузер имеет право его отправить. Современные браузеры по-разному ограничивают межсайтовые cookies, но сайты не сводят отслеживание только к ним: остаются авторизации, first-party storage, параметры ссылок и серверные сопоставления.

Вот почему «я удалил cookie одного сайта» и «меня больше никто нигде не узнает» — слишком большой вывод из маленького действия.

VPN меняет маршрут, а не очищает браузер

Теперь включим VPN с полнотуннельным режимом. Маршрут станет таким:

браузер ── зашифрованный туннель ──> VPN-сервер ── TLS/HTTPS ──> сайт

Для провайдера домашнего интернета соединение теперь заканчивается на VPN-сервере. Он видит IP-адрес VPN, время работы туннеля и объём переданных данных. При нормально работающем туннеле провайдер не видит прямое соединение браузера с news.example.

Сайт, в свою очередь, видит IP-адрес выхода VPN. Домашний IP он не получает.

Зато появляется новый наблюдатель: VPN-сервис. Он знает IP пользователя, принимает его трафик и устанавливает соединения дальше. Если VPN сам обслуживает DNS, он видит и DNS-запросы. Если запросы идут к внешнему DNS-сервису внутри туннеля, VPN видит соединение с этим DNS-сервисом, а содержимое зависит от того, используется ли DoH или DoT.

HTTPS по-прежнему защищает содержимое страницы от обычного VPN-туннеля: VPN пересылает зашифрованные пакеты, но не должен видеть текст формы или ответ сервера. Исключения возможны, если пользователь сам установил доверенный сертификат прокси или оказался в управляемой сети с TLS-инспекцией.

У браузерного расширения «VPN» границы могут быть уже: оно способно проксировать только вкладки браузера, а не весь трафик устройства. Поэтому в статье про приватность полезнее говорить не «я включил VPN», а «какой трафик и DNS этот клиент действительно направляет через туннель».

VPN не делает пользователя невидимым. Он убирает домашний IP из поля зрения сайта и переносит доверие с провайдера на VPN-сервис. Для многих задач этого достаточно. Для остальных нужно разбираться дальше.

Почему сайт может связать визиты после смены IP

Когда сайт узнаёт пользователя после VPN, чаще всего причина лежит выше сетевого уровня.

Вот типичный порядок силы идентификаторов:

1. Аккаунт. Вход по логину, почте, номеру телефона или SSO сразу связывает визит с учётной записью.

2. Сессионный cookie или другой сохранённый идентификатор. Сервис встречает тот же маркер, который сам выдал раньше.

3. Данные сайта в браузере. localStorage, IndexedDB и прочее состояние в пределах origin.

4. Браузерный отпечаток. Он помогает предположить, что два визита относятся к одному окружению.

5. Поведенческие и контекстные признаки. Время активности, привычная последовательность действий, настройки языка и региона.

6. IP-адрес. Он полезен как сигнал о сети и примерном регионе, но сам по себе редко равен человеку.

Смена IP затрагивает только последнюю строку. Если человек авторизован в сервисе, удалять cookies и менять IP можно сколько угодно — сервис всё равно видит аккаунт.

Инкогнито решает задачу на устройстве, а не в сети

Режим инкогнито часто ставят рядом с VPN, хотя они решают разные задачи.

Инкогнито открывает отдельную временную сессию. Пока все приватные окна не закрыты, сайты могут сохранять в ней cookies и данные, чтобы нормально работать. После завершения сессии браузер удаляет это временное состояние. Обычная история посещений не попадает в профиль.

При этом сайт видит запросы, провайдер видит сетевые метаданные, а VPN при включённом туннеле видит трафик, который через него проходит. Скачанные файлы и созданные закладки тоже остаются на устройстве.

Это прямо подтверждает справка Chrome об инкогнито: сайты, провайдер и администратор сети всё ещё могут наблюдать активность.

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

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

У слова «приватность» слишком много значений, чтобы его закрыла одна кнопка.

На последней строке обычно и ломаются разговоры про «просто включи VPN». Анонимность не появляется из-за нового IP: её легко разрушить входом в знакомый аккаунт, уникальным отпечатком браузера или обычной привычкой открывать один и тот же сервис в одной и той же сессии.

Во время написания статьи наткнулся на интересную ситуацию, при включенном VPN cookies отличаются от тех, что показываются на сайте без VPN. Хотя я собирался доказать обратное…

О том, почему так произошло, я написал в своём Телеграм канале. (Ссылка ниже)

HTTPS защищает содержание обмена. Защищённый DNS убирает из прямой видимости имя, которое спрашивает браузер. VPN меняет маршрут и IP, который увидит сайт. Инкогнито очищает временное состояние на устройстве после завершения сессии.

Ни один из этих механизмов не отменяет остальные слои. Поэтому вместо вопроса «кто следит за мной в интернете?» полезнее держать в голове другой: какую именно информацию я хочу скрыть, от кого и какой ценой?

---

В этой статье я попытался собрать в одну картину то, что обычно объясняют кусками: DNS, HTTPS, VPN, cookies и браузерные отпечатки. Разбирался по ходу сам, где заканчивается защита трафика, почему смена IP не отменяет авторизацию и кому в итоге приходится доверять.

В Telegram-канале «Кибербезнадёжен» я продолжаю разбираться в кибербезопасности и IT: проверяю популярные советы, делюсь тем, что изучаю, и честно пишу о местах, где сам пока плаваю. Если вам близок такой подход — подписывайтесь. Буду рад обсудить статью и ваши наблюдения в комментариях.