IPv4 или IPv6: какой адрес на самом деле видит сайт?

Откройте IP-аналитику BrowserInsight на современном подключении — и часто увидите сразу два адреса: IPv4-адрес вроде 198.51.100.20 и IPv6-адрес вроде 2001:db8:85a3::8a2e:370:7334. Иногда оба геолоцируются в один и тот же город. Иногда — нет. А если проверить завтра, сайт, сегодня записавший ваш IPv4-адрес, завтра может записать вместо него IPv6 — то же устройство, та же сеть, ничего не менялось. Это не сбой. Это видимый результат двух отдельных решений, которые ваша операционная система и браузер принимают при каждом новом соединении, и почти никто не видит, как это происходит.

Ключевые выводы

• Значительная часть домашних и мобильных подключений сегодня — dual-stack: у вашего устройства одновременно есть действующий IPv4-адрес и действующий IPv6-адрес, и сайт может в итоге зафиксировать любой из них.
• За выбор адреса отвечают два независимых механизма на разных уровнях: ОС выбирает исходный адрес для каждого назначения (RFC 6724), а логика соединения браузера устраивает «гонку» между обоими протоколами и оставляет тот, что ответил первым — это Happy Eyeballs v2 (RFC 8305).
• Какой протокол «победит» — это результат конкретной попытки соединения, а не ваша настройка: одна и та же машина может показаться сайту как IPv4 в одно посещение и как IPv6 в другое.
• Коммерческие базы геолокации описывают адресное пространство IPv6 гораздо хуже, чем IPv4, поэтому два ваших адреса могут геолоцироваться в разные города или даже страны.
• Если VPN или прокси туннелирует только один из протоколов, второй пойдёт своим обычным, нетуннелированным путём — это настоящая утечка, а не косметическое несоответствие. См. защиту от утечек WebRTC и защиту от DNS-утечек — там та же проблема проявляется тем же образом.

Почему у вас вообще два адреса

IPv4 и IPv6 — это две независимые системы адресации, работающие параллельно, а не «новая версия», заменяющая старую. Около 4,3 миллиарда адресов IPv4 закончились быстрее, чем рассчитывали создатели ранней сети, поэтому IPv6 спроектировали с намного большим адресным пространством и внедряли постепенно — а значит, десятилетиями обеим системам приходилось сосуществовать. Сегодня многие домашние и мобильные сети работают в режиме dual-stack: роутер или оператор выдаёт устройству рабочий адрес сразу в обеих системах. Ваше устройство не выбирает один из них втихую — у него реально есть оба, и оба готовы к использованию в любой момент.

Но так далеко продвинулись ещё не все сети. Внедрение IPv6 до сих пор сильно различается от страны к стране и от провайдера к провайдеру, а у подключения, которому IPv6 не выдали, публичный адрес ровно один. Если инструмент показывает вам только IPv4-адрес — дело в том, как ваш провайдер разворачивает IPv6, а не в сбое инструмента: пока оператор не включит IPv6, всё сказанное ниже о том, какой адрес видит сайт, к вам просто не относится.

Это только исходные условия. А то, какой именно адрес увидит конкретный сайт, определяют два отдельных решения, которые принимают два разных компонента софта в два разных момента.

Решение первое: ОС выбирает исходный адрес для каждого назначения

Прежде чем произойдёт хоть одна попытка соединения, сетевой стек вашей ОС должен решить, какой из ваших локальных адресов использовать для конкретного назначения — одному сетевому интерфейсу нередко назначено сразу несколько адресов IPv4 и IPv6. Это механизм выбора адреса по умолчанию, стандартизированный в RFC 6724: он применяет фиксированный набор правил — предпочесть совпадающую область видимости, предпочесть адрес, у которого с адресом назначения совпадает больше бит префикса, предпочесть временный IPv6-адрес постоянному, если оба доступны, и ещё несколько правил-разграничителей после этого. Ни одно из этих правил не спрашивает, какой протокол вам больше нравится — они только определяют, какой исходный адрес наиболее подходит, учитывая назначение и то, какие адреса сейчас есть у вашего интерфейса.

Решение второе: браузер устраивает гонку между протоколами и оставляет победителя

Выбор исходного адреса ещё не определяет, по какому именно протоколу — IPv4 или IPv6 — в итоге пойдёт соединение к dual-stack сайту. Это отдельное, более позднее решение, и принимает его логика соединения в браузере (или в системной сетевой библиотеке, которую он вызывает) — уже после того, как резолвер вернул и IPv4-, и IPv6-адрес для имени хоста. Старые реализации пробовали один протокол, ждали сбоя или таймаута и только потом переключались на другой — из-за чего сломанный или медленный путь по IPv6 действительно становился причиной заметно более медленной загрузки страниц. Современное решение — Happy Eyeballs v2, описанный в RFC 8305: браузер начинает попытку соединения по IPv6-адресу, ждёт короткий интервал (RFC 8305 рекомендует около 250 миллисекунд), и если за это время IPv6 не успел, параллельно запускает попытку по IPv4 — оба идут одновременно, и соединение завершается тем протоколом, который первым ответил. Проигравшая попытка просто отбрасывается.

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

И у вас нет способа со стороны клиента понаблюдать за этой гонкой. Network Information API браузера (navigator.connection) сообщает странице общий тип вашего соединения и примерную скорость — но ничего не говорит о том, какой протокол реально использовался для конкретного запроса. Эта информация существует только на принимающей стороне, и именно поэтому такому инструменту, как IP-аналитика, приходится спрашивать у сервера, что он увидел, а не читать это из браузера напрямую.

Следствие первое: одно и то же устройство сегодня — IPv4, завтра — IPv6

Поскольку гонка перезапускается при каждом соединении, а её исход зависит от сиюминутных условий — задержки DNS-ответа, перегрузки сети, того, какой резолвер ответил первым, — один и тот же ноутбук в одной и той же сети Wi-Fi вполне может при одной загрузке страницы быть зафиксирован как IPv4-посетитель, а при следующей — как IPv6. Только не переоценивайте частоту: на исправном dual-stack подключении IPv6 обычно выигрывает и продолжает выигрывать, так что переключение вы не будете наблюдать поминутно. Оно всплывает, когда что-то меняется под капотом: путь по IPv6 перегружен или деградировал, ответил другой резолвер, у сайта IPv6 есть не на всех хостах, или вы перешли в другую сеть. Если вы пытаетесь понять, почему история входов, правило ограничения частоты запросов или запись в allowlist ведут себя непоследовательно, «какой протокол выиграл гонку в этот раз» часто и есть та переменная, которую упускают из виду, а не признак поломки.

Следствие второе: ваши два адреса могут геолоцироваться по-разному

Адресное пространство IPv4 распределялось десятилетиями, и коммерческие базы геолокации давно успели его описать; пространство IPv6 сравнительно новое и описано куда менее полно, потому что огромные блоки были выделены совсем недавно, а многие провайдеры маршрутизируют его через инфраструктуру, которую базы данных ещё не успели полностью описать. На практике это означает, что ваши IPv4- и IPv6-адреса могут геолоцироваться в разные города — иногда в разные страны, — хотя оба действительно принадлежат одному и тому же подключению. Это не утечка и не ошибка с вашей стороны, а разрыв в том, насколько полно картировано каждое адресное пространство. IP-геолокация подробно разбирает базы данных и сигналы, стоящие за этой картой; здесь же — просто частный случай, когда два запроса для одного подключения дают разный ответ.

Следствие третье: туннель, покрывающий только один протокол, сливает второй

Вот что действительно стоит проверить. Некоторые VPN-клиенты и настройки прокси перехватывают только трафик IPv4 — то ли по замыслу, то ли потому что поддержку IPv6 добавили поздно или не добавили вовсе. В этом случае ваш IPv4-трафик, как и планировалось, идёт через туннель, но IPv6-адрес устройства остаётся активным и по-прежнему выигрывает гонку Happy Eyeballs на любом dual-stack сайте с поддержкой IPv6, отправляя этот трафик по вашему реальному, нетуннелированному подключению. В итоге на одной и той же загрузке страницы сайт видит и IPv4-адрес выхода вашего VPN, и ваш настоящий IPv6-адрес. Это настоящая утечка IPv6, а не косметическая нестыковка, и она встаёт в один ряд с другими путями утечки, подрывающими туннель тем же образом: защита от утечек WebRTC рассказывает, как то же самое происходит на уровне сбора ICE-кандидатов для медиасоединений, а защита от DNS-утечек — как нешифрованный запрос к резолверу полностью обходит туннель. Тест на утечки, проверяющий только смену IPv4-адреса, вполне может это пропустить — проверять нужно оба протокола.

Следствие четвёртое: CGNAT — проблема только IPv4

Carrier-Grade NAT (CGNAT) — когда провайдер делит один публичный IPv4-адрес между сотнями или тысячами абонентов — существует именно для того, чтобы растянуть сокращающийся запас IPv4. Адресного пространства IPv6 достаточно, чтобы провайдеры выдавали каждому клиенту отдельный блок, поэтому ваш IPv6-адрес обычно не делится ни с кем. У этого есть две стороны. На стороне IPv4 совместное использование адреса с незнакомцами означает, что из-за одного злоумышленника в том же пуле CGNAT под подозрение может попасть весь общий адрес — именно этот механизм лежит в основе статьи вас приняли за VPN, хотя вы им не пользуетесь; ваш IPv6-адрес, будучи неразделяемым, этому конкретному риску не подвержен. Но обратная сторона в том, что неразделяемый IPv6-адрес — это чуть более точный лично ваш идентификатор, без трафика других абонентов, размывающего картину. (Механику аренды и ротации адреса во времени полностью разбирает статья почему ваш IP-адрес постоянно меняется — здесь речь только о различии протоколов в том, делится ли адрес с кем-то ещё.)

Что можно проверить прямо сейчас

Откройте IP-аналитику и посмотрите на оба сообщённых адреса:

• Геолоцируются ли они в одно и то же место? Если нет — скорее всего, дело в более слабом покрытии баз данных для IPv6, а не в ошибке; почему — см. IP-геолокацию.
• Если вы используете VPN или прокси, показывает ли он IPv4-адрес выхода туннеля вместе с адресом IPv6, который через туннель не проходит? Если ваш реальный IPv6-адрес виден рядом с туннелированным IPv4-адресом, значит туннель не покрывает IPv6 — и вы сливаете его на каждом dual-stack сайте.
• Перезагрузите страницу несколько раз. На работающем dual-stack подключении картина обычно не меняется, потому что IPv6 продолжает выигрывать гонку, — стабильный результат здесь норма, а не доказательство того, что никакой гонки нет. Если же результат действительно меняется от загрузки к загрузке без каких-либо других изменений, значит гонка Happy Eyeballs разрешается по-разному вслед за условиями сети: это ровно так же ожидаемо и точно не сбой.

Как это соотносится с другими статьями сайта об IP

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

Часто задаваемые вопросы

Инструмент показывает только один адрес. Что-то сломалось?

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

Почему сайт иногда показывает не ту страну?

Если ошибочно геолоцируется именно ваш IPv6-адрес, частая причина — более слабое покрытие баз данных для адресного пространства IPv6; полную картину, включая причины со стороны IPv4, см. в статье про IP-геолокацию.

Можно ли заставить браузер всегда использовать IPv4 или всегда IPv6?

В большинстве операционных систем можно отключить один из протоколов на уровне сетевого интерфейса — тогда он вообще выпадает из гонки Happy Eyeballs. Это довольно грубый инструмент: он затрагивает все соединения на этом интерфейсе, а не только то, которое вы пытаетесь диагностировать, и отключение IPv6 не делает вас приватнее — оно просто убирает один из двух ваших адресов из картины.

Наличие сразу IPv4- и IPv6-адреса — это риск для приватности?

Само по себе нет. Это просто означает, что проверять нужно уже два адреса, а не один — особенно когда вы удостоверяетесь, что VPN или прокси полностью покрывает ваш трафик: как показано выше, IPv6-адрес, оставшийся за пределами туннеля, — это настоящая утечка.

Значит ли Happy Eyeballs, что IPv6 всегда используется первым?

Ему дают фору (RFC 8305 предлагает около 250 миллисекунд), после чего параллельно запускается и попытка по IPv4 — побеждает тот, кто первым завершит TCP-рукопожатие. Так что при быстром и рабочем IPv6 приоритет действительно у него, но медленный или проблемный путь по IPv6 в рамках той же попытки соединения уступает место IPv4, а не приводит к прямому отказу.

Заключение

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

Рекомендуем почитать:

• Приватные расширения IPv6: как ваш адрес перестаёт вас выдавать
• Почему ваш IP-адрес постоянно меняется (и когда — нет)
• IP-геолокация: баланс точности и приватности
• Защита от утечек WebRTC: обязательна для VPN
• Защита от DNS-утечек: скройте свои следы в сети
• Вас приняли за VPN, хотя вы им не пользуетесь