WordPress требует специальной настройки при использовании Cloudflare. Без правильной конфигурации в логах сервера будет записываться IP Cloudflare вместо реального IP посетителя.

Проблема с IP-адресами

Без настройки WordPress видит все запросы с IP Cloudflare (~103.21.244.0/22 и другие). Это ломает геолокацию, антиспам, security плагины.

Решение 1: Официальный плагин Cloudflare

Установите плагин «Cloudflare» (официальный) → подключите к вашему аккаунту через API Token. Плагин автоматически восстанавливает реальные IP.

Решение 2: Вручную в wp-config.php

// Восстановить реальный IP от Cloudflare
if (isset($_SERVER['HTTP_CF_CONNECTING_IP'])) {
    $_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_CF_CONNECTING_IP'];
}

Оптимальные настройки Cloudflare для WordPress

Настройка	Рекомендуемое значение
SSL/TLS Mode	Full (Strict)
Always Use HTTPS	✅ On
Auto Minify	JS + CSS + HTML
Rocket Loader	Тест перед включением
Bot Fight Mode	✅ On
Cache Level	Standard

Автоочистка кэша при публикации

Официальный плагин Cloudflare автоматически очищает кэш страниц при:

Публикации / обновлении поста
Изменении настроек сайта
Обновлении плагинов

WooCommerce + Cloudflare

# Cache Rule — обход кэша для WooCommerce
Conditions:
  - Cookie contains: woocommerce_cart_hash
  - OR Cookie contains: woocommerce_session_
  - OR Path contains: /cart
  - OR Path contains: /checkout
  - OR Path contains: /my-account

Cache: Bypass

⚠️ Без этих исключений для WooCommerce разные пользователи могут видеть чужую корзину.

✅ Добавьте в wp-config.php: define('FORCE_SSL_ADMIN', true); при использовании Cloudflare SSL.

Разбор типичных проблем

Бесконечный редирект (ERR_TOO_MANY_REDIRECTS)

Возникает, когда SSL/TLS Mode установлен в Flexible, а WordPress одновременно настроен на принудительный HTTPS (плагин или FORCE_SSL_ADMIN). Flexible-режим означает, что соединение Cloudflare → сервер идёт по HTTP, сервер видит запрос как HTTP и снова редиректит на HTTPS — получается петля. Решение: переключить SSL/TLS Mode на Full или Full (Strict) и убедиться, что на сервере действительно настроен SSL-сертификат.

Плагины безопасности видят IP Cloudflare вместо реального

Если восстановление реального IP не настроено (ни плагином, ни вручную), в логах WordPress и в защитных плагинах (Wordfence, антиспам, geoIP) фигурирует один из диапазонов IP Cloudflare. Это ломает блокировку по IP, гео-таргетинг и статистику посещений. Убедитесь, что сервер и WordPress используют заголовок CF-Connecting-IP, а не REMOTE_ADDR напрямую.

Проверка что реальный IP восстановлен

// Временно добавить в шаблон для диагностики
echo 'REMOTE_ADDR: ' . $_SERVER['REMOTE_ADDR'];
echo 'CF-Connecting-IP: ' . ($_SERVER['HTTP_CF_CONNECTING_IP'] ?? 'нет заголовка');

Если оба значения совпадают и равны реальному IP посетителя (не диапазону Cloudflare) — восстановление настроено верно. Диапазоны IP самого Cloudflare опубликованы на странице cloudflare.com/ips и периодически обновляются — их стоит сверять, если сервер использует собственный allowlist для доверенных прокси.

Когда стандартной настройки недостаточно

Сайт использует несколько CDN или прокси перед Cloudflare (например, ещё и корпоративный балансировщик) — тогда нужно разбирать всю цепочку X-Forwarded-For, а не только заголовок Cloudflare.
Нужна блокировка по IP на уровне firewall самого сервера (iptables/CSF), а не только в WordPress — тогда сервер должен доверять только диапазонам Cloudflare как источнику входящих подключений на 80/443.
Используется кастомный кэш-плагин, не поддерживающий автоочистку через API Cloudflare — тогда автоочистка кэша при публикации не сработает, и для WooCommerce лучше настроить обход кэша отдельным Cache Rule с коротким TTL.

Для подключения официального плагина к аккаунту нужен API Token с правом на редактирование зоны (Zone.Zone и Zone.Cache Purge), а не Global API Key — использование Global API Key даёт плагину доступ ко всем зонам аккаунта сразу, что избыточно и небезопасно для одного сайта.

Если сайт на WordPress уже использует собственный плагин кэширования (WP Rocket, W3 Total Cache, LiteSpeed Cache), важно развести зоны ответственности: серверный плагин кэширует HTML и объекты на уровне PHP, а Cloudflare кэширует статику на уровне CDN. Конфликт возникает, если оба одновременно пытаются кэшировать HTML-страницы без единого механизма инвалидации — тогда после обновления контента может показываться устаревшая версия то от одного, то от другого кэша.

Для мультисайтовой установки WordPress (Multisite) на нескольких доменах официальный плагин Cloudflare подключается один раз в сетевой админке, но правило автоочистки кэша при публикации применяется индивидуально к зоне того сайта, где произошла публикация — остальные сайты сети это не затрагивает.