Настройка Cloudflare для бизнес-сайта: скорость и защита шаг за шагом

Cloudflare стоит между посетителями и вашим сервером. Посетитель подключается к ближайшему дата-центру Cloudflare, который отдаёт кешированные файлы сам, отсекает враждебный трафик и пересылает остальное на ваш сервер. Для бизнеса это быстрые страницы для клиентов, далёких от вашего хостинга, защита от простых атак на отказ в обслуживании и место, где можно применять правила безопасности без изменения кода приложения. Многие тарифы начинаются с бесплатного, а платные добавляют функции, поэтому перед выбором проверьте актуальное сравнение тарифов.

Это не замена обновлённому ПО и безопасному коду. Наш чеклист безопасности PHP по-прежнему актуален. Считайте Cloudflare крепкой входной дверью, а не заменой замков на внутренних комнатах.

Перед началом

• Сделайте опись DNS. Выгрузите или сфотографируйте все записи у текущего DNS-провайдера, включая почтовые (MX, SPF, DKIM, DMARC) и записи подтверждения. Пропущенная запись — классический способ сломать почту при переезде.
• Выясните, кто владеет аккаунтом регистратора домена, и убедитесь, что это корпоративный аккаунт с многофакторной аутентификацией. Именно там вы смените серверы имён.
• Уменьшите TTL ключевых записей за день, если возможно, чтобы изменения распространялись быстрее.
• Выберите тихое время и предупредите команду. Продумайте откат: старые серверы имён, записанные заранее.

Шаг 1: добавьте сайт и проверьте DNS

Добавьте домен в панели Cloudflare. Он просканирует существующие записи. Сравните их с описью и закройте пробелы. Для каждой записи выберите один из двух режимов:

• Проксируется (оранжевое облако): трафик идёт через Cloudflare. Используйте для сайта и хостов веб-приложения.
• Только DNS (серое облако): Cloudflare просто отвечает на DNS-запрос. Используйте для почтовых серверов, хостов SSH и FTP и всего, что не является HTTP или HTTPS.

Затем смените серверы имён у регистратора. Когда сайт станет активным, проверьте его и отправьте тестовое письмо.

Шаг 2: правильно настройте шифрование

Именно эта настройка ломает больше всего сайтов. У Cloudflare несколько режимов SSL/TLS:

• Flexible: шифрует участок посетитель — Cloudflare, но передаёт трафик на ваш сервер без шифрования. Выглядит рабочим, но второй участок открыт и часто вызывает циклические редиректы. Избегайте.
• Full: шифрует оба участка, но не проверяет сертификат вашего сервера.
• Full (strict): шифрует оба участка и проверяет сертификат на вашем сервере. Используйте именно его.

Сначала установите на сервер действующий сертификат. Подойдёт сертификат Cloudflare Origin CA или бесплатный Let's Encrypt. Затем переключитесь на Full (strict), включите Always Use HTTPS, задайте минимальную версию TLS 1.2 и включайте HSTS только когда всё работает по HTTPS, потому что HSTS на долгое время запрещает браузерам обычный HTTP.

Шаг 3: сделайте обход Cloudflare невозможным

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

• Разрешите веб-трафик на сервер только из опубликованных диапазонов IP Cloudflare.
• Восстановите реальный IP посетителя в веб-сервере, иначе все запросы в логах, ограничениях и аналитике будут выглядеть как идущие от Cloudflare.

#!/usr/bin/env bash
# /opt/cf/update_cloudflare_ips.sh - запускать еженедельно из cron
set -euo pipefail
IPS="$(curl -fsS https://www.cloudflare.com/ips-v4) $(curl -fsS https://www.cloudflare.com/ips-v6)"

# 1) реальный IP посетителя для Nginx
OUT=/etc/nginx/conf.d/cloudflare_real_ip.conf
{
  for r in $IPS; do echo "set_real_ip_from $r;"; done
  echo "real_ip_header CF-Connecting-IP;"
} > "$OUT.tmp" && mv "$OUT.tmp" "$OUT"
nginx -t && nginx -s reload

# 2) файервол: HTTPS только от Cloudflare (сначала удалите общее правило "allow 443")
for r in $IPS; do ufw allow proto tcp from "$r" to any port 443 comment 'cloudflare'; done

Важная деталь для тех, кто использует Docker: порты, опубликованные Docker, обходят правила ufw. Привязывайте контейнеры к localhost за обратным прокси или ограничивайте доступ в цепочке файервола Docker DOCKER-USER. Для более сильной изоляции Cloudflare Tunnel позволяет серверу устанавливать только исходящее соединение, и тогда входящие веб-порты вообще не нужны. Для платёжных вебхуков и других интеграций «сервер — сервер» убедитесь, что правила по IP по-прежнему пропускают эти запросы, если они идут не через Cloudflare.

Шаг 4: правила кеширования

По умолчанию Cloudflare кеширует статические файлы — изображения, CSS и JavaScript, — но не HTML. Разумная политика для типичного PHP-сайта:

• Статические ресурсы: кешировать надолго (месяц и больше). Используйте версионные имена файлов или параметр вроде app.css?v=123, чтобы новый деплой подхватывался сразу.
• Публичные HTML-страницы (маркетинговые страницы, блог): можно кешировать на минуты или часы через Cache Rule. Тестируйте внимательно.
• Никогда не кешировать: админку, личный кабинет, корзину, оформление заказа, API и любые страницы, зависящие от cookie входа. Создайте правило обхода кеша для этих путей и для запросов с вашей сессионной cookie.

Сбрасывайте кеш автоматически после каждого деплоя, чтобы клиенты не видели устаревшие файлы. Создайте API-токен только с правом «Cache Purge» для этой зоны и вызывайте его из скрипта деплоя:

# сброс выбранных файлов после деплоя
curl -sS -X POST "https://api.cloudflare.com/client/v4/zones/$CF_ZONE_ID/purge_cache" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"files":["https://example.com/css/app.css","https://example.com/js/app.js"]}'

Быстрые страницы также помогают поиску и конверсии. В нашем руководстве по Core Web Vitals для PHP-сайтов описано, что исправлять на стороне сервера после подключения CDN.

Шаг 5: файервол, боты и ограничение частоты

• Включите управляемые правила WAF, доступные на вашем тарифе. Они блокируют типовые атаки до того, как те дойдут до вашего кода.
• Включите защиту от ботов, подходящую вашему тарифу, и смотрите аналитику, прежде чем что-либо ужесточать.
• Ограничьте частоту запросов к чувствительным точкам: вход, сброс пароля, регистрация и оформление заказа. Именно их атакуют перебором и проверкой карт.
• Исключите доверенный машинный трафик: платёжные вебхуки, сервисы мониторинга и ваши интеграции не должны получать проверки для браузеров, ведь страница проверки, возвращённая вебхуку, выглядит как сбой.

# Пользовательское правило 1: блокировать поиск секретов и репозиториев (действие: Block)
(http.request.uri.path contains "/.env" or http.request.uri.path contains "/.git" or http.request.uri.path contains "wp-config")

# Пользовательское правило 2: пропускать платёжные вебхуки (действие: Skip, функции безопасности)
(http.request.uri.path in {"/webhooks/stripe" "/webhooks/paypal"})

# Правило ограничения частоты: не более 10 попыток входа в минуту с одного IP
(http.request.uri.path eq "/login" and http.request.method eq "POST")  =>  10 requests / 1 minute / IP

Синтаксис правил и доступные поля зависят от тарифа, поэтому считайте это шаблонами и сначала тестируйте в режиме «лог». Сохраняйте и защиту на уровне приложения: проверка подписи вебхуков, как в нашем руководстве по вебхукам Stripe, никогда не должна зависеть только от сетевых правил.

Шаг 6: проверьте настройку

# идёт ли трафик через Cloudflare?
curl -sI https://example.com | grep -iE "^(server|cf-cache-status|cf-ray)"

# отказывает ли origin в прямом доступе? (подставьте IP сервера; ожидайте таймаут или отказ)
curl -sI --max-time 8 https://203.0.113.10 -H "Host: example.com" -k

# верны ли серверы имён и почтовые записи?
dig NS example.com +short
dig MX example.com +short
dig TXT example.com +short

Запросите статический файл дважды: второй ответ должен показать cf-cache-status: HIT. Проверьте вход, оформление заказа и админку в настоящем браузере, отправьте и получите тестовое письмо.

Частые ошибки

• Flexible SSL и последующие циклические редиректы.
• Проксирование почтового хоста (он должен быть «только DNS») или потеря почтовой записи при переезде.
• Кеширование приватных страниц, из-за чего один клиент видит страницу аккаунта другого. Всегда обходите кеш для авторизованного трафика.
• Открытый origin: реальный IP виден в старых DNS-записях, заголовках писем или логах сертификатов. Ограничьте файервол и подумайте о смене IP, если он утёк.
• Невосстановленный реальный IP, который ломает ограничения частоты, логи и антифрод.
• Проверки для вебхуков и API, вызывающие тихие сбои в платежах и интеграциях.
• Лимиты размера запроса: у проксируемых запросов есть максимальный размер тела, зависящий от тарифа. Проверьте актуальный лимит, если приложение принимает крупные загрузки.
• Забытый мониторинг. Добавьте алерты на срок действия сертификата и домена и сохраните проверки аптайма, как описано в нашем руководстве по бэкапам и мониторингу.

Чеклист на одну страницу

1. Опись DNS выгружена, аккаунт регистратора защищён.
2. Сайт добавлен, записи проверены, проксируются только веб-хосты.
3. Сертификат на origin установлен, режим SSL Full (strict), Always Use HTTPS включён.
4. Файервол ограничен диапазонами Cloudflare, реальный IP посетителя восстановлен.
5. Правила кеша для статики, обход для приватных путей, сброс кеша в скрипте деплоя.
6. Управляемый WAF включён, лимиты для входа и оплаты, вебхуки исключены.
7. Команды проверки выполнены, алерты настроены, откат задокументирован.

Чем мы можем помочь

Мы настраиваем Cloudflare, хостинг и конвейеры деплоя для PHP-приложений и подключаем их к платёжным, CRM- и мессенджер-системам. Прочитайте про нашу услугу интеграций или запишитесь на короткий звонок, и мы сверим вашу настройку DNS, SSL и кеширования с этим чеклистом.