• HOME
  • Налаштування Cloudflare для WordPress: NS, SSL, реальний IP і WAF

2026年11月12日

  • シェア
  • ツイート

    • 2026年11月12日

    Налаштування Cloudflare для WordPress: NS, SSL, реальний IP і WAF

    Ця стаття — локалізована версія японського оригіналу. Читати японський оригінал

    Підключення Cloudflare до WordPress виконується в такому порядку: ① додайте сайт у Cloudflare й змініть сервери імен (NS) домену; ② виберіть для SSL/TLS режим шифрування Full (strict); ③ відновіть на боці сервера справжню IP-адресу відвідувача; ④ захистіть сторінку входу спеціальним правилом WAF. Безкоштовний тариф уже дає CDN, SSL, захист від DDoS і спеціальні правила (до 5 штук).

    У цій статті описано кожне налаштування та те, що слід перевірити після перемикання. Назви й розташування елементів в інтерфейсі Cloudflare можуть змінюватися, тому тут усе викладено за офіційною документацією (developers.cloudflare.com) станом на листопад 2026 року.

    Що вирішити перед початком

    • Керування DNS перейде до Cloudflare. Реєстратор домену не зміниться, але DNS-записи ви редагуватимете в інтерфейсі Cloudflare.
    • DNS-записи пошти (MX тощо) не проксіюйте. Через Cloudflare проходить лише веб-трафік (HTTP/HTTPS).
    • Переконайтеся, що на початковому сервері (origin, де розташований WordPress) є чинний SSL-сертифікат. Якщо HTTPS уже працює, наприклад із Let's Encrypt, нічого міняти не треба.
    • Якщо в реєстратора ввімкнено DNSSEC, вимкніть його до зміни серверів імен. Якщо залишиться застарілий запис DS, розв’язання імен не працюватиме.

    Крок 1. Додайте сайт і змініть сервери імен

    1. Створіть обліковий запис Cloudflare й додайте домен на панелі керування. Можна вибрати тариф Free.
    2. Cloudflare зчитає поточні DNS-записи та покаже їх списком; перевірте, чи нічого не пропущено. Деякі записи зчитати не вдається, тож порівняйте зі своєю поточною панеллю керування DNS і додайте відсутні вручну.
    3. Для записів A (або AAAA, CNAME) веб-сайту ввімкніть статус проксі (помаранчева хмаринка). Для MX і записів A поштового сервера вимкніть його (лише DNS, сіра хмаринка).
    4. Cloudflare покаже два імені серверів імен. Вони мають вигляд 〇〇.ns.cloudflare.com (де 〇〇 — змінна частина) і призначаються кожному акаунту окремо. Користуйтеся двома іменами, які бачите на власному екрані, а не тими, що вказані в інших статтях.
    5. У панелі керування реєстратора домену змініть сервери імен на ці два.

    Чи відбулося перемикання, можна перевірити такими командами. Поширення змін може зайняти кілька годин.

    # Чи сервери імен — це дві адреси Cloudflare
dig NS example.com +short

# Чи трафік іде через Cloudflare (повертаються server: cloudflare і cf-ray)
curl -sI https://example.com | grep -iE '^(server|cf-ray):'

    Коли статус домену в Cloudflare стане активним (Active), перемикання завершено.

    Крок 2. Виберіть для SSL/TLS режим Full (strict)

    В SSL/TLS Cloudflare є режими, які визначають, як шифруються з’єднання між відвідувачем і Cloudflare та між Cloudflare і початковим сервером.

    Режим Між Cloudflare і початковим сервером Як ставитися у WordPress
    Off Без шифрування Не використовувати
    Flexible HTTP (без шифрування) Не використовувати. Спричиняє цикли перенаправлень і змішаний вміст
    Full HTTPS (сертифікат не перевіряється) Тимчасовий варіант, доки ви не підготуєте сертифікат
    Full (strict) HTTPS (сертифікат перевіряється) Вибирайте цей

    Режим змінюється на сторінці огляду SSL/TLS (Overview) на панелі керування Cloudflare. Типовий параметр «Automatic SSL/TLS» автоматично вибирає безпечний режим у межах того, що підтримує початковий сервер. Якщо вибрати Full (strict) самостійно, сайт ніколи не працюватиме в небажаному режимі. Сертифікатом початкового сервера може бути сертифікат публічного центру сертифікації (як-от Let's Encrypt) або сертифікат Origin CA, який видає Cloudflare.

    Чому слід уникати Flexible: у цьому режимі запит надходить на початковий сервер по HTTP, тож WordPress або сервер відповідає «прийшло по HTTP, перенаправляю на HTTPS», а Cloudflare знову звертається до початкового сервера по HTTP — і так по колу (у браузері з’явиться ERR_TOO_MANY_REDIRECTS). У режимі Full (strict) запит надходить на початковий сервер також по HTTPS, тому на боці WordPress не потрібен додатковий код, що перевіряв би X-Forwarded-Proto і переписував $_SERVER['HTTPS'].

    Заодно переконайтеся, що в WordPress у розділі «Налаштування» (Settings) → «Загальні» (General) поля «Адреса WordPress (URL)» і «Адреса сайту (URL)» починаються з https://. Якщо зображення й далі підвантажуються по http://, див. як виправити змішаний вміст.

    Крок 3. Відновіть справжню IP-адресу відвідувача

    Коли трафік іде через Cloudflare, джерелом з’єднання (REMOTE_ADDR), яке бачить сервер, стає IP-адреса Cloudflare. У такому разі журнал доступу, IP коментарів, плагіни, що обмежують спроби входу, тощо вважатимуть усіх відвідувачів IP-адресами Cloudflare. Cloudflare передає IP відвідувача в заголовку CF-Connecting-IP, тому налаштуйте сервер так, щоб він довіряв цьому заголовку лише тоді, коли джерелом з’єднання є Cloudflare.

    Якщо переписувати REMOTE_ADDR значенням заголовка, не перевіряючи джерело з’єднання, той, хто звернеться до початкового сервера напряму повз Cloudflare, зможе видати себе за будь-яку IP-адресу. Через це не використовуйте код зі старих статей, який просто присвоює REMOTE_ADDR значення HTTP_CF_CONNECTING_IP, якщо воно є.

    Список IP-адрес Cloudflare опубліковано на сторінці https://www.cloudflare.com/ips/. Список може змінюватися, тому періодично переглядайте його.

    Для Nginx

    Використовуйте ngx_http_realip_module. У блоці http або server перелічіть усі діапазони Cloudflare.

    # Діапазони IP Cloudflare (станом на листопад 2026 року; актуальні — на cloudflare.com/ips)
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2a06:98c0::/29;
set_real_ip_from 2c0f:f248::/32;

real_ip_header CF-Connecting-IP;
    sudo nginx -t && sudo systemctl reload nginx

    Для Apache (Debian / Ubuntu)

    Використовуйте mod_remoteip. Створіть файл /etc/apache2/conf-available/remoteip.conf і перелічіть діапазони Cloudflare в RemoteIPTrustedProxy.

    RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxy 173.245.48.0/20 103.21.244.0/22 103.22.200.0/22 103.31.4.0/22
RemoteIPTrustedProxy 141.101.64.0/18 108.162.192.0/18 190.93.240.0/20 188.114.96.0/20
RemoteIPTrustedProxy 197.234.240.0/22 198.41.128.0/17 162.158.0.0/15 104.16.0.0/13
RemoteIPTrustedProxy 104.24.0.0/14 172.64.0.0/13 131.0.72.0/22
RemoteIPTrustedProxy 2400:cb00::/32 2606:4700::/32 2803:f800::/32 2405:b500::/32
RemoteIPTrustedProxy 2405:8100::/32 2a06:98c0::/29 2c0f:f248::/32
    sudo a2enmod remoteip
sudo a2enconf remoteip
sudo apache2ctl configtest
sudo systemctl restart apache2

    Щоб в журналі доступу з’являлася справжня IP-адреса, у LogFormat (combined) у файлі /etc/apache2/apache2.conf замініть %h на %a.

    Якщо змінити налаштування сервера не можна (wp-config.php)

    Якщо ви користуєтеся орендованим сервером (хостингом) і не можете змінювати налаштування вебсервера, виконайте таку саму перевірку в wp-config.php. Розмістіть код перед рядком require_once ABSPATH . 'wp-settings.php';. Значення CF-Connecting-IP (яке є коректною IP-адресою) використовується лише тоді, коли джерело з’єднання входить до діапазонів Cloudflare.

    <?php
// Використовувати CF-Connecting-IP як IP відвідувача лише тоді, коли запит надійшов через Cloudflare
$cf_ranges = [
    '173.245.48.0/20', '103.21.244.0/22', '103.22.200.0/22', '103.31.4.0/22',
    '141.101.64.0/18', '108.162.192.0/18', '190.93.240.0/20', '188.114.96.0/20',
    '197.234.240.0/22', '198.41.128.0/17', '162.158.0.0/15', '104.16.0.0/13',
    '104.24.0.0/14', '172.64.0.0/13', '131.0.72.0/22',
    '2400:cb00::/32', '2606:4700::/32', '2803:f800::/32', '2405:b500::/32',
    '2405:8100::/32', '2a06:98c0::/29', '2c0f:f248::/32',
];

function cf_ip_in_range(string $ip, string $cidr): bool
{
    [$net, $bits] = explode('/', $cidr);
    $ip_bin  = inet_pton($ip);
    $net_bin = inet_pton($net);
    if ($ip_bin === false || $net_bin === false || strlen($ip_bin) !== strlen($net_bin)) {
        return false;
    }
    $bits  = (int) $bits;
    $bytes = intdiv($bits, 8);
    if ($bytes > 0 && substr($ip_bin, 0, $bytes) !== substr($net_bin, 0, $bytes)) {
        return false;
    }
    $rest = $bits % 8;
    if ($rest === 0) {
        return true;
    }
    $mask = (0xFF << (8 - $rest)) & 0xFF;
    return (ord($ip_bin[$bytes]) & $mask) === (ord($net_bin[$bytes]) & $mask);
}

if (!empty($_SERVER['HTTP_CF_CONNECTING_IP']) && !empty($_SERVER['REMOTE_ADDR'])) {
    foreach ($cf_ranges as $range) {
        if (cf_ip_in_range($_SERVER['REMOTE_ADDR'], $range)) {
            $visitor = filter_var($_SERVER['HTTP_CF_CONNECTING_IP'], FILTER_VALIDATE_IP);
            if ($visitor !== false) {
                $_SERVER['REMOTE_ADDR'] = $visitor;
            }
            break;
        }
    }
}

    У wp-config.php уже є <?php на самому початку, тому не копіюйте <?php з першого рядка, а вставте рядки, починаючи з другого. Перш ніж вставляти, зробіть резервну копію wp-config.php.

    Крок 4. Захистіть сторінку входу спеціальним правилом WAF

    Спеціальні правила WAF Cloudflare на безкоштовному тарифі можна створити до 5 штук, і для них можна вибрати будь-яку дію, окрім Log (Block, Managed Challenge тощо). Створюється правило так: на сторінці Security rules на панелі керування виберіть «Create rule» → «Custom rules», задайте умову (Field, Operator, Value) і дію та натисніть «Deploy».

    Приклад 1. Відкрити вхід і адмінку лише для вашої IP-адреси

    Це приклад для випадку, коли вдома чи в офісі є статична IP-адреса. Виразом це записується так (замініть 203.0.113.10 і 198.51.100.0/24 на власні IP).

    (http.request.uri.path eq "/wp-login.php" or starts_with(http.request.uri.path, "/wp-admin/"))
and http.request.uri.path ne "/wp-admin/admin-ajax.php"
and not ip.src in {203.0.113.10 198.51.100.0/24}

    Дія — Block. /wp-admin/admin-ajax.php виключено з умови, тому що його іноді викликають без входу в обліковий запис функції публічних сторінок, як-от форми зворотного зв’язку й нескінченне прокручування.

    Приклад 2. Якщо статичної IP-адреси немає, обмежте за країною та Managed Challenge

    (http.request.uri.path eq "/wp-login.php" or http.request.uri.path eq "/xmlrpc.php")
and not ip.src.country in {"JP"}

    Для визначення країни використовуйте ip.src.country (двобуквений код за ISO 3166-1). Параметр ip.geoip.country зі старих статей є застарілим. Спершу виберіть дію Managed Challenge, перегляньте події безпеки (security events), чи не потрапляють під правило легітимні запити, і лише потім за потреби переходьте на Block. Документація Cloudflare також рекомендує таку послідовність. xmlrpc.php використовується під час публікації з Jetpack або мобільних застосунків, тому перш ніж додавати його в умову, перевірте, чи ви ним користуєтеся.

    Обмеження за країнами — це допоміжний захід, який можна обійти, наприклад через VPN. Поєднуйте його з двофакторною автентифікацією та обмеженням кількості спроб входу. Як визначати країну на боці Nginx, описано в статті Як обмежити доступ за країнами за допомогою Nginx GeoIP2.

    Крок 5. Типова поведінка кешу та скидання кешу під час публікації

    Cloudflare за замовчуванням не кешує HTML. Він кешує статичні файли, що визначаються за розширенням: зображення, CSS, JavaScript, шрифти. Також не кешуються відповіді із заголовком Set-Cookie. Тому якщо нічого не налаштовувати, адмінка й сторінка входу в кеші Cloudflare не опиняться.

    Якщо ви хочете кешувати і HTML, розширте охоплення в Cache Rules, але тоді з нього потрібно виключити /wp-admin/, /wp-login.php, попередній перегляд і вигляд для користувачів, які ввійшли в обліковий запис. Через помилку в цьому налаштуванні сторінки для адміністраторів можуть показуватися іншим людям, тож якщо ви не впевнені, безпечніше залишити типові параметри.

    Якщо після заміни CSS чи зображень вигляд не змінюється, скиньте (purge) кеш у налаштуваннях кешу на панелі керування. Якщо потрібно, щоб кеш скидався автоматично під час кожної публікації чи оновлення запису, викличте API Cloudflare. Спершу створіть у Cloudflare API-токен лише з дозволом «Cache Purge» і разом з ідентифікатором зони (він показаний на сторінці огляду домену) запишіть його в wp-config.php у вигляді констант.

    define( 'CF_ZONE_ID', 'ID зони' );
define( 'CF_API_TOKEN', 'API-токен' );

    Наступний код помістіть у functions.php дочірньої теми або в невеликий власний плагін (підійде й Code Snippets).

    <?php
// Після публікації чи оновлення запису видалити з Cloudflare кеш цього запису й головної сторінки
function cf_purge_urls(array $urls): bool
{
    if (!defined('CF_ZONE_ID') || !defined('CF_API_TOKEN')) {
        return false;
    }

    $response = wp_remote_post(
        'https://api.cloudflare.com/client/v4/zones/' . CF_ZONE_ID . '/purge_cache',
        [
            'headers' => [
                'Authorization' => 'Bearer ' . CF_API_TOKEN,
                'Content-Type'  => 'application/json',
            ],
            'body'    => wp_json_encode(['files' => array_values($urls)]),
            'timeout' => 15,
        ]
    );

    if (is_wp_error($response)) {
        error_log('Cloudflare purge failed: ' . $response->get_error_message());
        return false;
    }

    $result = json_decode(wp_remote_retrieve_body($response), true);
    return !empty($result['success']);
}

add_action('publish_post', function (int $post_id): void {
    if (wp_is_post_revision($post_id) || wp_is_post_autosave($post_id)) {
        return;
    }
    cf_purge_urls([get_permalink($post_id), home_url('/')]);
});

    publish_post спрацьовує, коли запис опубліковано й коли оновлено вже опублікований запис. Окрім files, де задаються URL, у purge_cache в API є також purge_everything, що очищає все, але повне скидання змушує заново отримувати всі статичні файли, тож не застосовуйте його під час кожної публікації запису.

    Що перевірити після перемикання

    • У результаті curl -sI є server: cloudflare і cf-ray, а в браузері показано значок замка
    • Можна ввійти в адмінку, зберегти запис і завантажити медіафайл
    • У нових коментарях і журналі доступу записується IP-адреса відвідувача, а не IP-адреса Cloudflare
    • Листи з контактної форми доходять (MX-записи не проксіюються)
    • Якщо ви створили спеціальне правило WAF, відкрийте wp-login.php із підключення, якому доступ не дозволено (наприклад, зі смартфона через мобільну мережу) і переконайтеся, що з’являється блокування або перевірка (challenge)

    Поширені проблеми

    З’являється ERR_TOO_MANY_REDIRECTS

    Перевірте, чи для SSL/TLS не вибрано режим Flexible. Установіть на початковий сервер сертифікат і змініть режим на Full (strict) — проблема зникне.

    Не вдається потрапити в адмінку

    Можливо, в умову спеціального правила WAF не входить ваша IP-адреса чи країна. Тимчасово вимкніть правило на панелі керування Cloudflare, у подіях безпеки з’ясуйте, яке саме правило спрацювало, і лише потім виправте вираз.

    Усі запити виглядають як із однієї IP-адреси

    Не виконано відновлення реальної IP-адреси з кроку 3. Для Nginx перевірте діапазон у set_real_ip_from і real_ip_header, для Apache — чи ввімкнено remoteip.

    Підсумок

    • Змініть сервери імен на два, призначені вашому акаунту, а записи для пошти, зокрема MX, не проксіюйте
    • SSL/TLS — Full (strict). Flexible спричиняє цикли перенаправлень і змішаний вміст
    • Справжню IP-адресу відновлюйте, довіряючи CF-Connecting-IP лише тоді, коли джерело з’єднання входить до діапазонів Cloudflare
    • Сторінку входу обмежте правилом WAF за IP або країною і спершу спостерігайте за роботою в режимі Managed Challenge
    • HTML за замовчуванням не кешується. Скидання кешу під час публікації виконуйте через API-токен лише з дозволом «Cache Purge»

    Пов’язані статті

    Джерела: Restoring original visitor IPs (Cloudflare), Encryption modes (Cloudflare), Custom rules (Cloudflare WAF), Default cache behavior (Cloudflare)

    Views: 4

    Маєте запитання щодо WordPress? Видавець сайту перебуває в Японії й відповідає японською. Написати нам (японською)

    お気軽にご相談ください

    お見積りへ お問い合わせへ
    閉じる
    ▲