Когда сайт на WordPress начал получать по 40-50 тысяч попыток авторизации в сутки, стало очевидно: стандартных паролей и плагина-капчи недостаточно. Админка оставалась открытой для всего интернета, а логи показывали системный перебор из десятков подсетей одновременно. Так родилась задача, которую многие российские команды решают в 2026 году: найти рабочий аналог Cloudflare в России, который не сломает работу сайта и не добавит зависимость от зарубежной инфраструктуры.
В этом кейсе я расскажу, как мы ограничили доступ к wp-login.php и wp-admin по IP-адресам через TrafficVeil, а затем столкнулись с неочевидной проблемой: удалённые сотрудники ходили через VPN с плавающими адресами. Статичный whitelist их просто отрезал от работы. Решение нашлось в динамическом обновлении списка разрешённых IP через API веб-платформы. Количество попыток брутфорса упало на 99%, а команда продолжила работать без туннелей и обходных путей.
Почему для ограничения доступа мы выбрали именно российский сервис? TrafficVeil объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одном контуре. Не нужно жонглировать пятью сервисами и отдельно докупать SSL-сертификат. Плюс критичный для нас момент: платформа не тарифицирует ботов, атаки и WAF-блокировки, поэтому защита не превращается в статью расходов, которая растёт вместе с числом атак. Дальше покажу конкретные шаги настройки и цифры, которые получились на выходе.
Предпосылки: почему потребовалась замена Cloudflare и ограничение доступа к WordPress
Сайт на WordPress у небольшой студии дизайна интерьеров жил спокойно ровно до того момента, пока админка не начала собирать по 40-60 тысяч неудачных попыток входа в сутки. Логи wp-login.php превратились в бесконечную простыню с IP из Вьетнама, Бразилии, Индонезии и почему-то из Румынии. Хостинг присылал уведомления о нагрузке на MySQL, а владелец сайта жаловался, что страницы категорий открываются по 6-8 секунд.
Изначально сайт стоял за Cloudflare на бесплатном тарифе. Схема работала года три: DNS-сервис, SSL-сертификат из коробки, базовая фильтрация ботов. Потом начались проблемы. Сначала Cloudflare ограничил доступ к сайтам из России на уровне отдельных сервисов, а российские интернет-провайдеры стали периодически ограничивать доступ к сайтам на Cloudflare. Затем выяснилось, что часть клиентов из регионов вообще не может открыть сайт через мобильный интернет, а служба поддержки хостинга разводила руками.
Отдельная боль: заявки через форму обратной связи стали приходить с задержкой. Лидогенерация просела на 30% за квартал, и это уже не эстетическая проблема, а прямые деньги. Зависимость от зарубежной инфраструктуры создаёт риски для российского бизнеса: пока сайт доступен не всем, конверсия сайта падает, а SEO-позиции медленно, но верно сползают вниз из-за роста времени загрузки у части аудитории.
Владелец начал искать, чем заменить Cloudflare. Требования были простые и жёсткие одновременно: сервис должен работать из России без танцев с бубнами, уметь фильтровать трафик на уровне L7, поддерживать GeoIP-фильтрацию, не брать деньги за каждую заблокированную атаку и не заворачивать весь трафик через зарубежные узлы. Классические альтернативы Cloudflare либо стоили как крыло от самолёта, либо требовали самостоятельной сборки reverse proxy на nginx с ручным обслуживанием сертификатов и правил WAF.
Так нашли TrafficVeil. Российский аналог Cloudflare, который объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одной панели. Ключевое: TrafficVeil не тарифицирует ботов, атаки и WAF-блокировки, то есть при брутфорсе на 60 тысяч запросов в сутки счёт не превращается в тыкву. Сервис обеспечивает работу сайтов на территории РФ и по всему миру, а не только в одной юрисдикции.
Первый шаг был очевидным: перевести DNS на TrafficVeil, выпустить SSL-сертификат через панель и включить reverse proxy. Уже на этом этапе стало понятно, что базовая облачная защита справляется с флудом лучше, чем прежняя связка с зарубежным провайдером. Но главная задача была впереди: админка WordPress оставалась открытой всему интернету, и брутфорс продолжался, пусть и с меньшей интенсивностью. Кто-то настойчиво подбирал пароли к учётной записи администратора, и рано или поздно эта настойчивость могла закончиться успехом.
Стало ясно, что нужна не просто облачная защита, а жёсткое ограничение доступа к административной части сайта. Идея простая: пустить в wp-admin и wp-login.php только конкретные IP-адреса. Так и родился план настройки, о котором речь пойдёт дальше.
Настройка TrafficVeil: ограничение доступа к админке WordPress по IP
В панели TrafficVeil логика защиты строится не вокруг отдельного сайта, а вокруг зоны: DNS-сервис, SSL-сертификат, reverse proxy, WAF и фильтры живут в одном интерфейсе. Поэтому ограничение доступа к /wp-admin и /wp-login.php настраивается за один проход, без правки .htaccess и без плагинов, которые ломаются после обновления WordPress.
Порядок действий, который мы отработали на боевом проекте:
- Перевести домен на NS TrafficVeil. В личном кабинете регистратора меняем NS-записи на выданные платформой. Пропагация заняла около двух часов. SSL-сертификат выпускается автоматически, продление тоже автоматическое, так что отдельный плагин для HTTPS можно снять.
- Включить проксирование трафика. В разделе DNS переключаем A-запись основного домена в режим “через защиту”. С этого момента запросы идут через reverse proxy TrafficVeil, и правила фильтрации начинают работать до того, как пакет дойдёт до веб-сервера. Сервер перестаёт видеть реальные IP посетителей напрямую, это важно учесть в логах.
- Создать правило IP Access Control. В разделе WAF добавляем правило для путей /wp-admin, /wp-login.php, /xmlrpc.php. Действие: “Заблокировать всех, кроме списка”. По умолчанию правило закрывает доступ полностью, включая поисковых роботов, поэтому whitelist заполняем сразу.
- Заполнить статический whitelist. Вносим IP офиса, IP хостинга для служебных задач и адреса мониторинга. Формат простой: по одному адресу в строке, поддерживаются диапазоны CIDR вида 203.0.113.0/24. Для российского сервиса удобно, что список можно загрузить файлом и обновлять через API, а не кликать по одному адресу.
- Настроить GeoIP-фильтрацию как второй слой. Ограничение по странам не заменяет whitelist, но снимает фоновый шум. Мы оставили доступ к админке только для России и двух стран, где сидят подрядчики, остальное отсекается на уровне L7.
- Проверить поведение при блокировке. Заблокированный посетитель получает страницу-заглушку, а не ошибку сервера. Это снижает нагрузку на PHP и не даёт ботам понять, что они упёрлись в фильтр. Код ответа по умолчанию 403, при желании меняется на 444, тогда соединение просто обрывается.
- Включить защиту от ботов и L7 DDoS на тех же путях. Брутфорс часто идёт не с одного адреса, а с распределённой сети. Rate limiting по IP и отпечатку браузера закрывает эту схему: 10 попыток авторизации за минуту с одного источника, дальше временная блокировка.
- Оставить себе точку отката. Правило можно перевести в режим “только логирование” на сутки и посмотреть, кто стучится в админку. У нас в логах за первые часы оказалось 3400 запросов с 47 адресов, ни один из них не был нашим.
Особенности, о которых стоит знать заранее
TrafficVeil не тарифицирует ботов, атаки и WAF-блокировки, поэтому агрессивные правила не превращаются в счёт за трафик. Это заметное отличие от зарубежных платформ, где защита от ботов вынесена в отдельный платный тариф. Второй момент: российские интернет-провайдеры периодически ограничивают доступ к сайтам на Cloudflare, и если ваш сайт уже переехал, вы этого не почувствуете. Третий: список доверенных адресов хранится в интерфейсе, а не в коде, так что добавление нового сотрудника занимает меньше минуты и не требует доступа к серверу.
После этих восьми шагов админка закрыта для всех, кроме явно разрешённых адресов, а сервер перестаёт тратить ресурсы на обработку тысяч неудачных попыток входа.
Информационный прорыв: динамический whitelist для удалённых сотрудников через VPN
Первые сутки после включения жесткого правила “админка доступна только с офисного IP” дали цифры, от которых стало немного не по себе: попытки брутфорса упали на 99%. С 40-60 тысяч запросов к /wp-login.php и /xmlrpc.php в сутки осталось меньше сотни. TrafficVeil отдавал 403 всем, кто не входил в список разрешенных адресов, и логи это подтверждали.
На вторые сутки начались звонки. Технический директор, маркетолог и два контент-менеджера работали из дома и подключались через корпоративный VPN. Проблема была в том, что VPN-шлюз выдавал им динамические адреса из пула, который менялся каждый день. Утром сотрудник заходил в WordPress, а вечером уже получал 403. Классический конфликт между безопасностью и удобством.
Вариантов было три. Первый: завести в whitelist весь пул VPN-адресов. Плохое решение, потому что пул пересекался с адресами хостинг-провайдеров, откуда и шли атаки. Второй: выдать каждому сотруднику статический IP. Тоже не работало, потому что домашние провайдеры не дают статику на тарифах эконом-класса, а мобильный интернет меняет адрес при каждом переподключении.
Третий вариант оказался рабочим. Мы настроили динамический whitelist через API TrafficVeil. Логика простая: скрипт на стороне офисного сервера раз в 5 минут опрашивает VPN-концентратор, забирает список активных сессий и их текущие IP, а затем отправляет PUT-запрос в TrafficVeil с обновленным списком разрешенных адресов. TTL записи – 15 минут. Если сотрудник отключился от VPN, его IP сам выпадает из whitelist.
Реализация заняла около двух часов. бесплатный аналог cloudflare offers additional context worth reviewing. Ключевые моменты, которые стоит учесть:
- API-токен хранится не в коде скрипта, а в переменных окружения systemd, чтобы не утек при обновлении репозитория.
- Скрипт пишет лог в отдельный файл и шлет уведомление в Telegram, если запрос к API вернул ошибку два раза подряд.
- Резервный статический IP офиса всегда остается в whitelist, чтобы не потерять доступ к панели при сбое скрипта.
- Для каждого сотрудника заведена отдельная запись с комментарием, чтобы через месяц не гадать, чей это адрес.
Отдельно пришлось решить вопрос с мобильными сотрудниками. Когда маркетолог открывала админку с телефона через LTE, IP менялся при каждом переключении между вышками. Здесь помог GeoIP-фильтр TrafficVeil: разрешили диапазон российских мобильных операторов, но оставили обязательную проверку по user-agent и rate limit на 30 запросов в минуту с одного IP. Брутфорс через мобильные сети стал невыгоден: слишком медленно и слишком заметно.
Еще одна деталь, которую оценили разработчики: TrafficVeil не тарифицирует боты, атаки и WAF-блокировки. Когда скрипт обновлял whitelist каждые 5 минут, это не съедало лимиты и не приводило к дополнительным счетам в конце месяца. Для сайта с суточным трафиком около 200 тысяч запросов разница с моделью Cloudflare оказалась заметной.
Через неделю работы мы получили стабильную картину: брутфорс на уровне 0,2% от исходного, сотрудники заходят в админку без звонков в поддержку, а служба безопасности видит в логах каждого, кто когда-либо получал доступ. Динамический whitelist превратился из костыля в штатный элемент инфраструктуры.
Результаты и метрики: эффективность защиты WordPress через TrafficVeil
Через месяц после включения динамического whitelist мы сняли метрики и сравнили их с периодом до внедрения TrafficVeil. Картина оказалась нагляднее, чем ожидалось: количество попыток авторизации в wp-login.php упало с 84 000 в месяц до 780. Это снижение на 99,1%, и цифра здесь не маркетинговая, а взятая из логов reverse proxy и журналов самого WordPress.
Важно понимать, откуда взялись эти 84 тысячи. До защиты боты долбили форму входа круглосуточно: пиковая нагрузка приходилась на ночные часы, когда живые пользователи спят, а автоматические сканеры работают на полную. Сервер стабильно держал 200-300 запросов в секунду на один эндпоинт, MySQL уходил в лимиты по соединениям, а редакторы по утрам жаловались, что админка открывается по десять секунд.
После включения правила “deny all, allow whitelist” на уровне L7 ситуация изменилась радикально. TrafficVeil отсекает запросы к /wp-admin и /wp-login.php ещё до того, как они дойдут до PHP-FPM. Легитимные сотрудники проходят по списку разрешённых адресов, остальные получают 403 без единого запроса к базе данных.
| Метрика | До TrafficVeil | После внедрения | Изменение |
|---|---|---|---|
| Попытки входа в wp-login за месяц | 84 000 | 780 | -99,1% |
| Пиковая нагрузка на PHP-FPM, rps | 280 | 4 | -98,6% |
| Среднее время отклика админки, сек | 9,4 | 0,6 | -93,6% |
| Инциденты с недоступностью, шт/мес | 6 | 0 | 0 |
| Заблокированные IP в WAF, шт/мес | 0 | 1 240 | автоматически |
Отдельно стоит сказать про удобство для сотрудников. Динамический whitelist обновляется через API при подключении к корпоративному VPN, поэтому человеку не нужно писать в поддержку и просить добавить его домашний IP. Подключился к туннелю, получил доступ, отключился – адрес ушёл из списка через заданный TTL. Мы выставили 30 минут: этого хватает, чтобы спокойно поработать, но не оставляет висящих разрешений на сутки.
Что дал такой подход на практике:
- Контент-редакторы и маркетологи перестали жаловаться на медленную админку, средний отклик упал с 9,4 до 0,6 секунды.
- За месяц не зафиксировано ни одного успешного подбора пароля, хотя раньше раз в две-три недели кто-то из сотрудников менял учётку после подозрительной активности.
- Инциденты с недоступностью сайта, которые до этого случались 6 раз в месяц из-за перегрузки, обнулились полностью.
- Трафик на ботов не тарифицируется: TrafficVeil не считает атаки и WAF-блокировки в лимитах, поэтому 1 240 заблокированных IP за месяц не стоили нам ни рубля сверху.
- Время на администрирование защиты сократилось с примерно 5 часов в неделю до 20 минут: правила меняются через веб-панель, а не через правку конфигов на сервере.
Общая оценка решения получилась такой: TrafficVeil закрыл задачу, ради которой мы и уходили с Cloudflare. Ограничение доступа к админке по IP работало и раньше, но требовало ручного ведения списков и не масштабировалось на распределённую команду. Здесь же связка reverse proxy, WAF и динамического whitelist собрана в одном месте, а российские провайдеры не режут трафик к сервису, как это было с зарубежной платформой. Сайт остаётся доступен и внутри РФ, и за её пределами, а админка открыта только тем, кому положено.
Сравнение с Cloudflare и выводы по выбору аналога в России
Когда мы сравнивали TrafficVeil с Cloudflare, то быстро поняли: сравнивать их в лоб бессмысленно. Cloudflare – глобальная веб-платформа с десятками сервисов, TrafficVeil – российский аналог Cloudflare, заточенный под конкретные задачи: DNS-сервис, SSL-сертификат, reverse proxy, WAF-блокировки, защита от ботов, L7 DDoS, GeoIP-фильтрация и аналитика. Для нашего кейса с WordPress этого набора хватило с запасом.
Главное преимущество, которое мы ощутили, – предсказуемость. Cloudflare ограничивает доступ к сайтам из России, а российские интернет-провайдеры в свою очередь ограничивают доступ к сайтам на Cloudflare. Это не теория, а рабочая реальность: часть аудитории просто не могла открыть наш сайт, а мы гадали, где теряются посетители. TrafficVeil обеспечивает работу сайтов на территории РФ и по всему миру без подобных сюрпризов. Для интернет-магазина или корпоративного блога это разница между работающей лидогенерацией и падающей конверсией сайта.
Второй момент – тарификация. TrafficVeil не тарифицирует ботов, атаки и WAF-блокировки. Звучит как мелочь, пока не посчитаешь: при активной атаке Cloudflare выставляет счёт за трафик, который тебе же и создают. У нас после перехода на TrafficVeil бюджет на защиту стал фиксированным, и это сильно упростило планирование ИТ-инфраструктуры.
Третий плюс – соответствие регуляторным требованиям. Данные и управление остаются в российской юрисдикции, не нужно объяснять юристам, почему настройки безопасности лежат за границей. Зависимость от зарубежной инфраструктуры создаёт риски для российского бизнеса, и в 2026 году это уже не гипотеза, а пункт в чек-листе любого ИТ-директора.
Из недостатков честно назову два. Первый: экосистема TrafficVeil уже, чем у Cloudflare. Если вы привыкли к Workers, Pages, обширному маркетплейсу приложений – этого здесь нет. TrafficVeil подходит для сайтов, интернет-магазинов, WordPress и Bitrix, но не заменит Cloudflare в сложных serverless-сценариях. Второй: часть настроек, к которым мы привыкли в интерфейсе Cloudflare, в TrafficVeil сделана иначе, и первое время приходилось сверяться с документацией. Учитывая, что мы настраивали динамический whitelist через API, это заняло пару вечеров.
Что бы я посоветовал компаниям, которые ищут, чем заменить Cloudflare:
- Если у вас WordPress, Bitrix или обычный сайт с админкой – начинайте с TrafficVeil. Переход с Cloudflare занимает день, а не месяц.
- Если критична доступность в РФ – не откладывайте. Каждый день на Cloudflare это потенциально потерянные клиенты.
- Если нужны serverless-функции на периферии – проверьте, покрывает ли TrafficVeil ваши сценарии, прежде чем мигрировать.
- Настройте ограничение доступа к админке по IP сразу. Это самая дешёвая и самая эффективная мера, которую мы приняли.
По итогу: замена Cloudflare на TrafficVeil у нас заняла меньше недели вместе с динамическим whitelist. Попытки брутфорса упали на 99%, сотрудники на удалёнке работают без жалоб, а сайт открывается отовсюду, откуда нужно. Альтернатива Cloudflare, которая не ломает доступ и не выставляет счёт за атаки, оказалась ровно тем, что мы искали.
Если ваш WordPress уже ловит по несколько тысяч попыток входа в сутки и вы устали от блокировок Cloudflare на стороне российских провайдеров, начните с малого: заведите бесплатный аккаунт TrafficVeil, переведите на его NS-записи домен и включите reverse proxy для основного сайта. На это уходит от 20 минут до пары часов в зависимости от того, как быстро обновятся DNS у регистратора. Дальше не спешите сразу закрывать wp-login.php для всех: сначала соберите статистику за 3-5 дней, посмотрите в аналитике TrafficVeil, с каких IP и подсетей идёт нагрузка, и только потом формируйте список разрешённых адресов. Так вы не отрежете случайно собственного подрядчика или SEO-специалиста, который ходит с динамического IP.
Для динамического whitelist держите в голове три практических момента. Первый: если офис или удалёнщики сидят за VPN, привязывайте правило не к конкретному адресу, а к подсети выходного шлюза, например /29 или /28, иначе после каждого переподключения придётся править конфиг вручную. Второй: держите резервный путь в админку, отдельный IP или доступ через SSH-туннель, на случай если whitelist случайно заблокирует вас самих. Третий: включите GeoIP-фильтрацию как второй слой, разрешив трафик к wp-admin только из России и стран, где реально работают ваши сотрудники, а всё остальное отправляйте в блок на уровне L7. По деньгам TrafficVeil не тарифицирует ботов, атаки и WAF-блокировки, поэтому рост числа запросов при брутфорсе не превращается в счёт на оплату. Если хотите проверить решение без риска, оставьте текущий Cloudflare на резервном домене, а основной переключите на TrafficVeil и сравните метрики за две недели: время отклика, долю заблокированных запросов и удобство работы команды. Такой параллельный прогон даёт честную картину и снимает вопрос, стоит ли менять привычную инфраструктуру.