Тонкая настройка Cloudflare: как ускорить сайт для зарубежной аудитории

Сервер бэкенда продолжает расходовать процессорное время и оперативную память на компиляцию PHP и запросы к СУБД для каждого иностранного посетителя, а физическая задержка трансатлантического маршрута нивелирует преимущества CDN.

О влиянии физического расстояния между континентами и сетевых задержек оптоволокна на мобильный трафик читайте в материале «Хостинг в США vs Европа: почему выбор локации для Tier-1 изменился».

Криптографический фундамент: устранение уязвимости Flexible SSL

Использование режима Flexible SSL в панели Cloudflare — критическая ошибка в архитектуре безопасности. В этом режиме шифруется только участок пути между браузером пользователя и Cloudflare, а трафик между серверами CDN и вашим хостингом передается открытым текстом по незащищенному протоколу HTTP (порт 80).

server {
    listen 443 ssl http2;
    server_name domain.com www.domain.com;

    ssl_certificate /etc/ssl/certs/origin.crt;
    ssl_certificate_key /etc/ssl/certs/origin.key;
    ssl_protocols TLSv1.2 TLSv1.3;

    # ... остальная конфигурация
}

Пошаговая настройка правила кэширования всего сайта:

1. Перейдите в Caching ➔ Cache Rules и нажмите Create Rule.

2. Задайте имя правила: Cache HTML with Cookie Bypass.

3. В блоке условий (When incoming requests match) укажите:

   • Hostname equals domain.com AND

   • Cookie does not contain "wordpress_logged_in_" AND

   • Cookie does not contain "comment_author_" AND

   • URI Path does not start with "/wp-admin/" AND

   • URI Path does not start with "/wp-login.php"

4. В блоке параметров (Then) настройте:

   • Cache eligibility: Eligible for cache (Cache Everything)

   • Edge TTL: Override origin ➔ 7 days (или 30 days)

   • Browser TTL: Respect origin или 4 hours

Неавторизованные пользователи получают статический HTML напрямую из оперативной памяти ближайшего Edge-сервера. Как только пользователь или администратор авторизуется, наличие куки wordpress_logged_in_ направляет запросы в обход кэша напрямую к бэкенду.

Матрица глобальных параметров кэширования

Для исключения просадок скорости при первом формировании страниц (Cache MISS) внутренние службы бэкенда должны быть предварительно оптимизированы. О настройке локального кэша читайте в статье «Серверное кэширование: как разделить слои HTTP и данных (FastCGI, Redis, Opcache)».

Сетевые протоколы: выжимаем максимум из HTTP/3 и Early Hints

В разделе Speed ➔ Optimization активируйте современные протоколы доставки контента:

• HTTP/3 (QUIC): протокол работает поверх UDP, устраняя блокировку очереди пакетов (Head-of-Line Blocking) при потерях данных в мобильных сетях.

• 0-RTT Connection Resumption: позволяет клиентам, ранее посещавшим сайт, отправлять первый полезный HTTP-запрос одновременно с пакетом рукопожатия TLS.

• 103 Early Hints: сервер Cloudflare отправляет браузеру предварительные заголовки со ссылками на критические стили и шрифты (Link: </style.css>; rel=preload) еще до завершения сборки основного тела страницы бэкендом.

Защита Origin IP: блокировка прямых запросов к серверу

Если реальный IP-адрес сервера станет известен, атакующие смогут направить поток трафика напрямую на сетевой интерфейс хостинга в обход WAF и правил Cloudflare.

Способы изоляции бэкенда:

• Фильтрация на уровне фаервола (UFW):

  Разрешите входящие соединения на веб-порты 80 и 443 исключительно из официальных IPv4- и IPv6-диапазонов Cloudflare ([https://www.cloudflare.com/ips/](https://www.cloudflare.com/ips/)), заблокировав все остальные IP-адреса.

• Authenticated Origin Pulls (mTLS):

  Активируйте в панели Cloudflare режим Authenticated Origin Pulls и подключите публичный CA-сертификат Cloudflare в Nginx:

ssl_client_certificate /etc/ssl/certs/cloudflare_origin_pull.crt;
ssl_verify_client on;

Nginx будет сбрасывать любые входящие HTTP-запросы, если клиент не предоставил валидный TLS-сертификат Cloudflare.

Автоматизировать настройку правил сетевого экрана UFW и выгрузку белых списков IP-адресов на пуле серверов позволяет готовый Ansible-плейбук для массового развертывания.

Сценарии применения: арбитраж, E-commerce и PBN

• Арбитраж трафика: кэширование белых страниц (White Page) и настройка WAF-правил (Managed Challenge для подозрительных ASN) снижают нагрузку на трекер и защищают бюджет от спам-ботов. Подробнее о защите связок читайте в статье «Хостинг для арбитража трафика: архитектура серверов под Keitaro, клоаку и лендинги».

• PBN-сетки и сателлиты: проксирование трафика через Anycast IP Cloudflare маскирует принадлежность сайтов к одному серверу или автономной системе (ASN). Архитектура безопасного разделения сателлитов описана в материале «Хостинг для PBN: как избежать бан-паттернов на уровне ASN и NS-записей».

Чек-лист: аудит конфигурации Cloudflare перед запуском

• Установлен сертификат Cloudflare Origin CA и включен режим SSL/TLS: Full (Strict).

• Создано Cache Rule для кэширования всего HTML с исключением куки авторизации (wordpress_logged_in_).

• Включен функционал Tiered Cache и режим отказоустойчивости Always Online.

• Активированы протоколы HTTP/3 (QUIC), 0-RTT и механизм 103 Early Hints.

• Включено сжатие алгоритмом Brotli.

• На сервере бэкенда закрыты порты 80/443 для всех внешних адресов, кроме официальных подсетей Cloudflare.

Что делать дальше: следующие шаги

• Для настройки локального серверного кэширования и кэша запросов к СУБД ➔ изучите руководство «Серверное кэширование: как разделить слои HTTP и данных (FastCGI, Redis, Opcache)».

• Для выбора оптимальной физической локации бэкенд-сервера под Tier-1 ➔ перейдите к статье «Хостинг в США vs Европа: почему выбор локации для Tier-1 изменился».

• Для базовой настройки защиты Linux-сервера от взлома ➔ выполните инструкцию «Безопасное управление сервером: ed25519, UFW, Fail2ban».