Access denied и Your IP, почему сайт блокирует доступ и как исправить ошибку

Сообщение «Access denied. Your IP» означает, что один из узлов между браузером и приложением отказался обрабатывать запрос. Текст не доказывает блокировку IP. Отказ мог сформировать веб-сервер, CDN, WAF, антибот-система, балансировщик, корпоративный прокси, модуль безопасности CMS или само приложение.

Я начинаю диагностику с трёх вопросов. Какой HTTP-код вернулся, какой сервер сформировал ответ и появляется ли ошибка при другом способе подключения. Ответы быстро отделяют блокировку IP от проблем с авторизацией, ограничением частоты запросов, браузерной проверкой и ошибкой конфигурации.

Что на самом деле вернул сайт

Первым делом я запрашиваю страницу методом GET и вывожу заголовки ответа. Команда curl -I менее надёжна для такой проверки, поскольку отправляет HEAD. Сервер или защитный сервис может обработать HEAD иначе, чем обычную загрузку страницы через GET. Разницу подтверждают документация curl и описание метода HEAD.

curl -sS -L -D - -o /dev/null https://example.com/
 
 curl -sS -L -o /dev/null 
   -w "HTTP %{http_code}
URL %{url_effective}
" 
   https://example.com/
 
 curl -4 -sS -L -D - -o /dev/null https://example.com/
 curl -6 -sS -L -D - -o /dev/null https://example.com/

Параметр -L разрешает переход по редиректам, -D - выводит заголовки, а -o /dev/null не сохраняет тело страницы. Проверки через IPv4 и IPv6 помогают найти ситуацию, когда защитное правило действует только для одного адреса или сетевого диапазона.

curl не проходит проверки, которым нужны JavaScript и cookie. Cloudflare прямо указывает, что консольные клиенты не выполняют браузерные Challenge-проверки, а AWS WAF использует JavaScript и токены в cookie. Поэтому результат curl показывает HTTP-цепочку, но не всегда повторяет поведение браузера. Подробности описаны в документации Cloudflare и AWS WAF.

Стандарт RFC 9110 определяет 403 как отказ выполнить понятый запрос. Документация AWS CloudFront перечисляет несколько независимых источников такого ответа, включая WAF, географические ограничения, origin-сервер, S3 и ошибки подписанных ссылок. По одному коду нельзя определить причину.

Код 429 однозначнее и означает превышение установленной частоты запросов. Сервер может вернуть Retry-After с рекомендуемым временем ожидания. Такое поведение описывают RFC 6585 и документация Cloudflare Rate Limiting.

Код 503 тоже нельзя автоматически считать признаком аварии. По RFC 9110 сервер временно не может обработать запрос. При этом модуль ограничения запросов Nginx по умолчанию возвращает именно 503, хотя для rate limit логичнее настроить 429.

Что может сделать посетитель

Сначала я сохраняю точный адрес страницы, время ошибки с часовым поясом, HTTP-код, показанный IP и идентификатор запроса. Для Cloudflare особенно полезен Ray ID. Владелец сайта может найти событие по Ray ID или клиентскому адресу, что подтверждают документация Cloudflare Ray ID и руководство по ошибке 1020.

Время 2026-07-19 21:42 UTC
 URL https://example.com/account
 HTTP-код 403
 IP 203.0.113.15
 Request ID abc123
 Браузер Chrome
 Сеть домашний провайдер

Дальше я открываю тот же URL в приватном окне, временно отключаю блокировщики и защитные расширения, проверяю JavaScript и cookie. Cloudflare предупреждает, что блокировщики скриптов, антифингерпринтинг и отключённый JavaScript могут мешать Challenge-проверке. AWS WAF тоже применяет JavaScript и cookie с токеном для подтверждения браузерной сессии. Источники доступны в руководствах Cloudflare и AWS WAF.

Если включён корпоративный прокси или VPN, я временно отключаю его для диагностики и повторяю запрос через обычное разрешённое подключение. Затем проверяю другой браузер или устройство. Смена среды помогает понять, связано ли срабатывание с сетью, браузером или конкретной сессией, но не доказывает причину.

Проверка через мобильный интернет тоже полезна как диагностический тест. Если домашняя сеть получает отказ, а мобильная открывает страницу, защитная система может учитывать IP, подсеть, ASN, страну, IPv4 или IPv6. Публичный адрес при этом не обязательно принадлежит одному абоненту. CGNAT позволяет нескольким клиентам провайдера выходить через общий IPv4, что описывают RFC 6888 и исследование Cloudflare.

Из-за CGNAT, офисного NAT или общего VPN-сервера блокировка способна затронуть людей, которые не отправляли подозрительные запросы. IP показывает сетевую точку выхода, но не подтверждает личность пользователя.

При 429 я не обновляю страницу многократно, а проверяю Retry-After и сообщение сервиса. При 403 без понятной причины обращаюсь к владельцу сайта и передаю собранные данные. Случайная смена IP может временно скрыть симптом, но не исправит ошибочное правило, повреждённую сессию или неправильно настроенный WAF.

Как искать причину владельцу сайта

Я начинаю с определения уровня, на котором оборвался запрос. Проверяю журналы CDN, WAF, балансировщика, веб-сервера и приложения. Если событие есть в CDN, но отсутствует на origin-сервере, запрос, скорее всего, остановился до origin. Если веб-сервер записал 403 от upstream, отказ сформировало приложение или следующий прокси.

grep '203.0.113.15' /var/log/nginx/access.log
 grep '203.0.113.15' /var/log/nginx/error.log
 
 grep '203.0.113.15' /var/log/apache2/access.log
 grep '203.0.113.15' /var/log/apache2/error.log
 
 journalctl -u nginx 
   --since "2026-07-19 21:35" 
   --until "2026-07-19 21:50"

На сайте за Cloudflare я ищу событие по Ray ID, IP, URL и времени в Security Events. В AWS CloudFront проверяю WAF, географические ограничения, политику origin, разрешённые HTTP-методы, подписанные URL и cookie. Разнообразие причин подтверждают официальные руководства Cloudflare и AWS.

Отдельно проверяю восстановление клиентского IP за обратным прокси. Origin-сервер видит адрес CDN или балансировщика, пока администратор не настроит доверенный заголовок. Nginx меняет клиентский адрес через модуль Real IP, а стандартный заголовок Forwarded описан в RFC 7239.

# Укажите только адреса собственных доверенных прокси
 set_real_ip_from 192.0.2.10;
 set_real_ip_from 2001:db8:1234::/48;
 
 real_ip_header X-Forwarded-For;
 real_ip_recursive on;

Нельзя задавать set_real_ip_from 0.0.0.0/0 и безусловно доверять заголовку от любого клиента. Злоумышленник сможет подставить произвольный адрес, загрязнить журналы или обойти лимит, основанный на IP. Риск подтверждают рекомендации OWASP и документация Nginx.

Для Cloudflare лучше использовать CF-Connecting-IP и доверять заголовку только при соединении с актуальных адресов Cloudflare. Origin также следует закрыть от прямого публичного доступа, если архитектура не требует обратного. Схему описывают руководства по восстановлению IP и адресам Cloudflare.

Следующим шагом проверяю rate limit. Nginx по умолчанию отвечает кодом 503 на отклонённые запросы. Я явно задаю 429, чтобы ответ соответствовал смыслу ограничения частоты.

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
 
 server {
     location = /login {
         limit_req zone=login burst=5 nodelay;
         limit_req_status 429;
 
         proxy_pass http://backend;
     }
 }

Перед включением строгого лимита можно использовать limit_req_dry_run on. Nginx продолжит обслуживать запросы, но отметит превышения в статистике и журналах. Такой режим помогает подобрать порог по реальному трафику. Обе директивы описаны в текущей документации ngx_http_limit_req_module и практическом руководстве Nginx.

Если блокировку вызвало правило WAF, я не отключаю весь набор защиты. Сначала нахожу ID правила, путь, параметр и часть запроса, которая вызвала срабатывание. Затем создаю исключение только для нужного маршрута, метода или параметра. OWASP CRS рекомендует устранять ложные срабатывания через rule exclusions, а Cloudflare советует отключать конкретное правило вместо всего ruleset. Подробности есть у OWASP CRS и Cloudflare.

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

nginx -t && systemctl reload nginx
 
 apachectl configtest && systemctl reload apache2

Ошибки, которые только ухудшают ситуацию

Первая ошибка заключается в предположении, что указанный IP попал в некий глобальный чёрный список. Сайт может использовать собственное правило, локальную базу, ограничение по стране, ASN, URL или поведению браузера. Проверка адреса в стороннем сервисе репутации не покажет внутренние правила конкретного сайта.

Вторая ошибка связана с полным отключением WAF. Доступ восстановится, но приложение потеряет защитный слой, а причина ложного срабатывания останется неизвестной.

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

Четвёртая ошибка заключается в использовании IP как единственного идентификатора. CGNAT объединяет нескольких абонентов, мобильные операторы меняют адреса, а IPv6 может назначать клиенту несколько адресов. Для административных разделов надёжнее применять учётные записи, многофакторную аутентификацию, mTLS или отдельную систему контроля доступа.

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

Короткие ответы

Сообщение «Access denied. Your IP» даёт только исходную точку. Посетителю нужно получить реальный HTTP-код, проверить браузерную среду и передать владельцу идентификатор запроса. Администратору нужно проследить запрос через CDN, WAF, прокси, веб-сервер и приложение, а затем исправить конкретное правило. Смена IP, очистка всего браузера и отключение защиты могут скрыть симптом, но редко устраняют настоящую причину.