В Cloudflare нет единой страницы со всеми заблокированными IP. Правила, из-за которых запрос получает 403 или 1020, разложены по нескольким инструментам: IP Access Rules, WAF custom rules (бывшие Firewall Rules) и rate limiting. Быстрее всего проверить адрес в разделе Security → WAF → Tools → IP Access Rules: в таблице видно, какие IP, подсети, ASN и страны получили действие Block.
Начинайте диагностику с кода ответа. 1020 формирует сам Cloudflare, значит блокировка точно на его стороне. 403 отдают и Cloudflare, и origin-сервер, поэтому здесь решают заголовки ответа и логи обеих сторон. Ниже - пути в панели, готовые команды API и чек-лист аудита.
Один нюанс до начала: Cloudflare переименовывает разделы между релизами, и Firewall Rules в обновлённых аккаунтах теперь называются WAF custom rules. Названия пунктов в вашей панели могут отличаться на один шаг, логика при этом сохраняется.
Пути в панели и эндпоинты API указаны по состоянию на сентябрь 2026 года. Сверяйте их с интерфейсом своего аккаунта: Cloudflare постепенно переносит правила на ruleset engine и меняет названия фаз.
Где в Cloudflare посмотреть заблокированные IP
Стартовая точка - Security → WAF → Tools. Вкладка IP Access Rules показывает правила, которые матчат адрес запроса: отдельный IP, диапазон в CIDR, номер автономной системы (ASN) или страну. Действия три: Block, Challenge и Allow, в API последнее называется whitelist.
Сводного списка всех блокировок в панели нет. WAF custom rules живут на отдельной вкладке, rate limiting - на третьей. Адрес, заблокированный сложным выражением вроде «путь /wp-login.php + метод POST + User-Agent без браузерных признаков», в IP Access Rules не появится.
IP Access Rules: список заблокированных адресов
Таблица содержит колонки Type (IP, IP range, ASN, Country), Value, Action, Notes и дату создания. Комментарий в Notes заполняйте всегда: через полгода именно он объяснит, зачем адрес заблокирован.
Чтобы оставить только блокировки, отфильтруйте таблицу по Action = Block. Правила уровня зоны действуют на один домен, правила уровня аккаунта наследуются всеми зонами аккаунта, и найти их можно в разделе аккаунта. Если адрес прописан в двух местах, проверьте оба.
Выгрузка списка через API:
curl -s -X GET "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/firewall/access_rules/rules?per_page=100" \ -H "Authorization: Bearer $CF_API_TOKEN" \ -H "Content-Type: application/json"
Только блокирующие правила и их значения:
curl -s -X GET "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/firewall/access_rules/rules?per_page=100" \ -H "Authorization: Bearer $CF_API_TOKEN" \ | jq -r '.result[] | select(.mode=="block") | "\(.configuration.target) \(.configuration.value) \(.notes)"'
Ответ приходит страницами. Поле result_info.total_pages покажет, сколько их всего; для больших списков пройдите страницы циклом по параметру page.
Список операций и назначение эндпоинтов подтверждены в справочнике Firewall API, а поведение и рекомендации по IP Access rules - в документации IP Access rules.
Firewall Rules и Rate Limiting: где искать блокировки
WAF custom rules (Security → WAF → Custom rules) матчат запрос по выражению. Доступные поля: ip.src, ip.geoip.country, http.request.uri.path, http.request.method, http.user_agent, http.request.headers. Правило с действием Block срабатывает молча для клиента, но оставляет запись в событиях безопасности.
Читайте список правил сверху вниз: исполняются они в том порядке, который задаёте вы перетаскиванием. Действие Log (в новом интерфейсе - Simulate) ничего не блокирует, а только пишет событие. Это самый безопасный способ проверить новое условие на живом трафике.
Rate limiting (Security → WAF → Rate limiting rules) блокирует по частоте: например, больше 100 запросов с одного IP за минуту на /login. При превышении лимита Cloudflare возвращает код 429, а на странице ошибки виден код Cloudflare 1015 «You are being rate limited»: сайт получил слишком много запросов и временно заблокировал доступ. Важно различать эти два сигнала: 1015 - специфичный для Cloudflare ответ rate limit, тогда как HTTP 429 - общий код, который может прийти и от origin-сервера. Если пользователи жалуются на 429, проверяйте этот раздел, а не IP Access Rules.
Сработавшее правило видно в Security → Events: там есть тип правила, действие, IP и Ray ID запроса. Для длительного хранения включайте Logpush, иначе события живут ограниченное время.
Описание ошибки 1015 и её связь с rate limiting приведены в документации Cloudflare по ошибке 1015; разбор отличий 1015 от HTTP 429 - в материале Decodo об ошибке 1015.
Как отличить блокировку Cloudflare от блокировки на origin-сервере
Разделить две блокировки помогает один признак: кто сформировал ответ. Cloudflare добавляет к ответу заголовки cf-ray и Server: cloudflare. Origin отвечает своими: Server: nginx или Server: apache и без cf-ray.
Ошибка 1020: что это и как диагностировать
Код 1020 означает «Access denied»: доступ к сайту запрещён правилом firewall Cloudflare. Это ошибка, сгенерированная Cloudflare, а не origin-сервером, поэтому вопрос «кто блокирует» здесь не стоит. По документации Cloudflare такая блокировка возникает, когда клиент или браузер попадает под Firewall Rules (deprecated) клиента Cloudflare. Алгоритм поиска виновного правила:
- Откройте Security → WAF → Tools → IP Access Rules и проверьте, нет ли вашего адреса или его подсети среди Block.
- Перейдите в WAF custom rules и найдите активные правила с действием Block, особенно те, что матчат по стране или ASN.
- Проверьте rate limiting rules: всплеск запросов с одного адреса мог упереться в лимит.
- Возьмите Ray ID со страницы ошибки, откройте Security → Events и найдите запись по этому ID. В событии будет имя правила и его действие.
Дальше останется либо снять правило, либо добавить адрес в Allow. Не ослабляйте правило ради одного клиента, если он ходит из страны, которую вы блокируете целиком: точечное исключение безопаснее.
Определение и причина ошибки 1020 подтверждены в документации Cloudflare по ошибке 1020; признак того, что 1020 - ошибка, сгенерированная Cloudflare, приведён в примерах custom error rules.
Ошибка 403: Cloudflare или Nginx?
403 умеют отдавать оба участника. Первым делом посмотрите заголовки ответа:
curl -sI https://example.com/admin/ | grep -iE '^(server|cf-ray|cf-cache-status)'
Если видите cf-ray и Server: cloudflare, запрет сформировал Cloudflare: ищите правило в WAF. Если в заголовках только Server: nginx, блокировка на сервере. Чтобы исключить Cloudflare из цепочки, обратитесь к origin напрямую по IP:
curl -sI --resolve example.com:443:203.0.113.10 https://example.com/admin/ | head -20
На стороне Nginx проверьте две вещи. В error.log ищите строку access forbidden by rule, она соответствует директиве deny:
grep -i "access forbidden by rule" /var/log/nginx/error.log | tail -20
В конфиге смотрите директивы deny, allow, auth_basic и правила location. Заодно проверьте fail2ban: если сервер стоит за Cloudflare, то баны получат адреса самого Cloudflare, и вы заблокируете весь трафик. Для корректной работы включите модуль real_ip в Nginx и передавайте реальный адрес клиента через заголовок CF-Connecting-IP.
Приоритеты правил в Cloudflare: что срабатывает первым
Порядок обработки запроса определяет, какое правило победит при конфликте. Фазы Ruleset Engine выполняются в том порядке, в котором они перечислены в документации; для HTTP-запросов Custom rules (Web Application Firewall) идут перед Rate limiting rules (WAF). Дополнительно действуют два правила приоритета: правила уровня аккаунта в фазе выполняются перед правилами уровня зоны в той же фазе, а терминирующее действие (Block, Managed Challenge) останавливает оценку, и последующие фазы запрос уже не видят.
Практический пример из этого правила: Block в custom rules убивает запрос до Managed Rules, и в Security Events вы увидите срабатывание custom Block, а не ID правила Managed Rules (например, сигнатуры SQLi).
Точную последовательность «IP Access Rules → WAF custom rules → Rate limiting → WAF Managed Rules» и утверждение, что Allow в IP Access Rules прекращает проверку последующими пользовательскими правилами, официальная документация в доступных нам материалах прямо не подтверждает. Поэтому не полагайтесь на неё как на гарантированную схему: проверяйте фактический порядок срабатывания в Security Events и тестируйте конфликтующие правила в режиме Log, прежде чем включать Block.
Пример конфликта. Адрес 203.0.113.10 внесён в Allow в IP Access Rules, а подсеть 203.0.113.0/24 заблокирована в custom rules. Итог зависит от того, какое правило сработает раньше: проверяйте такие пары в режиме Log, прежде чем включать Block.
Порядок фаз зависит от версии движка, на которую переведён ваш аккаунт. После миграции на ruleset engine часть правил переезжает, поэтому фиксируйте текущую схему в комментариях к правилам и перепроверяйте после обновлений интерфейса.
Порядок фаз и приоритет account-level над zone-level подтверждены в справочнике фаз Ruleset Engine; поведение терминирующих действий и пример с custom Block до Managed Rules разобраны в обзоре Cloudflare WAF от Techclick.
Как выгрузить список заблокированных IP через API
Для аудита и синхронизации с внешними системами удобнее работать через API: панель не даёт ни истории изменений, ни удобного экспорта. Ниже - минимально необходимый набор прав и команды для каждого типа правил.
Получение API Token с нужными правами
Создайте отдельный токен только на чтение, чтобы случайный скрипт не мог удалить правила. Путь: My Profile → API Tokens → Create Token → Custom token. Затем:
- Permissions: Zone → Firewall Services → Read. Для изменения правил понадобится Edit, но для аудита хватит Read.
- Zone Resources: Include → Specific zone → выберите нужный домен.
- Остальные разрешения не добавляйте. Global API Key для этих задач не нужен, и хранить его в скриптах рискованно.
Токен держите в переменной окружения или в секретах CI:
export CF_API_TOKEN="ваш_токен" export ZONE_ID="идентификатор_зоны"
Токен не коммитьте в git. Храните его в менеджере секретов и отзывайте при смене подрядчика.
Примеры curl для разных типов блокировок
IP Access Rules (операции List IP Access rules, Get an IP Access rule и Create an IP Access rule описаны в разделе Firewall API):
curl -s -X GET "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/firewall/access_rules/rules?per_page=100" \ -H "Authorization: Bearer $CF_API_TOKEN" | jq '.result[] | select(.mode=="block") | .configuration.value'
WAF custom rules (для правил firewall API предусмотрены также операции обновления приоритета и удаления firewall rule):
curl -s -X GET "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/firewall/rules" \
-H "Authorization: Bearer $CF_API_TOKEN" | jq '.result[] | {description, action, filter}'
Rate limiting:
curl -s -X GET "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/rate_limits" \
-H "Authorization: Bearer $CF_API_TOKEN" | jq '.result[] | {description, disabled, threshold}'
Если зона уже переведена на ruleset engine, вместо /firewall/rules используйте Rulesets API: точка входа custom rules лежит по пути /zones/$ZONE_ID/rulesets/phases/http_request_firewall_custom/entrypoint. Для управления правилами этой фазы используется операция обновления entry point ruleset зоны, которая заменяет существующие правила в entry point ruleset фазы. Оба варианта возвращают те же правила в разной структуре, поэтому скрипт аудита стоит написать с проверкой, какой эндпоинт отвечает.
Обратите внимание: конкретные URL-шаблоны эндпоинтов выше приведены по состоянию на сентябрь 2026 года. В официальной документации Cloudflare подтверждены названия операций (List IP Access rules, Update priority of a firewall rule, Delete a firewall rule, Update a zone entry point ruleset) и наличие entry point ruleset фазы http_request_firewall_custom, но не дословные пути. Сверяйте актуальные URL в справочнике Firewall API и документации по custom error rules перед запуском скриптов.
Централизованное управление доступом: стратегия и инструменты
Распределяйте правила по назначению, тогда конфликтов будет меньше:
| Инструмент | По чему матчит | Путь в панели | Когда использовать |
|---|---|---|---|
| IP Access Rules | IP, CIDR, ASN, страна | Security → WAF → Tools | Быстрые блокировки и белые списки по адресам |
| WAF custom rules | IP, путь, метод, User-Agent, заголовки, страна | Security → WAF → Custom rules | Условия из нескольких признаков |
| Rate limiting | Частота запросов плюс выражение | Security → WAF → Rate limiting rules | Брутфорс, парсинг, всплески на логине и API |
| WAF Managed Rules | Сигнатуры известных атак | Security → WAF → Managed rules | Базовая защита, которую не подменяют своими правилами |
По документации Cloudflare IP Access rules позволяют блокировать, разрешать и проверять трафик по IP-адресу, ASN или стране посетителя. При этом Cloudflare рекомендует создавать custom rules вместо IP Access rules для IP- или гео-блокировок. Учитывайте это при проектировании: для новых задач блокировки по адресу или географии лучше сразу заводить custom rule, а IP Access Rules использовать для быстрых точечных исключений и белых списков.
Рабочая схема доступа к админке: в IP Access Rules внесите офисные и VPN-адреса с действием Allow, а в custom rules поставьте правило, которое блокирует всё остальное на префикс /admin или /wp-admin. Так исключения собираются в одном месте, а не расползаются по десяткам условий.
Для геоограничений сравните доступные пути до того, как заводить правила: разбор Cloudflare, AWS WAF, Nginx и iptables с замерами и конфигами мы приводим в материале о геофильтрации в 2026 году. Если фильтрация нужна на уровне приложения, а не CDN, пригодятся готовые middleware для Python, Node.js и Go.
Правила именуйте по схеме: инструмент, задача, дата, автор. Например, «WAF custom: block xmlrpc 2026-09-23, Ivanov». Комментарий в Notes избавит от археологии через год.
Типичные ошибки и чек-лист аудита блокировок
- Блокировка IP мониторинга, бэкапов или офисного VPN. Проверяйте адреса внешних сервисов до включения правила.
- Конфликт Allow и Block на разных уровнях. Один и тот же адрес в белом и чёрном списках даёт неожиданный результат, особенно после миграции интерфейса.
- Отключённое логирование. Без Security Events и Logpush вы не поймёте, какое правило сработало и когда.
- Забытые правила годичной давности. Блокировка подсети из-за одного инцидента продолжает работать и режет легитимных клиентов.
- Дублирование защиты: fail2ban на origin банит адреса Cloudflare вместо реальных клиентов и блокирует весь трафик зоны.
Чек-лист перед тем, как закрыть задачу:
- Пройти по всем IP Access Rules и снять устаревшие.
- Проверить, что Allow не перекрывает Block там, где это не задумано.
- Включить Logpush для Security Events или настроить выгрузку событий.
- Прогнать новое правило в режиме Log или Simulate минимум сутки.
- Выгрузить список через API и сохранить снимок для истории.
- Убедиться, что Nginx видит реальный адрес клиента через CF-Connecting-IP.
Контрольная команда считает число правил доступа в зоне и сразу показывает, изменилось ли что-то с прошлого аудита:
curl -s -H "Authorization: Bearer $CF_API_TOKEN" \ "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/firewall/access_rules/rules?per_page=100" \ | jq '.result | length'
Смежные техники блокировки на уровне сервера и пограничных устройств разобраны в статье о стратегиях блокировки IP и автоматизации в iptables, nftables и fail2ban, а методику полной проверки периметра с готовыми командами Nmap вы найдёте в материале об аудите сетевой инфраструктуры.