Cloudflare

01Пошагово: подключение домена

1) Создайте аккаунт Cloudflare с двухфакторной аутентификацией и добавьте сайт (корневой домен, например example.com). Выберите план; для начала хватит Free. 2) Cloudflare просканирует текущий DNS и импортирует найденные записи. Внимательно сравните их с текущей зоной, потому что сканирование может пропустить записи: проверьте A, AAAA, CNAME, MX, все TXT (SPF, селекторы DKIM, DMARC, верификации) и SRV. 3) Cloudflare выдаст вам два nameserver'а. У регистратора замените текущие nameserver'ы на эти два, а если у регистратора включён DNSSEC, сначала выключите его (позже включите снова уже через Cloudflare). 4) Дождитесь, пока зона станет Active; обычно это минуты, максимум 24 часа. 5) Подготовьте сертификат на origin и режим SSL до включения прокси на важных записях (следующие разделы). 6) Проверьте через dig и curl.

1# Nameservers switched?
2dig example.com NS +short
3# Proxied records return Cloudflare IPs, not your server's
4dig example.com A +short
5# Response passes through Cloudflare
6curl -sI https://example.com/ | grep -iE "server|cf-ray|cf-cache-status"

02Proxied (оранжевое облако) и DNS only (серое облако)

У каждой записи A, AAAA и CNAME есть статус прокси. Proxied означает, что DNS отвечает IP-адресами Cloudflare: посетители подключаются к Cloudflare, а он уже — к вашему origin. Вы получаете кэширование, WAF, защиту от DDoS и скрытый IP origin. DNS only означает, что Cloudflare просто отвечает вашим реальным IP, как любой DNS-хостинг, и никакая защита не работает. Проксируйте хосты сайта (example.com, www). Оставляйте DNS only для того, что не является HTTP или должно доходить до сервера напрямую: почтовые хосты из MX-записей, hostname'ы для SSH или базы данных, сервисы на портах, которые Cloudflare не проксирует. Помните: одна-единственная DNS only запись, указывающая на тот же сервер, раскрывает IP origin, поэтому не создавайте её для адреса веб-сервера без необходимости.

• Proxy: веб-трафик на стандартных портах HTTP(S).
• DNS only: почта, SSH, FTP, игровые или собственные TCP/UDP-сервисы.
• MX-записи не могут указывать на проксируемый hostname.

03Режимы SSL/TLS: почему Full (strict)

Здесь два соединения: посетитель — Cloudflare и Cloudflare — ваш origin. Режим шифрования SSL/TLS управляет вторым. Off: HTTPS нет вообще. Flexible: HTTPS до посетителя и обычный HTTP до вашего сервера; замочек в браузере есть, но трафик до origin не зашифрован, а если origin редиректит HTTP на HTTPS, получается бесконечный цикл. Full: HTTPS до origin, но сертификат не проверяется, поэтому самоподписанный или просроченный проходит — как прошёл бы и злоумышленник посередине. Full (strict): HTTPS до origin, и сертификат обязан быть действительным и соответствовать hostname, выпущенным публичным CA или Origin CA от Cloudflare. Всегда стремитесь к Full (strict). Установите на сервер сертификат Let's Encrypt (certbot) или бесплатный Cloudflare Origin Certificate, а затем переключите режим. Cloudflare также предлагает режим Automatic, который выбирает самый строгий режим, поддерживаемый вашим origin, но явная установка Full (strict) понятнее.

1# nginx on the origin with a Cloudflare Origin Certificate
2server {
3    listen 443 ssl;
4    http2 on;
5    server_name example.com www.example.com;
6    ssl_certificate     /etc/ssl/cloudflare/example.com.pem;
7    ssl_certificate_key /etc/ssl/cloudflare/example.com.key;
8    root /var/www/example/public;
9}

04HTTPS везде, кэширование и производительность

В разделе SSL/TLS > Edge Certificates включите Always Use HTTPS — он редиректит каждый запрос http:// прямо на edge — и установите Minimum TLS Version на 1.2. Включайте HSTS только после того, как весь сайт и все подключаемые поддомены работают по HTTPS, и начинайте с короткого max-age: как только браузеры его закэшируют, они откажутся от обычного HTTP. По умолчанию Cloudflare кэширует статические файлы по расширению (изображения, CSS, JS, шрифты) и не кэширует HTML. Cache Rules позволяют это изменить: кэшировать публичный HTML ненадолго, пропускать мимо кэша всё с сессионной cookie, /admin, /api и /checkout, задавать Edge и Browser TTL. Заголовок cf-cache-status показывает HIT, MISS, BYPASS или DYNAMIC. После деплоя очищайте кэш по URL, а лучше используйте версионированные имена файлов, чтобы очистка требовалась редко. HTTP/3 и Brotli на текущих планах включены по умолчанию.

• Никогда не кэшируйте страницы, зависящие от cookie или состояния входа.
• Для проверки изменений используйте Development Mode или очистку кэша; не отключайте кэширование глобально.
• Осторожнее с Rocket Loader и трюками с минификацией HTML — они могут сломать JavaScript-приложения; сначала тестируйте.

05Безопасность: WAF, rate limiting, DDoS, закрытие origin

Защита от DDoS — сетевых и HTTP-флудов — для проксируемого трафика включена автоматически на любом плане. Managed WAF ruleset (на платных планах наборы правил шире) блокирует распространённые атаки, например шаблоны SQL-инъекций. Custom rules позволяют блокировать или проверять запросы по стране, пути, user agent или bot score — например, managed challenge на /wp-login.php или /admin для запросов не из ожидаемых стран. Правила rate limiting ограничивают число запросов с одного IP к чувствительным эндпоинтам: логин, OTP, сброс пароля. Bot Fight Mode добавляет базовую защиту от ботов. Прокси помогает, только если атакующие не могут достучаться до origin напрямую: закройте сервер файрволом так, чтобы порты 80 и 443 принимали только опубликованные диапазоны IP Cloudflare (или используйте Cloudflare Tunnel, которому не нужны открытые входящие порты), а SSH оставьте только по ключам и с доверенных IP. Under Attack Mode — аварийный рубильник, который проверяет каждого посетителя.

1# ufw: allow web traffic only from Cloudflare (ranges from cloudflare.com/ips)
2for ip in $(curl -s https://www.cloudflare.com/ips-v4) $(curl -s https://www.cloudflare.com/ips-v6); do
3  sudo ufw allow proto tcp from "$ip" to any port 80,443
4done
5sudo ufw status numbered

06Реальный IP посетителя на origin

За прокси каждый запрос приходит на ваш сервер с IP Cloudflare. Логи, rate limiting, fail2ban и антифрод-проверки видят Cloudflare вместо посетителя и даже могут забанить сам Cloudflare. Cloudflare передаёт исходный адрес в заголовке CF-Connecting-IP (и в X-Forwarded-For). Настройте nginx с модулем realip так, чтобы он доверял этому заголовку только для запросов из диапазонов Cloudflare. Тогда $remote_addr везде станет IP посетителя. В приложениях на Laravel или Node за nginx дополнительно настройте trusted proxies, чтобы фреймворк читал правильный IP клиента и схему. Никогда не доверяйте этому заголовку из произвольных источников, иначе любой сможет подделать свой IP.

1# /etc/nginx/conf.d/cloudflare-realip.conf (list all current ranges)
2set_real_ip_from 173.245.48.0/20;
3set_real_ip_from 103.21.244.0/22;
4set_real_ip_from 2400:cb00::/32;
5# ... remaining ranges from https://www.cloudflare.com/ips/
6real_ip_header CF-Connecting-IP;

07Разбор ошибок 52x и циклов редиректов

Когда Cloudflare показывает страницу ошибки, проблема почти всегда между Cloudflare и вашим origin. 521 Web server is down: origin отклонил соединение — nginx остановлен или файрвол блокирует IP Cloudflare. 522 Connection timed out: Cloudflare не смог установить TCP-соединение — сервер перегружен, в DNS неверный IP или файрвол отбрасывает пакеты. 524: соединение установлено, но приложение отвечало дольше примерно 125 секунд (стандартный таймаут прокси); выносите долгую работу в очереди. 525 SSL handshake failed: origin не говорит на TLS на порту 443 или у него нет сертификата для этого hostname (SNI). 526 Invalid SSL certificate: в режиме Full (strict) сертификат origin просрочен, самоподписан или выпущен на другое имя. Too many redirects: обычно это режим Flexible плюс origin, который редиректит HTTP на HTTPS; переключитесь на Full (strict). Смотрите логи origin и тестируйте его напрямую.

1# Test the origin directly, bypassing Cloudflare
2curl -svI https://example.com/ --resolve example.com:443:203.0.113.10 2>&1 | grep -E "HTTP/|subject|expire|issuer"
3sudo systemctl status nginx
4sudo tail -n 50 /var/log/nginx/error.log

08Что происходит с запросом внутри Cloudflare

Когда посетитель подключается к проксируемому hostname, anycast направляет его в ближайший дата-центр Cloudflare, где TLS завершается на edge-сертификате. Затем запрос проходит ряд фаз в фиксированном порядке. Сначала — сетевая и HTTP-защита от DDoS. Потом правила безопасности: IP access rules, пользовательские правила WAF, правила rate limiting и управляемые наборы правил WAF, плюс проверки ботов. Configuration rules, redirect rules и URL rewrites корректируют запрос. Если к маршруту привязаны Workers, они выполняются следующими и могут ответить сами или изменить запрос. Только после этого кэш ищет cache key. При промахе Origin Rules могут поменять host, порт или SNI, и запрос уходит на ваш origin, возможно сначала через региональный уровень. Знание этого порядка объясняет, например, почему правило WAF блокирует запрос, который всё равно был бы попаданием в кэш.

• Безопасность выполняется до кэша, поэтому заблокированные запросы не тратят ни кэш, ни origin.
• Используйте Trace в дашборде, чтобы увидеть, какие правила сработали для конкретного URL.
• Workers выполняются до кэша; чтобы кэшировать их ответ, используйте Cache API внутри Worker.

09Cache key, tiered cache и cache-заголовки origin

Cache key определяет, что считается одним и тем же объектом. По умолчанию в него входят scheme, host, path и вся query string, поэтому ?utm_source=x создаёт отдельную копию; Cache Rule может игнорировать или сортировать query string либо добавить в ключ заголовок или cookie. По умолчанию Cloudflare уважает Cache-Control от origin для кэшируемого контента: s-maxage и max-age задают время жизни на edge, private и no-store запрещают хранение, а Set-Cookie в ответе обычно мешает его кэшировать. Edge TTL в Cache Rule может переопределить заголовки origin — это мощно и опасно. Tiered Cache заставляет дата-центры нижнего уровня спрашивать верхний уровень вместо вашего origin, что повышает hit ratio и защищает маленький VPS. Варианты purge: один URL, всё целиком, а на некоторых тарифах — по тегу, префиксу или hostname.

1# Let the origin control edge vs browser caching
2location /blog/ {
3    add_header Cache-Control "public, max-age=60, s-maxage=600, stale-while-revalidate=300";
4}
5location /account/ {
6    add_header Cache-Control "private, no-store";
7}
8# Check: curl -sI https://example.com/blog/ | grep -iE "cf-cache-status|age|cache-control"

10Закрываем origin: Authenticated Origin Pulls и Tunnel

Файрвол, пропускающий только диапазоны IP Cloudflare, отсекает случайные сканеры, но трафик любого клиента Cloudflare тоже приходит из этих диапазонов. Есть два более надёжных варианта. Authenticated Origin Pulls используют mutual TLS: Cloudflare при подключении к вашему origin предъявляет клиентский сертификат, а nginx отклоняет любое TLS-соединение без него. Pulls на уровне зоны используют сертификат, выпущенный Cloudflare; pulls на уровне hostname позволяют загрузить свой, что строже, ведь его использует только ваша зона. Cloudflare Tunnel идёт ещё дальше: небольшой демон cloudflared работает на вашем сервере и открывает исходящие соединения к Cloudflare, так что серверу вообще не нужны публичные входящие веб-порты. Tunnel подходит и для внутренних инструментов в связке с Cloudflare Access, который ставит логин перед приложением. Цена — ещё один агент, который нужно мониторить и обновлять.

1# nginx: accept only connections that present Cloudflare's client cert
2ssl_client_certificate /etc/ssl/cloudflare/authenticated_origin_pull_ca.pem;
3ssl_verify_client on;
4 
5# Or: no open ports, with Cloudflare Tunnel
6cloudflared tunnel login
7cloudflared tunnel create web-prod
8cloudflared tunnel route dns web-prod app.example.com
9cloudflared tunnel run web-prod

11Ограничения и пограничные случаи, которые стоит учесть

Несколько ограничений платформы влияют на архитектуру. Размер тела запроса для загрузок через прокси ограничен тарифом (100 MB на Free и Pro), поэтому крупные загрузки должны идти напрямую в объектное хранилище по presigned URL. Таймаут чтения прокси даёт 524, когда origin слишком долго молчит; актуальная документация указывает значение по умолчанию около двух минут, увеличить его можно только на Enterprise, поэтому длинные отчёты и импорты нужно выносить в фоновые задачи с polling или вебхуками. WebSocket поддерживаются, но долгоживущие соединения могут сбрасываться во время обслуживания Cloudflare, так что клиенты должны переподключаться. Проксируются только определённые порты (для HTTPS, например, 443, 2053, 2083, 2087, 2096 и 8443). Бесплатный Universal-сертификат покрывает apex и один уровень поддоменов, поэтому для более глубоких имён вроде a.b.example.com нужен advanced-сертификат. Прежде чем закладываться на дизайн, проверьте актуальные лимиты тарифа.