Исправить неверный IP в WordPress

Скриншот панели комментариев WordPress с IP-адресом 127.0.0.1

Почему WordPress показывает 127.0.0.1 или IP прокси

Когда сайт находится за обратным прокси, балансировщиком нагрузки или CDN (например, Cloudflare), реальный IP клиента часто добавляется в HTTP-заголовок X-Forwarded-For или в специальный заголовок провайдера. По умолчанию PHP/вебсервер помещает в $_SERVER[‘REMOTE_ADDR’] адрес соединения между прокси и сервером — это может быть 127.0.0.1 при локальном проксировании. Чтобы WordPress и плагины видели реальный IP, нужно явно восстановить REMOTE_ADDR из доверенного заголовка.

Важно: заголовки, которые передают IP, легко подделать, если их принимает сервер напрямую от неизвестных клиентов. Всегда фильтруйте по списку доверенных прокси.

Подготовка: резервная копия

Перед правкой любых файлов WordPress сделайте резервную копию wp-config.php и/или конфигурации сервера. Это позволит быстро откатить изменения при ошибке.

Быстрое исправление: правка wp-config.php

Откройте wp-config.php через FTP/SFTP или файловый менеджер хостинга и добавьте в конец файла (до строки “/ That’s all, stop editing! /“ если она есть) следующий фрагмент:

// Code for showing correct client IP address
if(isset($_SERVER['HTTP_X_FORWARDED_FOR'])){
    $mte_xffaddrs=explode(',',$_SERVER['HTTP_X_FORWARDED_FOR']);
    $_SERVER['REMOTE_ADDR']=$mte_xffaddrs[0];
}

Открытие файла wp-config.php в FTP-клиенте

Этот код берёт первый IP из X-Forwarded-For и ставит его в REMOTE_ADDR. Для некоторых конфигураций (когда прокси добавляет IP в конец списка) может потребоваться взять последний элемент — всё зависит от того, как устроен ваш стек.

Вставка кода в конец wp-config.php

Исправление для Cloudflare

Если вы используете Cloudflare, можно использовать специальный заголовок HTTP_CF_CONNECTING_IP, который Cloudflare передаёт с реальным клиентским IP:

// Fix incorrect IP when using Cloudflare
if(array_key_exists('HTTP_CF_CONNECTING_IP',$_SERVER)){
    $_SERVER['REMOTE_ADDR']=$_SERVER['HTTP_CF_CONNECTING_IP'];
}

Это простое и рабочее решение, но безопаснее проверять, что запрос действительно пришёл от Cloudflare (по диапазону их IP) перед доверительной заменой REMOTE_ADDR.

Плагин: если не хотите править файлы

Можно установить плагин Proxy Real IP — он делает ту же задачу (разбирает заголовки и устанавливает REMOTE_ADDR). Плагин не требует настроек:

Установка плагина Proxy Real IP в админке WordPress

Если вы управляете корпоративным сайтом, лучше выбирать поддерживаемые и регулярно обновляемые плагины.

Серверное решение (рекомендуется для производственных систем)

Лучше всего решать вопрос на уровне веб-сервера: nginx и Apache имеют модули для корректной обработки реального IP.

Пример для nginx (real_ip_module):

# доверять только IP вашего балансировщика/Cloudflare
set_real_ip_from 203.0.113.0/24; # пример диапазона, замените на реальные
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Для Cloudflare вместо 203.0.113.0/24 используйте официальные CIDR-диапазоны Cloudflare, опубликованные у них.

Пример для Apache (mod_remoteip):

RemoteIPHeader X-Forwarded-For
RemoteIPTrustedProxy 203.0.113.0/24

После настройки сервер корректно заполнит REMOTE_ADDR и WordPress не потребует вмешательства в wp-config.php.

Безопасность и случаи, когда метод не работает

X-Forwarded-For можно подделать, если сервер принимает заголовки от неизвестных клиентов. Всегда указывайте список доверенных прокси/балансировщиков.
Если у вас несколько уровней проксирования, позиция реального IP в X-Forwarded-For может отличаться (иногда первый элемент — клиент, иногда последний). Проверьте поведение вашей цепочки прокси.
Некоторые хостинги/панели уже корректно настраивают REMOTE_ADDR — дополнительный код не требуется и может помешать.
Плагины и плагины безопасности могут читать IP иначе; тестируйте всё на staging перед внедрением в прод.

Проверка и отладка

Шаги для проверки работы:

Очистите кэш сервера/плагинов и браузера.
Откройте страницу, оставьте комментарий с тестового устройства и проверьте IP в админке.
Используйте var_dump($_SERVER) в тестовом PHP-скрипте или логируйте $_SERVER[‘REMOTE_ADDR’] и $_SERVER[‘HTTP_X_FORWARDED_FOR’] чтобы увидеть реальные значения.
Если используете nginx/Apache, проверьте access_log — там должна быть клиентская цепочка.

Критерии приёмки

В админке WordPress в колонке IP и в логах виден реальный IP посетителя.
Известные прокси/балансировщики указаны в конфигурации сервера или проверены в коде.
Нет возможности для обычного клиента подменить свой IP через заголовки.

Контроль подделки заголовков — пример более безопасной проверки в PHP

// Безопасный пример: доверяем X-Forwarded-For только если соединение с известного прокси
$trusted_proxies = ['203.0.113.0/24','198.51.100.0/24']; // замените на реальные CIDR
$client_ip = $_SERVER['REMOTE_ADDR'];
$is_trusted = false;
foreach($trusted_proxies as $cidr){
    if(ip_in_cidr($client_ip, $cidr)) { $is_trusted = true; break; }
}
if($is_trusted && !empty($_SERVER['HTTP_X_FORWARDED_FOR'])){
    $xff = explode(',', $_SERVER['HTTP_X_FORWARDED_FOR']);
    $candidate = trim($xff[0]);
    if(filter_var($candidate, FILTER_VALIDATE_IP)){
        $_SERVER['REMOTE_ADDR'] = $candidate;
    }
}

// Функция ip_in_cidr — реализация проверки IP в CIDR (пример опущен, используйте готовую библиотеку)

Примечание: не придумывайте собственную реализацию проверки CIDR, если нет уверенности — используйте проверенные библиотеки.

Чеклист при внедрении (роли)

Для администратора сайта:

Сделать резервную копию wp-config.php и конфигурации сервера
Уведомить команду о возможном влиянии на логи/плагины
Протестировать на staging окружении

Для разработчика/инфраструктуры:

Настроить real_ip на уровне nginx/Apache (предпочтительно)
Подключить и обновить список доверенных прокси (CIDR)
Добавить тесты/логирование для REMOTE_ADDR

Дополнительные подходы и альтернативы

Использовать коммерческие/официальные модули CDN/балансировщиков для восстановления IP.
Попросить хостера настроить real IP на их стороне, если у вас нет доступа к серверу.
Плагин WordPress, который корректно обрабатывает X-Forwarded-For и проверяет доверенные прокси.

Ментальные модели и короткие подсказки

REMOTE_ADDR = адрес TCP-соединения (между вашим сервером и ближайшим узлом в цепочке).
X-Forwarded-For = список IP через запятую, обычно первый элемент — клиент (но всегда проверьте конкретную цепочку).
Доверяй, но проверяй: разрешайте заменять REMOTE_ADDR только от известных прокси.

Диаграмма принятия решения

flowchart TD
  A[Сайт показывает 127.0.0.1 или IP прокси?] -->|Нет| B[Ничего не менять]
  A -->|Да| C[Есть доступ к конфигурации сервера?]
  C -->|Да| D[Настроить nginx real_ip / Apache mod_remoteip]
  C -->|Нет| E[Добавить проверку в wp-config.php или установить плагин]
  D --> F[Добавить доверенные CIDR]
  E --> G[Проверить X-Forwarded-For или HTTP_CF_CONNECTING_IP]
  F --> H[Тестирование в staging]
  G --> H
  H --> I[Внедрение в прод]

Глоссарий (в одной строке)

X-Forwarded-For — HTTP-заголовок, содержащий цепочку IP от клиента через промежуточные прокси.
REMOTE_ADDR — значение IP, которое PHP видит как адрес соединения.
real_ip_module/mod_remoteip — модули nginx/Apache для корректной обработки реального IP.

Итог

Самое простое и быстрое решение — добавить короткий фрагмент в wp-config.php или установить плагин. Для надёжности и безопасности предпочтительнее настроить восстановление реального IP на уровне веб-сервера и ограничить доверенные прокси/диапазоны IP. Всегда тестируйте изменения на staging и проверяйте, что заголовки не могут быть подделаны внешними клиентами.