Как проверить, заблокирован ли сайт РКН

Сайт открывается у администратора через зарубежный VPN, но не открывается у пользователей из России. В логах сервера пусто, нагрузка нормальная, DNS вроде бы отвечает. В такой ситуации одна из первых гипотез — ограничение доступа со стороны российских операторов связи по реестрам Роскомнадзора.

Проверка на блокировку нужна не только владельцам спорных ресурсов. Под ограничение может попасть конкретный URL, домен, поддомен, IP-адрес или соседний сайт на том же адресе. Иногда проблема выглядит как обычный сетевой сбой: таймаут, сброс соединения, странная DNS-ошибка или заглушка провайдера.

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

Что значит блокировка сайта Роскомнадзором

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

Блокировка не всегда выглядит одинаково. Один оператор может показывать страницу-заглушку, другой — возвращать DNS-ответ на свой IP, третий — сбрасывать TCP-соединение или фильтровать HTTPS по SNI. Поэтому один и тот же домен может:

• открываться из одной сети и не открываться из другой;
• работать по мобильному интернету, но не работать у домашнего провайдера;
• открываться из-за рубежа, но не открываться из России;
• отдавать разные ошибки в браузерах: ERR_CONNECTION_TIMED_OUT, ERR_CONNECTION_RESET, DNS_PROBE_FINISHED_NXDOMAIN, ERR_SSL_PROTOCOL_ERROR.

С технической точки зрения ограничение может применяться к разным объектам.

1) URL — блокируется конкретная страница, например https://example.com/page. Для HTTP это может работать точечно, для HTTPS точная фильтрация сложнее из-за шифрования.

2) Домен или поддомен — блокируется example.com или sub.example.com. Это частый сценарий, если в реестр внесён не отдельный материал, а ресурс целиком.

3) IP-адрес — ограничение применяется к адресу сервера. В этом случае могут пострадать все сайты, которые используют тот же IP, особенно на виртуальном хостинге, прокси или CDN.

4) Сетевой признак — оператор может фильтровать по комбинации домена, IP, SNI, HTTP-заголовков и других признаков. Из-за этого диагностика через один инструмент часто даёт неполную картину.

Если сайт недоступен, не стоит сразу считать причиной блокировку. Похожую картину дают проблемы DNS, истёкший SSL-сертификат, упавший Nginx, ошибки на стороне CDN, фаервол, DDoS-защита или сбой у конкретного провайдера. Общий чеклист разборов есть в статье «Не открывается сайт», а здесь сфокусируемся именно на проверке по линии РКН.

Быстрая проверка через официальный реестр

Первый шаг — открыть официальный сервис Роскомнадзора, который проверяет ограничение доступа к сайтам и страницам. В форме укажите домен, URL или IP-адрес — лучше проверить не только главную страницу, а несколько вариантов сразу.

1) Домен без протокола — example.com. Так можно понять, есть ли ограничение на домен целиком.

2) Полный URL — https://example.com/path/page. Если пользователи жалуются на конкретный раздел, проверяйте именно его.

3) Поддомены — www.example.com, api.example.com, cdn.example.com, blog.example.com. Поддомены могут попадать в реестр отдельно.

4) IP-адрес — текущий A-адрес домена. Это важно для сайтов на виртуальном хостинге, выделенном сервере, балансировщике или CDN.

Если сервис показывает, что ресурс есть в реестре, дальше нужно смотреть, какой объект указан: домен, страница или IP. Это определяет дальнейшие действия — блокировка конкретной страницы обычно решается иначе, чем блокировка IP, на котором размещены десятки проектов.

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

Проверьте доступность из России и из других стран

Ключевой признак блокировки — географическая асимметрия: сайт доступен из-за рубежа, но недоступен из российских сетей. Однако проверять нужно не с одной точки, а с нескольких.

1) Россия, разные операторы — домашний провайдер, мобильный интернет, сервер в российском дата-центре. Если проблема воспроизводится у нескольких независимых операторов, вероятность блокировки выше.

2) Зарубежные точки — сервер в Европе, США, Азии или любой внешний сервис проверки. Если из-за рубежа сайт стабильно открывается, сервер и приложение, скорее всего, живы.

3) Разные типы запросов — проверяйте не только браузер, но и HTTP, HTTPS, DNS, TCP-подключение к 443 и 80. Браузер скрывает детали и часто показывает обобщённую ошибку.

4) Несколько URL — главная страница, проблемный раздел, статические файлы, API-эндпоинт. Иногда не работает только часть ресурса.

Для ручной проверки можно использовать удалённые серверы, VPN, облачные машины в разных регионах или сервисы синтетического мониторинга. Подробнее о подходе к географической диагностике — в материале «Проверка сайта по странам».

Мониторинг доступности здесь полезен тем, что фиксирует момент начала проблемы. Например, Statuser проверяет сайт с заданным интервалом и присылает уведомление о сбое. Если в истории видно, что падение наблюдалось только из российских точек, это хороший сигнал для дальнейшей проверки по реестрам и у провайдеров.

Техническая диагностика: DNS, IP, HTTP и TLS

После проверки в реестре нужно понять, на каком уровне рвётся доступ. Это помогает отличить блокировку от обычного сбоя инфраструктуры.

1) Узнайте текущие IP-адреса домена — начните с DNS. Команда dig покажет, куда должен резолвиться домен:

dig +short example.com A

Для IPv6:

dig +short example.com AAAA

Проверьте ответы разных резолверов:

dig @8.8.8.8 example.com A

dig @1.1.1.1 example.com A

dig @77.88.8.8 example.com A

Если у российского резолвера возвращается подозрительный IP, пустой ответ или адрес заглушки, а у зарубежных резолверов нормальный IP, проблема может быть на уровне DNS-фильтрации. Подробно про DNS-диагностику читайте в статье «Утилита dig. Как проверить DNS-записи и отладить домен».

2) Проверьте HTTP-ответ — используйте curl, чтобы увидеть статус, редиректы и заголовки:

curl -I -L --connect-timeout 10 https://example.com/

Если из зарубежной сети приходит 200, 301, 302 или ожидаемый 403, а из российской сети запрос зависает до таймаута, это сильный признак сетевой фильтрации. Если же везде приходит 502, 503 или 504, скорее всего, причина в сервере, прокси или апстриме.

Полезно проверить и HTTP без TLS:

curl -I --connect-timeout 10 http://example.com/

Иногда на http:// провайдер показывает заглушку, а https:// просто обрывается — содержимое HTTPS зашифровано, и оператор не всегда может вставить понятную страницу блокировки.

Если нужно больше практики по curl, есть отдельный материал «Что такое curl и как им пользоваться».

3) Проверьте соединение с конкретным IP — если домен резолвится в несколько адресов, проверьте каждый. Для HTTPS удобно использовать --resolve, чтобы принудительно связать домен с IP:

curl -I --resolve example.com:443:203.0.113.10 https://example.com/

Так можно понять, блокируется ли конкретный адрес или проблема в DNS. Если один IP работает, а другой нет, смотрите балансировщик, CDN, маршрутизацию и возможное попадание адреса в реестр.

4) Посмотрите трассировку — mtr или WinMTR помогут увидеть, где теряются пакеты:

mtr example.com

Трассировка не всегда показывает фильтрацию: ICMP может быть ограничен, а маршрутизаторы могут не отвечать. Но если из России маршрут стабильно обрывается в сети оператора, а из другой страны доходит до хостинга, это полезный артефакт для обращения в поддержку. Как читать такие выводы, разобрано в статье «Как читать трассировку в mtr и WinMTR».

5) Проверьте TLS и SNI — при HTTPS важен домен, который клиент передаёт в SNI во время TLS-рукопожатия. Если соединение к IP устанавливается, но с доменным именем обрывается, фильтрация может быть связана именно с доменом. Также не исключайте обычные TLS-проблемы: неправильный сертификат, устаревшие протоколы, ошибка в CDN или прокси.

Как выглядят типичные признаки блокировки

У блокировки нет одного универсального симптома. Но есть набор признаков, которые часто встречаются в реальных инцидентах.

1) Заглушка провайдера — самый очевидный случай. Пользователь видит страницу с сообщением об ограничении доступа, обычно со ссылкой на закон или требование уполномоченного органа. Для владельца сайта это почти прямое подтверждение, но всё равно стоит проверить официальный реестр.

2) Таймаут соединения — браузер долго грузит страницу и показывает ERR_CONNECTION_TIMED_OUT. Сервер при этом не видит запросов в access-логах. Если из других стран запросы доходят, а из России нет, причина может быть в фильтрации на пути. Но таймаут также бывает из-за фаервола, маршрутизации, DDoS-защиты и проблем у хостинга.

3) Сброс соединения — ошибка ERR_CONNECTION_RESET или похожая. Соединение начинается, но затем резко закрывается. Такое бывает при DPI-фильтрации, но также встречается при неправильной настройке прокси, WAF или TLS.

4) Разные DNS-ответы — домен резолвится в разные IP в зависимости от резолвера. Если российские резолверы отдают не тот адрес или не отдают ничего, а публичные зарубежные отвечают корректно, проверяйте DNS-фильтрацию и настройки зоны. Не забывайте про кэш: старые записи могут жить до истечения TTL.

5) В логах сервера пусто — если пользователи массово жалуются, а в access.log нет их запросов, проблема находится до вашего веб-сервера: DNS, маршрут, фильтрация, CDN, балансировщик или фаервол.

6) Сайт работает по IP, но не по домену — признак доменной фильтрации, DNS-проблемы или ошибки TLS/SNI. Для HTTPS проверка «по IP в браузере» часто некорректна: сертификат выдан на домен, а не на IP. Лучше использовать curl --resolve.

7) Не работает только часть URL — возможна точечная блокировка конкретной страницы. Но проверьте и приложение: редиректы, авторизацию, рейт-лимиты, ошибки 403 и 404.

Главная ошибка — сделать вывод по одному признаку. Таймаут из одной сети не доказывает блокировку. Нужны минимум три источника: официальный реестр, проверки из разных сетей и технические данные по DNS/HTTP/TLS.

Если сайта нет в реестре, но из России он не открывается

Такое бывает часто. Отсутствие домена в публичной проверке не означает, что причина точно не связана с фильтрацией. Но и зацикливаться на РКН не стоит: многие инциденты выглядят похожим образом.

1) Блокировка соседнего IP — ваш домен не внесён в реестр, но IP мог использоваться другим ресурсом. Это особенно вероятно на дешёвом виртуальном хостинге, shared-инфраструктуре, прокси или при переиспользовании адресов. Проверьте IP в официальном сервисе и уточните у хостера историю адреса.

2) Ошибка или задержка у оператора — провайдер мог некорректно применить фильтр, не обновить список или продолжать блокировать адрес после изменений. Сравнение нескольких российских операторов поможет понять масштаб.

3) Корпоративная или локальная фильтрация — пользователи могут сидеть за офисным прокси, школьным фильтром, родительским контролем, антивирусом или DNS-сервисом с дополнительными правилами. Это не блокировка РКН, но для пользователя результат тот же: сайт не открывается.

4) Проблемы DNSSEC, CNAME и CDN — сложные цепочки CNAME, гео-DNS, DNSSEC-ошибки и разные ответы по регионам могут создавать впечатление блокировки. Проверьте авторитативные DNS-серверы и ответы из разных сетей.

5) Фаервол или WAF блокирует российские адреса — иногда владелец сайта сам ограничивает страны в CDN, WAF, Nginx, iptables или панели хостинга. Проверьте правила доступа, geo-блокировки, списки ASN и недавние изменения.

6) Проблема на стороне CDN — CDN может неправильно маршрутизировать российский трафик, отдавать ошибку на edge-узле или конфликтовать с origin-сервером. Если сайт использует CDN, проверяйте отдельно домен CDN, origin, правила firewall и события безопасности.

В таких случаях помогает последовательная диагностика доступности: DNS → TCP → TLS → HTTP → приложение. Базовый подход описан в статье «Инструкции», а для регулярного контроля полезно понимать, что такое uptime monitoring.

Что делать, если сайт действительно заблокирован

Если проверка показала, что домен, URL или IP находится в реестре, действия зависят от того, что именно заблокировано и почему.

1) Зафиксируйте факты — сохраните результат официальной проверки, дату, проверяемый домен, URL, IP, скриншоты заглушек, выводы dig, curl, mtr, примеры жалоб пользователей. Это пригодится для общения с хостером, провайдерами, юристами и поддержкой сервисов.

2) Определите объект блокировки — домен, поддомен, страница или IP. Если заблокирован конкретный URL, не нужно сразу переносить весь сайт. Если заблокирован IP, возможно, достаточно получить другой адрес у хостера, но сначала нужно убедиться, что ваш домен не фигурирует отдельно.

3) Выясните основание — официальный реестр может показывать сведения об органе или решении, на основании которого ограничен доступ. Дальше нужно разбираться с содержимым, жалобой, судебным актом или иной причиной; в спорных случаях стоит привлекать профильного юриста.

4) Уберите проблемный материал, если причина в контенте — если ограничение связано с конкретной страницей, удаление или изменение материала может быть первым шагом. Но само по себе удаление не всегда автоматически снимает блокировку: может потребоваться заявление, проверка или ожидание обновления реестров.

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

6) Проверьте CDN и прокси — при использовании CDN убедитесь, что блокировка не связана с общим адресом edge-узла или неправильными DNS-записями. Менять CDN вслепую не стоит: если в реестре домен, смена инфраструктуры не поможет.

7) Настройте наблюдение после исправлений — после удаления материала, смены IP или обращения в поддержку важно видеть, когда доступ восстановился у пользователей из России. Регулярные проверки с уведомлениями позволяют не ждать ручных жалоб.

Не стоит маскировать проблему техническими обходами, не разобравшись с основанием блокировки. Правильная цель — понять причину, устранить её и добиться восстановления доступа официальным путём.

Как встроить проверку РКН в диагностику инцидентов

Блокировка РКН — одна из возможных причин недоступности, а не отдельная вселенная. Её удобно включить в стандартный runbook для инцидентов.

1) Сначала подтвердите масштаб — один пользователь, один провайдер, один регион или массовая проблема. Если жалоба единичная, начните с локального DNS, браузера, корпоративной сети и провайдера пользователя.

2) Проверьте внешний мониторинг — есть ли падение по HTTP-проверкам, из каких регионов, когда началось, какие статусы возвращались. Например, Statuser способен показать, с какого момента и из каких регионов начались сбои, — история проверок помогает восстановить хронологию.

3) Сравните Россию и зарубежные точки — если проблема только из России, переходите к официальному реестру, проверке IP и диагностике DNS/TLS.

4) Проверьте инфраструктурные изменения — деплой, смена DNS, выпуск сертификата, перенос на новый IP, включение WAF, изменение правил CDN, обновление фаервола. Совпадение по времени часто объясняет больше, чем реестр.

5) Соберите артефакты до исправлений — не перезапускайте всё подряд, пока не сняли минимальные данные. После перезапуска часть симптомов исчезнет, и будет сложнее понять, была ли это блокировка, сбой сети или ошибка приложения.

6) Заведите отдельную пометку в постмортеме — если причина оказалась в реестре, зафиксируйте объект блокировки, провайдеров, время обнаружения, время восстановления, действия команды и контакты, через которые решали вопрос.

Такой подход снижает риск ложных выводов: команда не тратит часы на перезапуск Nginx, когда запросы вообще не доходят до сервера, и не обвиняет РКН, когда проблема была в неправильной DNS-записи.

Мини-чеклист проверки

Если нужно быстро понять, заблокирован ли сайт РКН, пройдите короткий список.

1) Проверьте домен в официальном сервисе РКН — example.com, www.example.com, проблемный поддомен.

2) Проверьте полный URL — особенно если жалобы относятся к конкретной странице.

3) Узнайте IP через DNS — dig +short example.com A и проверьте каждый IP в реестре.

4) Сравните доступность из России и из-за рубежа — минимум две российские сети и одна зарубежная точка.

5) Проверьте HTTP и HTTPS через curl — статусы, редиректы, таймауты, сбросы.

6) Посмотрите DNS-ответы разных резолверов — публичные, провайдерские, авторитативные.

7) Проверьте логи сервера — доходят ли запросы от российских пользователей.

8) Исключите свои настройки — CDN, WAF, фаервол, geo-блокировки, свежие деплои, SSL.

9) Сохраните доказательства — скриншоты, выводы команд, время, провайдеры, IP.

10) Если блокировка подтверждена — выясните основание и объект — страница, домен или IP; от этого зависит план восстановления.

FAQ

Как проверить сайт на блокировку РКН?
Используйте официальный сервис проверки Роскомнадзора: проверьте домен, полный URL, поддомены и IP-адрес. Затем сравните доступность из российских и зарубежных сетей.

Если сайта нет в реестре, значит блокировки нет?
Не всегда. Может быть заблокирован IP, поддомен, конкретный URL, соседний ресурс на общем адресе или фильтрация у отдельного оператора. Также возможны обычные DNS- и сетевые проблемы.

Почему сайт открывается через VPN, но не открывается без него?
Это может быть признаком ограничения доступа из России, но не доказательством. Проверьте официальный реестр, DNS-ответы, curl из разных сетей и логи сервера.

Что делать при блокировке IP?
Проверьте, не внесён ли отдельно домен. Затем обратитесь к хостеру, уточните причину, попросите чистый IP при необходимости и настройте мониторинг, чтобы отследить восстановление доступа.