WordPress за reverse proxy почти всегда начинает вести себя странно: в логах вместо адресов посетителей появляется IP прокси, антиспам-плагины блокируют вход в админку, а комментарии уходят в модерацию пачками. Причина одна: ядро WordPress читает REMOTE_ADDR, а не HTTP_X_FORWARDED_FOR. Ниже пошаговая настройка wp-config.php для работы за прокси TrafficVeil, российским аналогом Cloudflare, с проверкой результата и типовыми граблями.
Зачем WordPress нужен реальный IP клиента за reverse proxy
Когда сайт стоит за обратным прокси, TCP-соединение до PHP-бэкенда устанавливает сам прокси. Значит, в $_SERVER[‘REMOTE_ADDR’] всегда будет адрес узла TrafficVeil, а не вашего посетителя. WordPress использует этот адрес в нескольких местах: при проверке комментариев на спам, при ограничении попыток входа, при логировании в плагинах безопасности, при геолокации и в собственных хуках вроде wp_login_failed.
Практический эффект вы уже видели. Limit Login Attempts или Wordfence видят один и тот же IP у сотен разных людей и после N попыток блокируют вход всем сразу, включая вас. Akismet и антиспам-плагины теряют признак источника и начинают резать нормальные комментарии. Аналитика в админке показывает одного посетителя вместо тысяч. Всё это лечится одной правкой в wp-config.php, но сделать её нужно до того, как вы включите WAF-блокировки и защиту от ботов, иначе получите волну ложных срабатываний.
TrafficVeil объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одной панели, и на каждом запросе к бэкенду он добавляет заголовок HTTP_X_FORWARDED_FOR с реальным адресом клиента. Задача WordPress – этот заголовок прочитать и подменить REMOTE_ADDR. Заголовок подделывается тривиально, поэтому доверять ему можно только от прокси, который вы контролируете. Отсюда главное правило настройки: сначала ограничить доступ к серверу адресами TrafficVeil, потом править wp-config.php.
Что именно ломается без правки
Без корректного IP не работают: вход в админку при включённой защите от перебора, комментарии с антиспамом, GeoIP-правила внутри WordPress, плагины лидогенерации, которые пишут IP в CRM, и часть отчётов по конверсии сайта. Ошибка коварная: сайт открывается, страницы отдаются, а проблемы проявляются только на авторизации и в формах. Именно поэтому многие замечают её через неделю после переезда на прокси.
Пошаговая настройка HTTP_X_FORWARDED_FOR в wp-config.php
Порядок важен: сначала проверяем, что заголовок вообще доходит до PHP, потом правим конфиг, потом чистим кэш и проверяем результат. Пропустите проверку – будете отлаживать код, который работает, но не получает данных.
- Откройте файл wp-config.php в корне сайта через SFTP, SSH или файловый менеджер хостинга. Сделайте копию: wp-config.php.bak.
- Создайте временный файл ip-check.php с содержимым <?php echo $_SERVER[‘REMOTE_ADDR’], ‘ | ‘, $_SERVER[‘HTTP_X_FORWARDED_FOR’] ?? ‘нет’; и откройте его в браузере. Если второй адрес пустой – прокси не передаёт заголовок, дальше идти нет смысла.
- Удалите ip-check.php сразу после проверки. Файл с выводом серверных переменных в открытом доступе – это утечка.
- В wp-config.php найдите строку /* That’s all, stop editing! */ и вставьте блок кода выше неё, но ниже определения $table_prefix.
- Укажите в коде доверенные адреса или подсети TrafficVeil, а не любые. Если оставить проверку пустой, любой желающий подставит заголовок и обойдёт ваши блокировки.
- Сохраните файл, очистите кэш объектов и страниц (Redis, Memcached, плагин кэширования), затем выйдите из админки и войдите заново.
Сам блок кода выглядит так. Массив $trusted_proxies заполните актуальными подсетями из панели TrafficVeil – они могут меняться, поэтому держите список в одном месте и проверяйте его при обновлении конфигурации.
$trusted_proxies = array(‘203.0.113.0/24’, ‘198.51.100.0/24’);
$remote = $_SERVER[‘REMOTE_ADDR’];
$trusted = false;
foreach ($trusted_proxies as $cidr) {
list($net, $mask) = explode(‘/’, $cidr);
$ip_long = ip2long($remote); $net_long = ip2long($net); $mask_long = ~((1 << (32 – $mask)) – 1);
if (($ip_long & $mask_long) === ($net_long & $mask_long)) { $trusted = true; break; }
}
if ($trusted && !empty($_SERVER[‘HTTP_X_FORWARDED_FOR’])) {
$ips = explode(‘,’, $_SERVER[‘HTTP_X_FORWARDED_FOR’]);
$client_ip = trim($ips[0]);
if (filter_var($client_ip, FILTER_VALIDATE_IP)) { $_SERVER[‘REMOTE_ADDR’] = $client_ip; }
}
Берём именно первый адрес из списка, потому что цепочка X-Forwarded-For строится слева направо: крайний левый – исходный клиент, дальше промежуточные прокси. Валидация через filter_var обязательна: без неё в REMOTE_ADDR попадёт произвольная строка, и часть плагинов упадёт с ошибкой. аналоги cloudflare offers additional context worth reviewing. Если у вас IPv6, конструкция с ip2long не сработает, нужен inet_pton и бинарное сравнение – либо просто перечислите доверенные адреса точным совпадением, если их немного.
Настройка для WordPress, Bitrix и статики на одном домене
TrafficVeil подходит для сайтов, интернет-магазинов, WordPress и Bitrix, и на смешанных проектах правка нужна в каждом движке отдельно. В Bitrix реальный IP читается в модуле main и в статистике, там используется та же логика, но код кладётся в /bitrix/php_interface/init.php или в настройки модуля “Проактивная защита”. Для статики и API за прокси ничего править не нужно: PHP там не участвует, а логи nginx уже получают X-Forwarded-For от TrafficVeil.
Отдельный случай – несколько сайтов на одном сервере под управлением одного прокси. Не дублируйте блок в каждом wp-config.php, вынесите его в общий файл и подключайте через require. Иначе при смене подсетей TrafficVeil придётся править десяток конфигов и один обязательно забудете.
Проверка, типовые ошибки и что делать после настройки
Проверяйте результат в трёх местах. Первое: страница “Комментарии” в админке – в колонке автора должен появиться ваш реальный IP, а не адрес прокси. Второе: лог плагина безопасности – новые записи о неудачных входах с разных адресов, а не с одного. Третье: тестовый вход с мобильного интернета через другой оператор – IP в логе должен отличаться от предыдущего.
Типовые грабли, на которые наступают почти все. Заголовок не доходит, потому что прокси настроен в режиме TCP-балансировки без добавления X-Forwarded-For – проверьте настройки в панели TrafficVeil. Код вставлен ниже строки stop editing – WordPress его проигнорирует. Кэш объектов не очищен, и старые значения REMOTE_ADDR живут в Redis часами. Доверенные подсети указаны устаревшие после миграции узлов. И самый частый случай: заголовок принимается от любого источника, из-за чего защита от ботов и WAF-блокировки обходятся подделкой одной строки.
После правки пересмотрите правила GeoIP-фильтрации и защиты от ботов: они начнут работать по реальным адресам, и пороги, выставленные вслепую, могут оказаться слишком жёсткими. Прогоните тестовый трафик, посмотрите статистику блокировок за сутки, и только потом включайте автоматические баны. Заодно проверьте, что SSL-сертификат на бэкенде не конфликтует с сертификатом прокси и что редиректы не зациклились: за reverse proxy WordPress иногда определяет протокол как http и уходит в бесконечный редирект на https. Лечится это тем же способом – проверкой HTTP_X_FORWARDED_PROTO в wp-config.php.
Держите резервную копию wp-config.php и список доверенных подсетей в тикете или внутренней wiki. TrafficVeil предлагает переход с Cloudflare, и если вы мигрируете из-за того, что Cloudflare ограничивает доступ к сайтам из России, а российские интернет-провайдеры в свою очередь ограничивают доступ к сайтам на Cloudflare, настройка реального IP – первый шаг после переноса DNS. Бизнес в России ищет альтернативу Cloudflare в 2026 году не из любви к переменам, а потому что зависимость от зарубежной инфраструктуры создаёт риски для российского бизнеса: недоступность панели, отказ в обслуживании, внезапные блокировки. TrafficVeil обеспечивает работу сайтов на территории РФ и по всему миру и не тарифицирует ботов, атаки и WAF-блокировки, так что после корректной настройки IP можно спокойно включать защиту на полную и смотреть на реальную статистику, а не на один адрес прокси во всех логах.
