Веб-разработка

IPv4 и IPv6: что нужно знать современным сайтам

Разбираем IPv4 и IPv6 для современных сайтов: DNS, dual-stack хостинг, производительность, влияние на SEO, тестирование и практику развертывания.

SeoNest Team2 мин чтения
Открыть содержание статьи

IPv4 и IPv6 для современных сайтов

IPv4 и IPv6 выполняют одну и ту же базовую задачу: позволяют пакетам передаваться между устройствами по IP-сетям. Главное различие в том, что IPv4 использует 32-битные адреса, а IPv6 — 128-битные и был разработан как преемник IPv4. Значительно большее адресное пространство решает долгосрочную проблему нехватки адресов, которая во многом определила развитие современной интернет-инфраструктуры. (rfc-editor.org)

Однако для современного сайта практический вопрос обычно звучит не как «IPv4 или IPv6?», а как «Могут ли пользователи надежно открыть сайт по обоим протоколам?» Для большинства публичных веб-проектов поддержка обоих протоколов — напрямую либо через CDN, reverse proxy или хостинг-платформу — остается наиболее безопасной стратегией перехода.

Краткий ответ

IPv4 по-прежнему широко используется, поэтому обычно не стоит отключать его на публичном сайте только потому, что доступен IPv6. IPv6 — долгосрочный преемник IPv4 и уже составляет значительную долю интернет-трафика: по текущим данным Cloudflare Radar, примерно 41% HTTP-запросов в глобальной сети Cloudflare используют IPv6, хотя этот показатель заметно различается в зависимости от сети и страны. (radar.cloudflare.com)

Для большинства сайтов практичным выбором остается dual-stack connectivity — доступность сайта одновременно по IPv4 и IPv6. В таком случае современные клиенты могут самостоятельно выбрать подходящий рабочий сетевой путь.

IPv4 и IPv6

ХарактеристикаIPv4IPv6
Размер адреса32 bits128 bits
Пример192.0.2.102001:db8::10
DNS-записьAAAAA
Доступность адресовСильно ограниченаЗначительно большее адресное пространство
BroadcastПоддерживаетсяЗаменен механизмами multicast
Поддержка сайтами сегодняНеобходима во многих средахСтановится все более важной
Типичное развертываниеIPv4 или dual-stackОбычно dual-stack для публичных сайтов

IPv6 — это не просто IPv4 с более длинными адресами. Спецификация также меняет некоторые аспекты обработки пакетов и упрощает структуру базового заголовка. IPv6 поддерживает unicast, multicast и anycast-адресацию и, в отличие от IPv4, не определяет broadcast-адреса. (rfc-editor.org)

Что меняется для сайта?

На уровне приложения меняется удивительно мало.

Ваш сайт по-прежнему может использовать:

  • HTTPS
  • HTTP/2 или HTTP/3
  • TLS
  • Nginx или Apache
  • Node.js, PHP, Python, Go или другой backend
  • CDN и reverse proxy
  • обычные доменные имена

Основные изменения происходят ниже, на уровне сетевого стека.

Для IPv4 DNS обычно возвращает запись A:

example.com.    A       192.0.2.10

Для IPv6 DNS использует запись AAAA:

example.com.    AAAA    2001:db8::10

Один hostname может публиковать обе записи. Документация Cloudflare по DNS также определяет записи A как сопоставление доменного имени с IPv4-адресом, а AAAA — с IPv6-адресом. (developers.cloudflare.com)

При этом URL не меняется:

https://example.com/

Браузер разрешает доменное имя и определяет, какой сетевой путь использовать.

Как работают dual-stack соединения

Распространенное заблуждение состоит в том, что браузер просто сначала пробует IPv6, а затем ждет его отказа, прежде чем перейти на IPv4.

Современные сетевые механизмы работают сложнее.

RFC 8305 определяет Happy Eyeballs Version 2 — подход для хостов, которым могут соответствовать несколько IPv4- и IPv6-адресов. Клиенты могут устанавливать соединения таким образом, чтобы уменьшить заметные для пользователя задержки, если одно из семейств адресов недоступно, работает некорректно или значительно хуже другого. (rfc-editor.org)

Концептуально это выглядит так:

Browser
   |
   +---- IPv6 ----\
   |               > Website
   +---- IPv4 ----/

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

Именно поэтому некорректно настроенный IPv6 может быть хуже, чем полное отсутствие IPv6: если инфраструктура объявляет доступность по IPv6, но фактически этот путь не работает, появляется дополнительный потенциально проблемный сетевой маршрут.

IPv6 быстрее?

Не обязательно.

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

  • маршрутизацию ISP
  • peering
  • топологию CDN
  • расположение сервера
  • packet loss
  • перегрузку сети
  • IPv4 NAT-инфраструктуру
  • качество внедрения IPv6

Happy Eyeballs существует в том числе потому, что IPv4- и IPv6-маршруты могут различаться по доступности и производительности. (rfc-editor.org)

Поэтому:

Поддержка IPv6 сама по себе не является оптимизацией производительности.

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

Улучшает ли IPv6 SEO?

Нет документированных оснований считать IPv6 самостоятельным преимуществом для ранжирования в поиске.

Опубликованные Google технические требования для Search сосредоточены на том, может ли Googlebot получить доступ к странице, возвращает ли сервер успешный HTTP-статус и содержит ли страница индексируемый контент. IPv6 не указан там как техническое требование. (developers.google.com)

Поэтому влияние на SEO здесь косвенное.

Если сетевая проблема делает сайт недоступным, нестабильным или медленным для пользователей либо поисковых роботов, такая инфраструктурная проблема может иметь значение. Google прямо указывает проблемы сервера и сети среди возможных причин ошибок crawling. (developers.google.com)

Поэтому полезный принцип для SEO звучит не так:

Включите IPv6, чтобы повысить позиции.

А так:

Обеспечьте надежную работу каждого объявленного сетевого пути.

INTERNAL LINK: How Google Crawling Works

IPv6-only сети

Существуют и сети, работающие только по IPv6.

Когда таким сетям необходимо обращаться к ресурсам, доступным только по IPv4, могут использоваться технологии трансляции, например NAT64 и DNS64. DNS64 способен синтезировать IPv6 DNS-ответы на основе IPv4-записей, чтобы IPv6-only клиенты могли подключаться через NAT64 gateway. (developers.cloudflare.com)

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

Это еще одна практическая причина делать современные публичные сервисы совместимыми с IPv6, сохраняя при этом поддержку IPv4 там, где она необходима.

Как безопасно включить IPv6

Не начинайте с добавления записи AAAA.

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

Internet
   ↓
DNS
   ↓
CDN / Load Balancer
   ↓
Firewall
   ↓
Reverse Proxy
   ↓
Application

Затем проверьте DNS:

dig A example.com
dig AAAA example.com

Отдельно протестируйте IPv4:

curl -4 https://example.com/

Затем IPv6:

curl -6 https://example.com/

Оба запроса должны возвращать ожидаемый ответ приложения.

Также проверьте мониторинг, firewall rules, rate limiting, IP allowlists, application logs, fraud detection и аналитические системы. Программное обеспечение, предполагающее, что любой IP-адрес клиента выглядит как 192.0.2.1, может работать некорректно при получении адреса вида:

2001:db8:85a3::8a2e:370:7334

Распространенные ошибки

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

Еще одна ошибка — считать NAT механизмом безопасности. Правила firewall и контроль доступности должны настраиваться осознанно независимо от используемой версии IP.

Наконец, не отключайте IPv4 только ради того, чтобы инфраструктура выглядела «современной». Распространение IPv6 значительно, но переход еще не завершен. Текущие глобальные измерения Cloudflare по-прежнему показывают существенную долю трафика по IPv4. (radar.cloudflare.com)

Рекомендация SeoNest

Для обычного публичного сайта в 2026 году предпочтительна проверенная dual-stack доступность, если ваша хостинг-архитектура надежно ее поддерживает.

Используйте IPv4 и IPv6 одновременно либо позвольте подходящей CDN или edge-платформе предоставлять пользователям оба протокола. Например, Cloudflare по умолчанию включает IPv6 compatibility для проксируемых доменов и может объявлять IPv6-доступность одновременно с IPv4. (developers.cloudflare.com)

Что еще важнее, относитесь к IPv6 как к полноценному production-маршруту: мониторьте его, тестируйте при развертываниях, учитывайте в правилах firewall и проверяйте доступность из внешних сетей.

Не внедряйте IPv6 только для того, чтобы поставить галочку.

FAQ

IPv4 уже устарел?

Нет. IPv4 по-прежнему широко используется, хотя ограничения его адресного пространства стали одной из причин разработки и распространения IPv6. Например, ARIN до сих пор использует очередь ожидания для ограниченного количества возвращаемого IPv4-адресного пространства. (arin.net)

Каждый сайт должен поддерживать IPv6?

Поддержка IPv6 становится все полезнее, особенно для инфраструктуры, рассчитанной на долгосрочную эксплуатацию. Но корректно работающий сайт только по IPv4 лучше, чем неправильно настроенный IPv6.

Могут ли IPv4 и IPv6 работать одновременно?

Да. Такой подход обычно называется dual-stack networking и является распространенной моделью перехода.

Нужны ли отдельные домены?

Нет. Один hostname может одновременно иметь DNS-записи A и AAAA.

Улучшит ли IPv6 Core Web Vitals?

Не автоматически. IPv6 может использовать другой сетевой маршрут, но итоговая задержка зависит от конкретного ISP, routing, peering, CDN и серверного пути.

Итог

IPv6 — это не новая версия вашего сайта. Это еще один способ доставки трафика к нему.

IPv4 по-прежнему важен, а IPv6 уже слишком широко распространен, чтобы считать его экспериментальной технологией. Поэтому практичная архитектура современного сайта обычно не сводится к выбору одного из двух протоколов.

Поддерживайте оба там, где это возможно, объявляйте только действительно рабочие сетевые пути и измеряйте IPv4 и IPv6 как отдельные маршруты.

Sources

  1. IETF / RFC Editor — RFC 8200: Internet Protocol, Version 6 (IPv6) Specification, July 2017. RFC 8200
  2. IETF / RFC Editor — RFC 791: Internet Protocol, September 1981. RFC 791
  3. IETF / RFC Editor — RFC 4291: IP Version 6 Addressing Architecture, February 2006. RFC 4291
  4. IETF / RFC Editor — RFC 8305: Happy Eyeballs Version 2, December 2017. RFC 8305
  5. Google Search Central — Google Search Technical Requirements. Google Search technical requirements
  6. Google Search Central — How Google Search Works. How Google Search works
  7. Cloudflare — IPv6 Compatibility, updated August 25, 2026. Cloudflare IPv6 compatibility
  8. Cloudflare — DNS Record Types, updated June 2, 2026. Cloudflare DNS record types
  9. Cloudflare Radar — Worldwide Adoption & Usage, accessed September 20, 2026. Cloudflare Radar
  10. ARIN — IPv4 Waiting List Distribution, July 2, 2026. ARIN IPv4 Waiting List Distribution

SEONEST

Нужна более сильная техническая основа?

Мы создаём production-ready сайты, где SEO, скорость и чистая разработка заложены в архитектуру с самого начала.

Обсудить проект