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: Bypassdefine('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 підключається один раз у мережевій адмінці, але правило автоочищення кешу під час публікації застосовується індивідуально до зони того сайту, де відбулася публікація — решти сайтів мережі це не стосується.