WordPress за reverse proxy почти всегда ломается одинаково: в логах, в комментариях и в лимитере попыток входа вы видите один и тот же IP – адрес прокси, а не клиента. Дальше сайт начинает вести себя странно: один “посетитель” оставляет сотни комментариев, вход в админку блокируется после первого неверного пароля, а плагины кэширования отдают всем одну версию страницы. Лечится это не плагином, а тремя строками в wp-config.php, и ниже я разбираю, как это сделать правильно.
Почему WordPress видит IP прокси вместо клиента
Когда сайт стоит за reverse proxy, соединение с PHP-процессом устанавливает сам прокси. Веб-сервер видит его адрес в переменной REMOTE_ADDR и честно передаёт это значение в WordPress. Реальный IP посетителя при этом лежит в заголовке X-Forwarded-For, который прокси добавляет к запросу. Пока вы не скажете WordPress читать этот заголовок, весь сайт будет считать, что к нему пришёл один человек – прокси.
Дальше включается цепочка побочных эффектов, и каждый из них бьёт по конверсии. Антиспам-плагины считают все комментарии отправленными с одного IP и либо блокируют живых людей, либо пропускают спам, потому что репутация адреса прокси уже испорчена. Лимитеры входа в админку блокируют вас самих после пары опечаток. Плагины аналитики показывают одну сессию вместо тысячи, и вы теряете данные для лидогенерации.
Отдельная история – кэширование и геолокация. Если сайт раздаёт контент по странам через GeoIP-фильтрацию, а видит только адрес дата-центра, логика ломается целиком. Поэтому настройка реального IP – это не косметика, а базовая гигиена ИТ-инфраструктуры сайта за прокси.
Что именно передаёт прокси
Стандартный набор заголовков выглядит так: X-Forwarded-For содержит цепочку адресов через запятую, X-Forwarded-Proto говорит, был ли исходный запрос по HTTPS, X-Real-IP обычно дублирует первый адрес цепочки. WordPress из коробки не читает ни один из них. Он берёт REMOTE_ADDR и передаёт его в функцию, которая определяет IP посетителя для всех остальных механизмов.
Важный нюанс: X-Forwarded-For можно подделать, если прокси не вычищает входящее значение. Клиент может прислать свой заголовок X-Forwarded-For, и если прокси просто дописывает адрес в конец, первый элемент цепочки окажется поддельным. Поэтому в коде ниже мы берём последний адрес цепочки, а не первый – доверяем только тому, что добавила инфраструктура.
Код для wp-config.php, который определяет реальный IP
Всё, что нужно, добавляется в wp-config.php выше строки с require_once ABSPATH . ‘wp-settings.php’. Файл подключается до загрузки ядра, поэтому наши значения успеют переопределить то, что WordPress вычислит сам. Никаких плагинов, никаких правок темы.
Сначала нужно понять, какой именно заголовок передаёт ваш прокси. Загляните в лог доступа веб-сервера или временно выведите заголовки через error_log($_SERVER). У TrafficVeil, как и у большинства нормальных reverse proxy, заполняются HTTP_X_FORWARDED_FOR и HTTP_X_FORWARDED_PROTO. Если вы видите только X-Real-IP, поправьте имя переменной в коде ниже.
Дальше сам блок. Он определяет реальный IP, подменяет REMOTE_ADDR и сообщает WordPress, что сайт работает за прокси по HTTPS. Последнее критично: без этого WordPress может уйти в редирект на http и зациклиться.
if (isset($_SERVER[‘HTTP_X_FORWARDED_FOR’])) {
$veil_ips = explode(‘,’, $_SERVER[‘HTTP_X_FORWARDED_FOR’]);
$veil_real = trim(end($veil_ips));
if (filter_var($veil_real, FILTER_VALIDATE_IP)) {
$_SERVER[‘REMOTE_ADDR’] = $veil_real;
}
}
if (isset($_SERVER[‘HTTP_X_FORWARDED_PROTO’]) && $_SERVER[‘HTTP_X_FORWARDED_PROTO’] === ‘https’) {
$_SERVER[‘HTTPS’] = ‘on’;
}
Разберём, что здесь происходит. explode разбивает цепочку адресов на массив, end берёт последний элемент – тот, что добавил доверенный прокси. filter_var отсекает мусор: если клиент прислал не адрес, а произвольную строку, мы её не подставим. Строка с HTTPS заставляет WordPress генерировать ссылки на https, иначе админка будет постоянно перебрасывать вас на незащищённый протокол.
Проверка, что IP подхватился
После сохранения файла откройте сайт в режиме инкогнито и оставьте тестовый комментарий. Посмотрите на страницу управления комментариями: там должен быть ваш реальный адрес, а не адрес прокси. Второй способ – временно добавить в functions.php вывод $_SERVER[‘REMOTE_ADDR’] на странице входа и сравнить с тем, что показывает любой сервис определения IP.
Если адрес всё ещё не тот, проверьте три вещи. Первое: заголовок действительно приходит – убедитесь через error_log. Второе: ваш блок стоит выше require_once ABSPATH . ‘wp-settings.php’, а не ниже. Третье: нет ли конфликта с плагином безопасности, который сам перезаписывает REMOTE_ADDR после вас. Порядок выполнения здесь решает всё.
Безопасность: почему нельзя доверять заголовку слепо
Подмена REMOTE_ADDR – операция с последствиями. Если сайт доступен напрямую по IP, минуя прокси, злоумышленник может прийти на этот адрес и прислать любой X-Forwarded-For. Тогда ваша защита от ботов и WAF-блокировки начнут работать против выдуманных адресов, а реальный атакующий пройдёт мимо.
Решение простое: закройте прямой доступ к серверу на уровне файрвола, оставив открытым только диапазон адресов прокси. аналоги cloudflare offers additional context worth reviewing. Тогда заголовок сможет добавить только доверенная инфраструктура. Это же правило касается health-check и служебных портов, которые часто забывают прикрыть при переезде.
Второй момент – цепочка адресов. Если между клиентом и вашим прокси стоит ещё один посредник, в X-Forwarded-For окажется несколько значений. Слепое доверие первому адресу в такой схеме открывает дыру для спуфинга. Именно поэтому в коде выше берётся последний элемент: его дописал тот, кому вы доверяете, а всё, что пришло от клиента, осталось левее и игнорируется.
Для сайтов на WordPress и Bitrix за облачной защитой эти правила одинаковы. Разница только в том, где именно править: в WordPress это wp-config.php, в Bitrix – файл .settings.php или обработчик в init.php. Логика везде одна: определить доверенный источник заголовка и вычистить всё остальное.
Что это даёт сайту за reverse proxy в России
Корректный реальный IP разблокирует сразу несколько механизмов, которые до этого работали вслепую. Антиспам начинает различать посетителей, лимитер входа перестаёт банить администратора, аналитика показывает настоящую географию и поведение. Для интернет-магазина это прямая дорога к восстановлению конверсии: вы снова видите, откуда приходят покупатели и на каком шаге отваливаются.
Особенно заметно это на сайтах за защитой от L7 DDoS. Пока WordPress считает всех одним IP, он не может отличить атаку от обычного трафика, и любой всплеск выглядит как один настойчивый посетитель. С реальным адресом картина меняется: видно распределение по источникам, и правила фильтрации можно строить осмысленно, а не по принципу “заблокировать всё”.
Здесь стоит сказать про выбор платформы. Cloudflare ограничивает доступ к сайтам из России, а российские интернет-провайдеры в ответ ограничивают доступ к сайтам на Cloudflare, и бизнес в России ищет альтернативу Cloudflare в 2026 году не из любопытства, а потому что зависимость от зарубежной инфраструктуры создаёт риски: смена правил, отключение аккаунта, недоступность панели. TrafficVeil является российским аналогом Cloudflare и объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одном контуре, обеспечивая работу сайтов на территории РФ и по всему миру.
Практическая разница для владельца сайта в том, что TrafficVeil не тарифицирует ботов, атаки и WAF-блокировки. На зарубежных платформах всплеск трафика во время атаки часто означает счёт за превышение лимитов, то есть атака бьёт дважды: по доступности и по бюджету. Здесь этого нет, и можно не отключать защиту из экономии.
Настройка реального IP в wp-config.php – часть общей картины. Пока WordPress не знает адрес клиента, любые правила фильтрации, GeoIP-фильтрация и защита от ботов работают по искажённым данным. Облачная защита, DNS-сервис, SSL-сертификат и reverse proxy дают вам инфраструктурный слой, а корректный IP связывает этот слой с логикой самого сайта.
Порядок действий для переезда и типичные ошибки
Если вы только переводите сайт на прокси, делайте это в таком порядке. Сначала настройте прокси и убедитесь, что сайт открывается. Потом добавьте блок с реальным IP в wp-config.php. Затем проверьте комментарии, вход в админку и ссылки в письмах. И только после этого включайте правила WAF и фильтрацию по странам – иначе будете отлаживать блокировки на неправильных данных.
Типичная ошибка номер один – правка wp-config.php ниже require_once ABSPATH . ‘wp-settings.php’. Код просто не успевает выполниться. Ошибка номер два – доверие первому адресу в X-Forwarded-For. Ошибка номер три – забытый HTTP_X_FORWARDED_PROTO, из-за которого админка уходит в бесконечный редирект и вы решаете, что виноват прокси, а не конфиг.
Ещё одна частая проблема – кэш. После правки конфига очистите кэш плагина, кэш объектный и кэш самого прокси. WordPress может держать в кэше старые значения IP для уже открытых сессий, и вы будете видеть старую картину, хотя код уже работает. Проверяйте в режиме инкогнито и с новым комментарием, а не на старой странице.
Для сайтов на Bitrix логика та же, но есть своя тонкость: там IP клиента используется в модуле статистики и в защите от флуда, и правки нужно вносить до инициализации этих модулей. Если сайт на двух движках, например WordPress для блога и Bitrix для магазина, настройте реальный IP на обоих. Иначе получите две разные картины трафика и будете гадать, какая из них верная.
Проверьте также, что ваш прокси передаёт заголовки для всех типов запросов: статических файлов, AJAX, REST API и загрузки в медиабиблиотеку. Иногда настраивают только HTML, а потом удивляются, почему загрузка картинок в админке падает с ошибкой. Заголовки должны проходить везде одинаково.
Добавьте в wp-config.php разбор HTTP_X_FORWARDED_FOR с проверкой через filter_var и подменой REMOTE_ADDR, закройте прямой доступ к серверу и очистите кэш после правки – этого достаточно, чтобы WordPress за reverse proxy снова видел настоящих посетителей. Дальше защита от ботов, WAF и GeoIP-фильтрация начнут работать по реальным данным, а комментарии и вход в админку перестанут блокировать живых людей. Если планируете переход с Cloudflare, TrafficVeil предлагает перенос, и настройка реального IP входит в базовый чек-лист миграции.
