Проверка IP на блокировку РКН: руководство для администраторов с примерами кода

Проверить IP в реестре РКН можно за пару секунд: реестр Роскомнадзора — официальный и единственный достоверный источник данных о заблокированных ресурсах, и по IP-адресу в нём видно, внесён ли адрес в список, с какой датой решения и по чьему решению. Для разовой проверки одного адреса достаточно веб-сервиса, для регулярного контроля десятков и сотен адресов — прямого запроса к API РКН или скрипта на Python с отчётом в CSV. Ниже — три способа проверки, готовые примеры кода, массовая проверка подсетей и мониторинг блокировок в Prometheus/Grafana и Zabbix.

Блокировка IP-адреса Роскомнадзором делает все сервисы на этом адресе недоступными для пользователей из России: в 2026 году практика применяется к социальным сетям, игровым платформам и мессенджерам — как в случаях с Roblox, WhatsApp и Untappd. Проверка IP в реестре РКН — обязательная процедура диагностики и проактивного мониторинга для системного администратора и DevOps-инженера.

Как проверить IP в реестре РКН: три способа

Веб-сервис (например, 2whois.ru) — разовая проверка одного адреса за секунды.
Прямой запрос к API РКН — программная проверка IP через curl или Python.
Скрипт для массовой проверки диапазонов и подсетей IP с выгрузкой отчета в CSV.

Ниже каждый способ разобран по шагам: от разового запроса до интеграции в системы мониторинга.

Что вы узнаете:

Как быстро проверить один IP-адрес через веб-сервисы и API РКН.
Как работает скрипт проверки IP на Python: массовая проверка 1000+ адресов из файла и отчет в CSV.
Как настроить мониторинг блокировок РКН: exporter для Prometheus, панель в Grafana и внешний скрипт для Zabbix.
Какие архитектурные и административные меры снижают риск попадания в реестр.

Содержание

Как работает реестр РКН и чем отличаются блокировки домена, IP и подсети
Проверка одного IP через веб-сервис: что показывает результат
Прямой запрос к API РКН: curl и Python
Скрипт массовой проверки диапазонов IP на Python
Мониторинг блокировок: Prometheus, Grafana, Zabbix
Тонкости: ложные срабатывания и задержки обновления реестра
Проактивные меры и чек-лист администратора
Частые вопросы

Почему блокировка IP — критический риск для инфраструктуры в 2026 году

В 2025-2026 годах Роскомнадзор продолжил блокировать не только отдельные сайты, но и целые онлайн-сервисы по их IP-адресам. Например, блокировка Roblox в декабре 2025 года или Untappd в апреле 2026 затрагивала миллионы пользователей. Для бизнеса, чьи сервисы размещены на заблокированном IP, последствия — полная потеря клиентов из РФ, удар по репутации и прямые финансовые потери из-за простоя.

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

Администратор инфраструктуры несет ответственность за доступность сервисов, даже если контент, приведший к блокировке, разместил клиент на виртуальном хостинге или сосед по серверу в дата-центре. Риск блокировки целой подсети, особенно маски /24, создает угрозу для десятков независимых серверов. Поэтому диагностика по IP, а не только по доменному имени, становится первым и критически важным шагом.

Основной источник истины: как работает реестр РКН и что в нем искать

Официальным и единственным достоверным источником информации о заблокированных ресурсах является реестр Роскомнадзора. Это единая база данных, куда вносятся решения о блокировке. Записи содержат идентификатор ресурса: это может быть доменное имя или IP-адрес. Ключевой момент для администратора — в реестре явно указывается, найден ли ресурс по IP.

Все сторонние сервисы проверки, такие как 2whois.ru, работают как фронтенд к этому реестру, запрашивая данные через публичный API. Понимание структуры реестра позволяет корректно интерпретировать результаты и выбирать методы автоматизации.

Блокировка домена, IP или целой подсети: в чем ключевая разница для диагностики

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

Блокировка домена. В реестре указано только доменное имя (например, example.com). IP-адрес сервера при этом может быть чистым. Проблема касается исключительно владельца домена и решается сменой DNS-записей или переносом сайта.
Блокировка конкретного IP-адреса. В запись внесен IP-адрес (например, 192.0.2.1). Все сервисы, работающие на этом адресе (веб-сайты, API, базы данных), становятся недоступными из РФ. Решение — запрос нового IP у хостинг-провайдера или миграция сервисов.
Блокировка подсети. Чаще всего блокируется диапазон адресов, например, 203.0.113.0/24. Это массовая проблема, которая затрагивает множество независимых серверов и клиентов одного провайдера. В реестре может быть указан один IP из диапазона. Диагностировать это можно, проверив соседние адреса из той же подсети.

Практическая рекомендация: при любой проблеме доступности первым делом проверяйте IP-адрес сервера, а не только доменное имя.

Практические методы проверки: от разового запроса до автоматизации

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

Метод проверки	Сценарий использования	Плюсы	Минусы
Веб-сервисы (2whois.ru)	Разовая проверка 1-2 IP	Мгновенно, не требует кода	Ручной ввод, не для массовых проверок
Прямой запрос к API РКН	Основа для скриптов	Прямой доступ к данным, программируемость	Требует навыков работы с API
Скрипты (Bash/Python)	Массовая проверка диапазонов	Автоматизация, отчеты, интеграция	Необходимо написание и поддержка кода
Интеграция в мониторинг	Непрерывный проактивный контроль	Уведомления до сбоя, дашборды	Сложность первоначальной настройки

Быстрая диагностика: проверка одного IP через веб-сервисы

Для срочной ситуации, когда нужно проверить один адрес, используйте специализированные сервисы. Откройте сайт, например, 2whois.ru, найдите форму проверки по реестру РКН. В поле для ввода данных укажите проверяемый IP-адрес и отправьте запрос.

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

Важный нюанс: агрегаторы подтягивают данные из реестра с задержкой — от минут до нескольких часов. Если проверка критична для решения о миграции, перепроверьте адрес прямым запросом к API РКН.

Прямой запрос к API РКН: проверка IP через curl и Python

Публичный API РКН — это программный интерфейс для автоматизированных запросов. Он позволяет интегрировать проверку в скрипты и системы мониторинга. Пример запроса к условному эндпоинту через curl:

curl -X GET "https://api.rkn.gov.ru/v1/check?ip=192.0.2.1"

Ответ приходит в формате JSON. Ключевые поля для анализа:

blocked: true или false — статус блокировки.
ip: проверяемый адрес.
decisionDate: дата решения о блокировке.
org: организация, вынесшая решение.

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

На Python базовую проверку можно выполнить с помощью библиотеки requests:

import requests

ip_to_check = "192.0.2.1"
api_url = f"https://api.rkn.gov.ru/v1/check?ip={ip_to_check}"

response = requests.get(api_url)
data = response.json()

if data.get("blocked"):
    print(f"IP {ip_to_check} заблокирован. Дата решения: {data.get('decisionDate')}")
else:
    print(f"IP {ip_to_check} не найден в реестре.")

Скрипт для массовой проверки диапазонов IP на Python

Для проверки списка адресов используйте готовый скрипт. Ниже пример на Python, который читает IP из файла ip_list.txt, выполняет асинхронные запросы для скорости и сохраняет отчет в CSV.

import aiohttp
import asyncio
import csv
from datetime import datetime

async def check_ip(session, ip):
    api_url = f"https://api.rkn.gov.ru/v1/check?ip={ip}"
    try:
        async with session.get(api_url, timeout=10) as response:
            data = await response.json()
            return {
                "ip": ip,
                "blocked": data.get("blocked", False),
                "date": data.get("decisionDate", "N/A"),
                "error": None
            }
    except Exception as e:
        return {"ip": ip, "blocked": False, "date": "N/A", "error": str(e)}

async def main():
    with open("ip_list.txt", "r") as f:
        ips = [line.strip() for line in f if line.strip()]

    async with aiohttp.ClientSession() as session:
        tasks = [check_ip(session, ip) for ip in ips]
        results = await asyncio.gather(*tasks)

    with open(f"rkn_report_{datetime.now().date()}.csv", "w", newline='') as csvfile:
        fieldnames = ["ip", "blocked", "date", "error"]
        writer = csv.DictWriter(csvfile, fieldnames=fieldnames)
        writer.writeheader()
        writer.writerows(results)

    print(f"Проверено {len(results)} IP. Отчет сохранен.")

if __name__ == "__main__":
    asyncio.run(main())

Скрипт обрабатывает таймауты и ошибки сети, что важно для устойчивой работы. Альтернатива на Bash с curl и jq подходит для небольших списков.

Мониторинг блокировок РКН: exporter для Prometheus и скрипт для Zabbix

Для проактивного контроля интегрируйте проверку в существующий мониторинг. Концепция для Prometheus: создать custom exporter, который периодически опрашивает API РКН по заданному списку IP и выдает метрику rkn_block_status{ip="192.0.2.1"} со значением 0 (чистый) или 1 (заблокирован).

В Grafana настройте дашборд с панелью, которая отображает все IP с метрикой 1. Настройте алерт-правило в Prometheus Alertmanager для отправки уведомления в Telegram или Slack при появлении заблокированного адреса.

Для Zabbix создайте внешний скрипт, который возвращает 0 или 1 для каждого хоста, и настройте триггер. Это позволяет получать оповещения в той же системе, где мониторится доступность сервисов и нагрузка. Такой подход сокращает время реакции с часов до минут.

Если держать отдельный exporter не хочется, подойдёт облегчённый вариант — периодический скрипт с проверками и алертами: примеры собраны в материале про скрипты мониторинга и проверки состояния серверов.

Автоматизация аудита безопасности — ключевой навык. В нашем руководстве по аудиту безопасности для DevOps вы найдете методики и инструменты для интеграции проверок в CI/CD.

Тонкости и подводные камни: как избежать ложных срабатываний

Данные в реестре РКН и сторонних сервисах обновляются не мгновенно. Официальный API может отставать на несколько минут после вынесения решения, а агрегаторы — на часы. Это основная причина ложных отрицательных результатов: IP уже заблокирован, но в API еще нет записи.

Ложные положительные срабатывания чаще связаны не с реестром, а с инфраструктурой:

Кэширование DNS. Провайдеры пользователей могут долго кэшировать старые A-записи, указывающие на заблокированный IP, даже после смены DNS.
Блокировка на уровне провайдера. Некоторые интернет-операторы могут применять собственные фильтры, не связанные с реестром РКН.
Проблемы с GEOIP. Сервисы, определяющие географию по IP, могут ошибочно относить адрес к заблокированному диапазону.

Рекомендация для критически важных проверок: используйте два независимых источника, например, прямой запрос к API РКН и проверку через доверенный сторонний сервис. Это повышает достоверность результата.

Отличить блокировку от обычного всплеска ошибок помогает анализ логов: разбор адресов из auth.log и access.log описан в статье как выгрузить и проанализировать заблокированные IP из auth.log, nginx access.log и journalctl.

Проактивные меры: что делать, чтобы минимизировать риски блокировки

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

Архитектурные меры. Избегайте shared-хостинга, где один IP используется сотнями клиентов. Риск блокировки из-за действий соседа слишком высок. Используйте выделенные IP-адреса или небольшие подсети (/29, /28) для критичных сервисов. Это изолирует вашу инфраструктуру.
Административные меры. Если вы предоставляете хостинг клиентам, внедрите четкие правила пользования, запрещающие размещение запрещенного контента. Настройте мониторинг исходящего трафика на сигнатуры известных угроз. Систематизация знаний помогает быстро реагировать. Внедрите базу знаний IT для документирования инцидентов и процедур.
Финансовый аспект. Рассчитайте стоимость одного часа простоя ваших сервисов. Сравните ее со стоимостью выделенных IP и внедрения системы автоматического мониторинга реестра РКН. Инвестиции в инфраструктуру обычно окупаются после предотвращения первого серьезного инцидента.

Итоговый чек-лист для администратора:

Внедрить скрипт массовой проверки IP и запускать его по расписанию: еженедельно, а также после каждого релиза и миграции на новые адреса.
Интегрировать проверку в систему мониторинга (Prometheus, Zabbix) для алертинга.
Перевести критичные сервисы с shared-хостинга на выделенные IP или VPS.
Хранить CSV-отчёты проверок — они пригодятся для аудита и разбора инцидентов, когда нужно доказать, когда адрес был чистым.
Документировать процедуру реагирования на блокировку в базе знаний команды.
Регулярно проводить комплексный аудит инфраструктуры. Практический план аудита безопасности поможет систематизировать этот процесс.

Диагностика сетевых проблем — смежная область. Если после проверки РКН проблема доступности остается, изучите руководство по диагностике Custom Resources в Kubernetes или методы анализа логов для поиска корневых причин.

Частые вопросы о проверке IP в реестре РКН

Как часто обновляется реестр РКН после решения о блокировке?

Запись обычно появляется в реестре в течение нескольких минут, но публичный API и сторонние агрегаторы могут отдавать данные с задержкой от минут до нескольких часов. Для критичных сервисов проверяйте два независимых источника одновременно.

Чем отличается проверка по IP от проверки по домену?

Это разные записи реестра. При блокировке домена IP-адрес сервера может оставаться чистым — тогда достаточно сменить DNS или перенести сайт. При блокировке IP недоступными становятся все сервисы на этом адресе, независимо от доменов, поэтому проверять нужно именно IP, а при подозрении на блокировку подсети — ещё и соседние адреса из диапазона.

Можно ли проверить сразу целую подсеть, а не отдельные адреса?

Да. Скрипт массовой проверки принимает список адресов из файла, поэтому в ip_list.txt можно заранее выгрузить все адреса диапазона — например, /24. Так вы поймете, заблокирован один адрес или вся подсеть.

Что делать, если адрес уже внесен в реестр?

Сначала уточните масштаб записи (домен, конкретный IP или подсеть), затем запросите новый адрес у хостинг-провайдера и перенесите сервисы, оставив старый IP для внутренних задач. Параллельно зафиксируйте инцидент в базе знаний и настройте алертинг, чтобы не пропустить повторную блокировку.