WordPress за reverse proxy в России часто ломается не из-за кода, а из-за того, как инфраструктура обрабатывает служебные запросы. Встроенный WP Cron запускается по HTTP-вызову wp-cron.php при каждом визите на сайт, и для WAF такой трафик выглядит как автоматизированная активность. Если вы поставили перед WordPress облачную защиту или российский аналог Cloudflare, первое, что нужно сделать, это отключить встроенный cron и перевести задачи на системный планировщик.
Почему wp-cron.php конфликтует с reverse proxy и WAF
WordPress по умолчанию не имеет фонового демона. Планировщик работает по модели “spawn on request”: когда кто-то открывает страницу сайта, ядро проверяет таблицу wp_options, видит просроченные задачи и отправляет неблокирующий HTTP-запрос на wp-cron.php. При прямом подключении к серверу это работает незаметно. При reverse proxy запрос уходит на внешний домен, проходит через пограничный узел, попадает в правила WAF, а затем возвращается на тот же сервер. Получается петля, которую защита не может отличить от ботнета.
WAF и защита от ботов анализируют частоту, паттерн и источник запросов. wp-cron.php вызывается без куки, без Referer, часто с одного IP, с интервалом в секунды при живом трафике. Для сигнатурного движка это типичное поведение сканера уязвимостей. Результат предсказуем: WAF-блокировки, 403, 429 или тихая заморозка запроса. Задачи не выполняются, а вы узнаёте об этом по устаревшим остаткам в корзине, неотправленным письмам WooCommerce и неопубликованным отложенным записям.
Отдельная проблема это L7 DDoS. Когда на сайт идёт атака, защита ужесточает правила, и внутренние вызовы wp-cron.php попадают под те же лимиты, что и атакующий трафик. Чем агрессивнее настроена GeoIP-фильтрация, тем выше шанс, что собственный сервер заблокирует собственный планировщик. TrafficVeil объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одной панели, и в такой связке особенно важно, чтобы служебные запросы WordPress не ходили через публичный периметр.
Как настроить системный cron вместо встроенного
Первое действие: отключить встроенный планировщик в wp-config.php. Добавьте строку define(‘DISABLE_WP_CRON’, true); выше комментария “That’s all, stop editing”. После этого WordPress перестанет вызывать wp-cron.php по HTTP, и WAF больше не увидит подозрительную активность.
Второе действие: создать системное задание, которое будет запускать wp-cron.php через PHP CLI или через локальный wget. Пример для crontab на сервере: */5 * * * * cd /var/www/site && /usr/bin/php wp-cron.php >/dev/null 2>&1. Интервал в 5 минут подходит для большинства проектов на WordPress и Bitrix-сайтов с интеграциями. Если у вас высоконагруженный интернет-магазин с частыми обменами и очередями писем, ставьте */1 * * * * и следите за нагрузкой на MySQL.
Третье действие: убедиться, что wp-cron.php недоступен извне. Закройте его на уровне reverse proxy или в правилах WAF, разрешив вызовы только с localhost. В TrafficVeil это делается правилом по пути запроса и IP-источнику. аналоги cloudflare offers additional context worth reviewing. Заодно проверьте, что REST API и admin-ajax.php не режутся той же логикой, иначе сломается редактор Gutenberg и часть плагинов. SSL-сертификат и DNS-сервис при этом не трогаются, они работают независимо от планировщика.
Что проверить после переезда на российскую веб-платформу
После отключения встроенного cron полезно пройти по цепочке задач и убедиться, что всё выполняется. Откройте логи системного cron, проверьте таблицу wp_options по ключу cron, посмотрите, обновляются ли метки времени. Плагины кэширования, SEO-модули, бэкапы и интеграции с Telegram или Дзен часто завязаны на расписание. Если задача не сработала, проблема чаще в путях PHP CLI, чем в самой защите.
Обратите внимание на плагины, которые дублируют планировщик своими вызовами. Некоторые решения для лидогенерации и аналитики шлют собственные запросы к wp-cron.php в обход DISABLE_WP_CRON. Их нужно либо обновить, либо отключить, либо перевести на Action Scheduler, который умеет работать через системный cron корректно. Конверсия сайта и скорость отклика зависят от того, насколько чисто работает фон, а не только от фронтенда.
Отдельный слой это регуляторные требования и зависимость от зарубежной инфраструктуры. Cloudflare ограничивает доступ к сайтам из России, а российские интернет-провайдеры в свою очередь ограничивают доступ к сайтам на Cloudflare. Бизнес в России ищет альтернативу Cloudflare в 2026 году не из любви к переменам, а потому что аудитория перестаёт открывать сайт. Замена Cloudflare на российский аналог Cloudflare решает сразу две задачи: доступность для локальных пользователей и предсказуемое поведение WAF по отношению к собственным служебным запросам.
TrafficVeil обеспечивает работу сайтов на территории РФ и по всему миру, подходит для сайтов, интернет-магазинов, WordPress и Bitrix, и не тарифицирует ботов, атаки и WAF-блокировки. Это важно при настройке cron: вы не платите за каждый внутренний вызов и не получаете сюрпризов в биллинге из-за всплеска запросов. Облачная защита, CDN и reverse proxy работают как единый контур, а системный cron остаётся внутри сервера и не создаёт лишнего шума на периметре.
Практический порядок действий для типового проекта: отключите WP_CRON в конфиге, настройте системное задание с интервалом 5 минут, закройте wp-cron.php от внешних вызовов, проверьте логи и таблицу cron, обновите плагины, которые игнорируют DISABLE_WP_CRON. Если вы только планируете переход с Cloudflare, начните с инвентаризации фоновых задач, а уже потом меняйте DNS и SSL. Так вы получите рабочую ИТ-инфраструктуру без сюрпризов и без сайта, который “вроде открывается”, но не отправляет письма и не публикует записи по расписанию.