31 августа 2026 года РБК со ссылкой на копию письма Минцифры сообщил: ведомство попросило российские хостинг-провайдеры, CDN и сервисы веб-защиты выделить IP-адреса ресурсов из «белого списка» в отдельные подсети. Формально это нужно, чтобы «оптимизировать» работу одобренных сайтов. По сути, из «разрешённых» сетей хотят вычистить посторонних: VPN, наркошопы и сайты интим-услуг, которые оказываются там не потому, что их туда внесли, а потому что делят адрес с легитимным сервисом.
Для владельца обычного сайта это не абстрактная регуляторика. Если вы сидите на общем IP, за анти-DDoS или за shared CDN, адрес могут переехать. Ниже, что именно попросили, почему так выходит технически и что проверить, пока провайдер не начал «окрашивать» сети.
Что именно попросило Минцифры 31 августа
По материалу РБК (автор Екатерина Шокурова, публикация 31 августа 2026, 00:00 мск) письмо разослали трём типам инфраструктуры:
- хостинг-провайдерам;
- CDN-провайдерам;
- сервисам веб-защиты (анти-DDoS, WAF, reverse-proxy).
В письме сказано, что выделенные подсети позволят «оптимизировать» сайты из перечня и «исключить возможность использования IP-адресов» из белого списка организациями, «не получившими соответствующее согласование». На момент подготовки материала отдельного публичного пресс-релиза Минцифры по этому письму не было: история опирается на копию обращения, с которой работал РБК.
Это просьба к рынку, а не опубликованный закон. Срока исполнения в открытых пересказах нет. Опрошенные изданием эксперты говорят, что технически идея реализуема, но «затратна» и «потребует времени»: нужно понять, какой адрес реально внесён в перечень, «окрасить» сети и перевести остальных клиентов на другие IP. Для конечных пользователей сдвиг обещают незаметным. Для тех, у кого на старый адрес завязаны DNS, SSL, вебхуки и allow-листы, он как раз заметен.
Почему в белый список попадают чужие сайты
«Белый список» Минцифры, с сентября 2025 года, это перечень социально значимых сервисов, которые должны открываться при ограничениях мобильного интернета. Операторы режут трафик по модели «всё закрыто, кроме разрешённого»: пропускают домены и IP из списка, остальное на мобильной сети не ходит. Проводной домашний интернет этим режимом официально не затрагивается.
Проблема не в домене Госуслуг или Ozon. Проблема в том, как устроена публикация сайта.
Сайт может слушать на собственном статическом адресе. Тогда в перечень логично отдать один хост в нотации CIDR /32. Так и рекомендуют облачные платформы: в документации Yandex Cloud прямо написано не передавать в Минцифры диапазоны, а указывать отдельные зарезервированные публичные адреса, закреплённые только за этим ресурсом.
Часто схема другая. Сайт стоит за анти-DDoS или CDN. Трафик пользователей приходит на чужие адреса провайдера защиты. Эти адреса общие: на одном IP или на одной /24 сидят десятки клиентов. Если в белый список попадает не один хост, а сеть, «разрешёнными» становятся и соседи. Собеседник РБК описывает это так: сервис «выходит в интернет» через чужие адреса, в перечень попадает целая сеть, а вместе с ней другие клиенты, среди которых могут быть запрещённые ресурсы и VPN.
Ещё одна дыра: клиент проходит проверку при подключении, а потом меняет содержимое. Сначала заявлен интернет-магазин, через месяц на том же IP крутится VPN или что-то из серой зоны. Хостер видит тот же контракт и тот же адрес. Фильтр оператора видит «белый» IP.
Именно поэтому письмо адресовано не только классическому хостингу, но и CDN с веб-защитой. Общий anycast, общий прокси, общий пул очистки, всё это увеличивает «пятно» адреса.
Это не первая попытка развести пулы
Первую версию перечня Минцифры представило 5 сентября 2025 года, затем расширяло его в ноябре, декабре, феврале 2026-го и 23 апреля 2026 года. Списки «большой четвёрки» операторов при этом расходятся между собой и с формулировками ведомства. Полного официального реестра IP в открытом виде нет.
В январе 2026 года портал «Код Дурова» писал, что Роскомнадзор уже прикрыл обход ограничений через VPN, которые арендовали серверы с «белыми» IP. По той версии, облачным провайдерам запретили сдавать такие адреса другим клиентам: пулы ресурсов из перечня не должны пересекаться с пулами «обычной» аренды. 24 января у части VPN-сервисов отвалились серверы именно по этой причине. Официального комментария РКН тогда не было.
3 августа 2026 года РБК отдельно писал о другой линии: мониторинг IP «легитимных» VPN у хостеров, сроки на разбор инцидента и риск признать провайдера недобросовестным. Письмо от 31 августа про отдельные подсети для белого списка лежит в той же логике, но бьёт уже не только по VPN, а по любой «паразитной» нагрузке на разрешённый адрес.
Зачем ведомству такая точность, видно по цифрам сети. По данным компании Vigo (разбор на Хабре), в июле 2026 года в Центральном федеральном округе без ограничений проходило в среднем только 30,5% пользовательских сессий в мобильных сетях. Количество подключений в режиме белого списка в Центральной России выросло с января примерно на 31%. Чем чаще «интернет» на смартфоне равен короткому перечню IP, тем дороже ошибка: один лишний /24 в списке даёт бесплатный канал всем, кто на нём сидит.
Что это значит для владельца сайта
Если ваш ресурс сам в перечне или вы туда целитесь, задача простая: один сервис, один (или несколько) статических адресов, без соседей. Shared hosting, общий IP виртуалки, «бесплатный» анти-DDoS на пуле провайдера, зарубежный CDN, всё это плохо стыкуется с моделью /32.
Если вас в перечне нет, расслабляться рано. Эксперты РБК как раз описывают сценарий: провайдер выделяет подсеть «только для белого списка», остальных клиентов этой сети переводит на другие адреса. Для вас это смена A-записи, перевыпуск сертификата, правки allow-листов у банков, платёжек, почтовых шлюзов и партнёрских API. Пользователь сайта «ничего не заметит», если DNS и TTL успеют разъехаться. Если не успеют, часть аудитории будет ходить на старый IP, пока кэш не протухнет.
Отдельный риск для тех, кто завязал инфраструктуру на Cloudflare, Akamai или другой зарубежный CDN. Даже при сервере в Москве такой вход часто не проходит критерии перечня. Российские CDN (NGENIX, CDNvideo, EdgeCenter, Selectel CDN, Yandex Cloud CDN) умеют выдавать выделенный адрес, но это отдельная опция, не «включил галочку в панели».
Как устроена нормальная схема под перечень
Рабочая схема, которую уже описывают облака, выглядит так.
- Публичный IP статический, зарезервирован за вами, с защитой от удаления.
- В заявку идут отдельные адреса /32, не «наш /24 целиком».
- На этом IP нет чужих клиентов, нет чужого VPN, нет «соседнего» магазина.
- Если сервису нельзя выдать собственный адрес (типичный пример, объектное хранилище), перед ним ставят L7-балансировщик с выделенным IP, и в перечень отдают уже его.
- Для CDN просят выделенную адресацию по всем точкам присутствия, а не общий anycast-пул.
Yandex Cloud прямо перечисляет, каким сущностям можно назначить индивидуальный публичный адрес: виртуальные машины, BareMetal, узлы Kubernetes, L7- и сетевые балансировщики, прокси Smart Web Security, CDN-ресурсы по обращению в поддержку. Остальные сервисы платформы сидят на служебных адресах, общих для многих клиентов. Это как раз та модель, которую письмо Минцифры пытается сломать на стороне хостеров.
Сам факт размещения в российском облаке в перечень не включает. Решение по каждому сервису принимает Минцифры. У хостера можно взять выделенный IP, но заявку подаёт владелец ресурса.
Что проверить на своём сервере
Сначала посмотрите, какой адрес реально видит клиент, не какой написан в панели «внутренний eth0».
curl -4 -s https://ifconfig.me; echo dig +short A example.ru
Если A-запись указывает не на ваш VPS, а на узел CDN или анти-DDoS, в белый список (и в чужой) попадает именно этот внешний адрес. Дальше смотрите, кому принадлежит сеть и насколько она широкая.
whois 203.0.113.10 dig +short -x 203.0.113.10
В whois важны поля CIDR, inetnum, netname и origin. Если ваш /32 лежит внутри чужой /24, а в перечень когда-то внесли эту /24, вы технически «белый» без заявки. И наоборот: если провайдер вырежет из этой /24 «чистую» подсеть под перечень, ваш адрес сдвинут.
Маску удобно прикинуть на калькуляторе сетевых масок. PTR и владельца блока можно быстро глянуть через whois-lookup и DNS lookup на сайте, без консоли.
Имеет смысл спросить у хостера три вещи, обычным тикетом, без драмы:
- адрес выделенный или из общего пула;
- планируют ли вынос клиентов белого списка в отдельную подсеть, и попадёте ли вы под смену IP;
- можно ли заранее зарезервировать статический /32 и зафиксировать его в DNS с небольшим TTL.
Перед любой сменой адреса опустите TTL у A/AAAA хотя бы за сутки. Иначе часть резолверов будет стучаться на старый IP ещё часы. После смены проверьте не только сайт в браузере, но и почту, вебхуки оплат, колбэки рекламных кабинетов и allow-листы, куда IP прописывали руками.
Где обычно ломается
Первое: «у нас и так российский хостинг». Хостинг российский, адрес общий. Для фильтра оператора важен IP, который видит ТСПУ, а не страна в оферте.
Второе: в заявку отправили /24 «на всякий случай». Облака уже предупреждают: диапазон могут не принять. Даже если когда-то такой вариант проходил, сейчас логика письма прямо против него.
Третье: сайт за Cloudflare, а в Минцифры отдали IP origin-сервера в Москве. Мобильный клиент ходит на anycast Cloudflare, не на origin. В перечень нужно то, что реально отвечает пользователю.
Четвёртое: несколько виртуалок, один NAT, один белый IP на всех проектах. Вынесли в «чистую» подсеть магазин из перечня, вместе с ним уехал тестовый стенд, почтовый релей и чужой бот.
Пятое: сертификат Let’s Encrypt и HSTS. Сменили IP, забыли, что часть клиентов ходит по старому A, пока TTL жив, и ловят чужой сертификат на том же виртуальном хосте провайдера.
Шестое: allow-листы. Банк, платёжка, Яндекс.Метрика, почтовый шлюз, партнёрский API. Старый IP внезапно «не наш». Это чинится заранее списком зависимостей, а не ночью после тикета хостера.
Как понять, что провайдер уже переехал
Признаки смены публикации без вашего тикета:
- A-запись в DNS панели хостера другая, чем неделю назад;
- curl на сайт отдаёт сертификат или заголовок чужого vhost;
- whois по новому адресу показывает другую подсеть или другой netname «whitelist» / «waf» / «cdn»;
- часть мобильных клиентов в регионах с ограничениями открывает сайт, часть нет: разные операторы держат разные срезы списка.
Проверка с сервера после заявленного переноса:
curl -4 -sI https://example.ru | head dig +short A example.ru ip -4 addr show
На что смотреть: новый публичный адрес совпадает с A-записью, на интерфейсе виртуалки он же (если нет отдельного прокси), TLS валидный, редиректы не уезжают на старый IP. Если перед сайтом балансировщик, проверяйте адрес балансировщика, не внутренний адрес бэкенда.
Не отключайте файрвол и не открывайте SSH в интернет «чтобы точно пустили». Смена публикации и дырявый периметр это разные задачи. Для рабочего сайта разумнее сначала согласовать окно с хостером, сохранить старую A-запись в комментарии тикета и откатить DNS, если новый адрес не отвечает.
Вывод
Минцифры не изобрело новый фильтр, а попросило убрать грязь из уже работающего. Белый список на мобильной сети режет интернет до набора IP. Пока одобренный сайт сидит в общей подсети с CDN и анти-DDoS, в этот набор неизбежно пролезают соседи, включая VPN и запрещённый контент.
Ответ рынка, который уже проговаривают крупные хостеры: отдельная подсеть только под перечень. Для админа это либо выделенный /32 и спокойный сон, либо внезапная смена адреса. Имеет смысл сейчас узнать, чей IP у сайта на самом деле, и не держать на нём ничего лишнего.
