В iPhone достаточно включить «Частный узел», открыть Safari и увидеть на сайте уже другой IP-адрес. Интерфейс почти сам подталкивает к мысли, что Apple встроила в систему собственный VPN. Я бы так Private Relay не называл. Сервис действительно скрывает исходный IP, защищает DNS-запросы и пропускает веб-трафик Safari через два независимых посредника, но универсального системного туннеля не создаёт.
Практическая граница довольно чёткая. Private Relay защищает веб-сёрфинг Safari, DNS-разрешение имён и незашифрованный HTTP-трафик приложений. Обычный HTTPS-трафик остальных приложений не получает автоматически ту же защиту только потому, что пользователь включил «Частный узел». Поэтому Telegram, игра, банковское приложение, собственный сетевой клиент или команда в терминале могут работать по совсем другой сетевой схеме. Именно здесь заканчивается сходство Private Relay с полноценным VPN.
Материал посвящён устройству сетевой защиты и диагностике приватности. Используйте такие функции законно и с учётом требований своей страны, включая российское законодательство и правила сервисов. Инструкции не предназначены для несанкционированного доступа, слежки, взлома или незаконного обхода ограничений.
Как Private Relay разделяет ваш IP и историю посещений
Главная идея Private Relay мне нравится больше, чем привычная схема с одним посредником. Apple не пытается передать всю информацию одному серверу, которому пользователь затем вынужден полностью доверять. Вместо этого запрос проходит через два независимых узла. Архитектуру Apple подробно описывает в техническом документе.
iPhone или Mac
|
v
интернет-провайдер
|
v
первый узел Apple
видит исходный IP
не видит сайт
|
v
второй узел
не видит исходный IP
знает адрес сайта
|
v
сайт
видит IP Private RelayДомашний или мобильный оператор по-прежнему знает ваш настоящий IP. Иначе сеть физически не смогла бы доставить пакеты до первого узла. Провайдер также видит соединение с инфраструктурой Private Relay, объём и временные характеристики трафика. Для защищённых запросов оператор не должен получать список доменов, к которым обращается Safari.
Первый узел управляется Apple. Узел получает исходный IP, но имя сайта передаётся дальше в защищённом виде. Второй узел, который обслуживает сторонний поставщик инфраструктуры, получает имя нужного сайта и выбирает выходной IP Private Relay, но уже не знает исходный IP пользователя. Сайт видит соединение от второго узла.
| Участник | Что видит | Чего не должен видеть |
|---|---|---|
| Интернет-провайдер | Ваш исходный IP и соединение с Private Relay | Домены защищённого трафика Safari и защищённые DNS-запросы |
| Первый узел Apple | Исходный IP и примерный регион | Имя конечного сайта |
| Второй узел | Имя сайта и обобщённую географию | Исходный IP пользователя |
| Сайт | IP Private Relay, запросы браузера, cookies и данные самой сессии | Исходный IP при штатной работе Private Relay |
DNS Apple защищает отдельно. В документации описан механизм Oblivious DNS over HTTPS, сокращённо ODoH. DNS-запрос шифруется так, чтобы первый посредник знал источник соединения, но не содержимое DNS-запроса. DNS-сервер получает запрос через посредника и не должен видеть исходный адрес устройства.
Отсюда возникает важное различие между «скрыть IP» и «стать анонимным». Private Relay не стирает cookies, не разлогинивает аккаунт Google, не мешает сайту узнать зарегистрированного пользователя и не уничтожает браузерный отпечаток. Если я войду на сайт под своей учётной записью, сайт совершенно законно узнает меня по аккаунту, хотя увидит другой IP. Если я разрешу сайту точную геопозицию, Private Relay также не превращает координаты GPS в фикцию.
Локальная выдача при этом обычно сохраняется специально. Первый узел определяет примерный регион исходного IP, после чего второй узел выдаёт адрес Private Relay из соответствующей географической области. В настройках можно сохранить общую геопозицию либо ограничиться страной и часовым поясом. Поэтому поисковик продолжает показывать ближайшие магазины и местные новости, хотя точный домашний IP ему уже не достаётся.
Что Private Relay защищает, а что проходит мимо
Самая распространённая ошибка звучит так. «Раз IP изменился, значит весь iPhone теперь работает через Private Relay». Документация Apple говорит иначе. Компания прямо описывает защиту Safari, DNS и незашифрованного HTTP-трафика приложений. Для разработчиков Apple приводит тот же перечень в описании сервиса.
| Трафик | Private Relay |
|---|---|
| HTTP и HTTPS в Safari | Да, штатный веб-трафик проходит через архитектуру Private Relay |
| DNS-запросы устройства | Да, штатно защищаются, если настройки DNS не заменены другой конфигурацией |
| Незашифрованный HTTP из приложений | Да |
| Обычный HTTPS других приложений | Нет общей гарантии маршрутизации через Private Relay |
| Локальная сеть | Нет, локальные ресурсы доступны напрямую |
| MMS, часть служебного сотового трафика, Visual Voicemail | Нет |
| Трафик, отправленный через активный VPN | Использует VPN вместо Private Relay |
VPN работает на другом уровне. Системный VPN создаёт виртуальный сетевой интерфейс или туннель и может отправлять через него почти весь IP-трафик устройства. «Может» здесь принципиально. У VPN существуют раздельная маршрутизация, исключения, VPN для отдельных приложений и системные исключения. Поэтому фраза «любой VPN всегда шифрует вообще всё» тоже неверна.
Разница хорошо видна в документации Apple по маршрутизации VPN. Разработчик способен включить весь сетевой трафик в туннель, исключить отдельные сети или привязать VPN к конкретным приложениям. Private Relay подобной универсальной задачи перед собой не ставит.
Отсюда мой критерий выбора. Для обычного Safari на личном iPhone Private Relay представляет собой полезный дополнительный слой приватности с хорошей моделью разделения доверия. Если задача требует контролировать сетевой маршрут приложения, рабочего клиента, терминала или практически всего устройства, архитектурно нужен уже системный туннель. Я бы не пытался растянуть Private Relay на сценарий, для которого сервис не проектировали.
Private Relay также не предназначен для выбора произвольной страны. Apple специально сохраняет реальную страну или регион, поэтому сервис нельзя считать инструментом смены географии. Данный нюанс одновременно объясняет, почему локальные сайты продолжают работать ожидаемо и почему сравнение с коммерческими VPN часто получается некорректным.
Августовские утечки показали настоящую границу защиты
Хороший урок дала история с WebKit. В августе исследователи Talal Haj Bakry и Tommy Mysk описали три сетевых пути, которые могли выходить за стандартный маршрут проксирования Private Relay. Проблема оказалась особенно показательной именно потому, что обычная загрузка страницы продолжала идти через Private Relay, а отдельный вспомогательный запрос уходил напрямую.
Первый путь касался предварительного DNS-разрешения. Страница может попросить браузер заранее разрешить имя будущего ресурса через конструкцию <link rel="dns-prefetch">. Исследователи обнаружили сценарий, при котором такой запрос уходил через обычный сетевой путь устройства вместо защищённого маршрута.
Второй путь затрагивал WebAuthn, технологию, на которой основаны ключи доступа. При проверке связанных доменов системная служба учётных данных может самостоятельно запросить специальный файл с другого домена. Такой запрос рождается уже не внутри обычной цепочки загрузки Safari, поэтому у исследователей получалось раскрыть реальный IP без привычного диалога с пользователем.
Третий вариант использовал WebTransport. Протокол работает поверх HTTP/3 и QUIC и подходит для низколатентных двусторонних соединений. Ошибка маршрутизации позволяла WebTransport создать прямое соединение. Позже исправление попало в WebKit, а в официальном бюллетене Apple уязвимость получила идентификатор CVE-2026-65352. Связанная запись WebKit находится в Bugzilla проекта.
К середине сентября картина уже отличалась от первоначальных августовских публикаций. Apple исправила раскрытие IP в iOS и iPadOS 26.6.1, macOS Tahoe 26.6.2 и других поддерживаемых ветках. Отдельная проблема Authentication Services с тем же последствием получила CVE-2026-65355 и была исправлена также в iOS 18.7.10. Поэтому утверждение «Private Relay прямо сейчас всегда раскрывает IP через августовские методы» уже устарело для обновлённых систем. При этом Apple не сопоставила в бюллетене каждый первоначальный исследовательский сценарий отдельному CVE, так что считать количество CVE точным отражением всех трёх демонстраций не стоит.
История ценна по другой причине. Private Relay защищает конкретные сетевые маршруты. Если системный компонент или новый API создаёт соединение за пределами ожидаемого маршрута, приватность может нарушиться. Системный VPN в аналогичной ситуации обычно расположен ниже по сетевому стеку, поэтому прямому приложению сложнее просто «не заметить» туннель.
Как проверить настройки на своём iPhone или Mac
Глобальная настройка на iPhone находится в разделе «Настройки» → имя пользователя → iCloud → «Частный узел». Нужна подписка iCloud+. Apple сейчас указывает Россию в списке регионов, где Private Relay поддерживается, хотя конкретная сеть всё равно способна ограничить работу функции.
Пункт «Ограничение трекинга по IP-адресу» относится уже к конкретному сетевому подключению. Для Wi-Fi переключатель находится в свойствах сети. Для мобильного интернета настройка привязана к соответствующей SIM или eSIM. Если выключить параметр для Wi-Fi, Private Relay перестанет работать именно в данной сети. Apple описывает поведение в инструкции по настройке.
Самая простая практическая проверка не требует специальных программ. Сначала откройте в Safari надёжный сервис, который показывает внешний IP, и запишите адрес. Затем временно выключите Private Relay для текущей сети и обновите страницу. Адрес обычно изменится. После проверки включите функцию обратно. Такой тест показывает работу выходного узла, но не доказывает отсутствие любых возможных сетевых утечек.
На Mac можно дополнительно проверить, разрешаются ли служебные имена Private Relay.
dig mask.icloud.com
dig mask-h2.icloud.comКорпоративная или учебная сеть может специально возвращать отрицательный DNS-ответ для этих имён, чтобы запретить Private Relay. Apple официально предусматривает такой механизм для сетей, где администраторам требуется аудит трафика. Поэтому сообщение о недоступности Private Relay не обязательно означает поломку iPhone.
Ещё одна типичная путаница возникает при одновременной работе VPN. Apple указывает, что соединения, маршрутизируемые через VPN, не используют Private Relay. Если IP в Safari выглядит не так, как ожидалось, сначала проверьте активный VPN, профиль управления устройством, сетевой фильтр и пользовательскую настройку DNS.
Private Relay и VPN одно и то же?
Нет. Private Relay защищает определённые классы трафика и использует два независимых посредника. VPN создаёт сетевой туннель и в зависимости от конфигурации может маршрутизировать через него почти весь IP-трафик устройства или только выбранные приложения.
Скрывает ли Частный узел реальный IP-адрес?
Для штатно защищённого трафика сайт получает IP выходного узла Private Relay вместо исходного адреса пользователя. Интернет-провайдер и первый узел Apple исходный IP при этом знают.
Защищает ли Private Relay приложения кроме Safari?
Частично. Apple включает в область защиты DNS и незашифрованный HTTP-трафик приложений. Обычный HTTPS-трафик каждого приложения автоматически через Private Relay не проходит.
Что означает «Ограничение трекинга по IP-адресу»?
На устройствах с iCloud+ переключатель управляет Private Relay для конкретной Wi-Fi или сотовой сети. Отключение параметра позволяет трафику в данной сети идти без Private Relay.
Может ли сайт узнать точное местоположение при включённом Private Relay?
По IP сайт обычно получает только обобщённую географию, но разрешение браузеру передать точную геопозицию работает отдельно. Если пользователь разрешил доступ к геопозиции, Private Relay не скрывает предоставленные координаты.
Скрывает ли Частный узел историю посещений от Apple?
Архитектура Private Relay спроектирована так, чтобы Apple не получала одновременно исходный IP пользователя и имя посещаемого сайта. Первый узел знает исходный адрес, а второй обслуживает конечное соединение.
Нужно ли выключать Private Relay при использовании VPN?
Обычно система сама отдаёт приоритет VPN для трафика, который входит в его маршруты. Одновременное включение обеих функций не означает двойное последовательное туннелирование всего трафика.
Делает ли Private Relay пользователя анонимным?
Нет. Сервис снижает возможность связывать IP с веб-сёрфингом, но сайты по-прежнему могут узнавать пользователя по аккаунтам, cookies, действиям на странице, разрешённой геопозиции и другим признакам.
Я бы оставил Private Relay включённым для повседневного Safari, если сеть и рабочие требования не мешают его работе. Функция действительно уменьшает объём данных, который отдельно получает провайдер, Apple или сайт. Но рассчитывать на «встроенный VPN от Apple» не стоит. Когда критично скрыть сетевой маршрут всего устройства или конкретного приложения, сначала нужно понять, какой именно трафик должен попасть в туннель. Private Relay решает более узкую задачу и именно в этих границах работает лучше всего.
