Сообщение «отключите VPN» не доказывает, что посетитель включил VPN. Если сайт стоит за CDN или обратным прокси, защита может проверять адрес промежуточного сервера вместо адреса клиента. Другой вариант — адрес клиента определён верно, но правило ошибочно относит его к нежелательной сети.
Сначала найдите конкретный отказ в журнале защиты и выясните, какой IP использовало правило. Это отделяет ошибку передачи адреса от ошибки классификации; отключать WAF целиком для такой проверки не нужно.
1. Установите, кто показал сообщение
WAF — фильтр веб-запросов. Он может работать на стороне CDN, на сервере или внутри приложения. Надпись про VPN бывает и собственной страницей сайта: по её тексту нельзя определить механизм блокировки.
Для одного воспроизводимого обращения сохраните:
- публичный URL без секретных параметров;
- время и часовой пояс;
- HTTP-код и точный текст отказа;
- технический идентификатор запроса, если он есть;
- сеть, в которой ошибка повторяется.
Владелец сайта ищет соответствующее событие в журнале CDN, прокси и приложения. Нужны действие, идентификатор правила и адрес, по которому принято решение. Если блокировка произошла на CDN до передачи запроса дальше, записи приложения может не быть.
Ответ 403 сам по себе не означает запрет VPN: возможны ограничения по пути, роли или другим условиям. Общие причины разобраны в руководстве по 403 Forbidden.
2. Сверьте адрес на каждом участке
В цепочке «посетитель → CDN → балансировщик → приложение» сервер принимает соединение от ближайшего прокси. Исходный адрес передаётся отдельно, а каждый слой должен правильно его интерпретировать.
Для Cloudflare это описано в инструкции по восстановлению IP посетителя: origin по умолчанию видит адрес Cloudflare, а клиентский адрес передаётся в заголовке CF-Connecting-IP. При другом провайдере проверяйте его собственный контракт передачи IP.
Сопоставьте для одного запроса три значения: адрес соединения с сервером, адрес в доверенном заголовке и адрес, использованный защитой. Проверку проводите в закрытом диагностическом журнале с ограниченным доступом и сроком хранения; не выводите эти данные на публичную страницу.
Если защита проверяет адрес прокси
Признак ошибки — разные посетители определяются как один узел CDN или балансировщика. Проверьте, сохраняется ли клиентский заголовок на следующем прокси и использует ли приложение восстановленный адрес.
Сначала найдите место потери: CDN передал адрес, балансировщик его заменил или приложение проигнорировало. Правка только логирования не поможет, если модуль блокировки продолжит брать другой IP.
Если клиентский адрес определён верно
Тогда проверяйте условие отказа: список IP, сеть оператора, репутационную категорию или отдельный антифрод-сервис. Попросите поставщика объяснить основание классификации. Название категории «VPN» ещё не подтверждает реальное использование туннеля.
Общий внешний адрес корпоративной сети или оператора может принадлежать нескольким посетителям. Поэтому успешный тест через мобильную сеть сужает поиск до сети или правила, но не доказывает причину отказа.
3. Исправьте границу доверия
Нельзя безусловно брать первый IP из X-Forwarded-For: заголовок может прийти от самого клиента. Сервер должен доверять сведениям об адресе только от известных прокси, а входная граница — обрабатывать внешние заголовки по согласованным правилам.
В nginx за это отвечает модуль realip:
set_real_ip_fromзадаёт доверенные адреса прокси;real_ip_headerвыбирает источник клиентского адреса;real_ip_recursiveуправляет разбором цепочки адресов.
При рекурсивном разборе nginx выбирает последний недоверенный адрес из переданной цепочки, если адрес соединения относится к доверенным. Настройка должна соответствовать реальной схеме проксирования: универсального набора директив для всех сайтов нет.
Не добавляйте весь интернет в доверенные сети и не копируйте устаревший список узлов CDN. Если origin доступен напрямую, неподтверждённый заголовок не должен позволять посетителю подменить IP. Проверьте также настройки доверенных прокси в самом приложении: сервер и приложение могут иначе трактовать одну цепочку.
Перед применением сохраните прежнюю конфигурацию, проверьте синтаксис и подготовьте откат. Меняйте один участок за раз.
4. Докажите результат повторной проверкой
Повторите тот же безопасный запрос из затронутой сети и из независимой сети. Убедитесь, что правило получает ожидаемый адрес, ложный отказ исчез и нужная страница показывает штатное содержимое. Один код 200 недостаточен, если вместо страницы вернулась заглушка.
В контролируемом тесте проверьте и обратное: произвольный заголовок от недоверенного клиента не должен менять адрес, используемый защитой. Не тестируйте это на чужом сайте.
Если IP передаётся правильно, а блокировка остаётся, вернитесь к конкретному правилу и его классификатору. Отдельно разбирайте Cloudflare Challenge: браузерная проверка и запрет по адресу требуют разных действий.
Что делать посетителю и владельцу
Посетителю достаточно передать поддержке сайта публичный адрес страницы, время, текст ошибки и сеть подключения. Не устанавливайте предложенные неизвестной страницей программы ради «проверки VPN» и не отправляйте пароль или Cookie.
Внешний мониторинг Web-Puls помогает заметить изменения доступности публичного URL, но не читает ваши журналы WAF и не воспроизводит сеть каждого посетителя. Успешная внешняя проверка не отменяет подтверждённый отказ у клиента.
Если место подмены адреса не найдено, отправьте заявку на диагностику: укажите публичный URL, время с часовой зоной, схему прокси и очищенное описание сработавшего правила. Специалист оценит задачу и предложит формат работ; секреты и полные журналы в заявку не нужны.