CDN для сайта: настройка

MAATRIX

Сайт открывается быстро у вас и медленно — у половины посетителей из других регионов, а на пиках трафика сервер начинает захлёбываться на отдаче обычных картинок. Обе проблемы решает CDN: статика раздаётся с серверов, географически близких к посетителю, а ваш VPS освобождается от рутинной работы и занимается только тем, что реально требует его вычислений. Разберём, как подключить CDN на практике — через Cloudflare как самый доступный и распространённый вариант, — что кешировать агрессивно, а что нельзя трогать, и почему скрытый за CDN IP сервера не спасает от прицельной атаки.

Зачем сайту нужен CDN

CDN (Content Delivery Network, сеть доставки контента) — это распределённые по миру узлы, которые хранят копию вашей статики и отдают её посетителю с ближайшей точки, а не с единственного сервера на другом конце света. Если ваша аудитория сидит в одной стране рядом с сервером, эффект будет скромным. Но если посетители приходят из разных регионов, каждый лишний прыжок через полмира добавляет заметную задержку — CDN эту задержку убирает.

Второй эффект даже важнее первого: снятие нагрузки с origin-сервера. Каждая картинка, файл стилей или скрипт, отданный из кеша CDN, — это запрос, который никогда не дошёл до вашего VPS. Сервер продолжает обрабатывать динамику: генерацию страниц, запросы к базе, API — а всю рутинную раздачу файлов берёт на себя сеть доставки. На практике это означает, что один и тот же тариф VPS выдерживает заметно больший всплеск посетителей, если статика уже не идёт через него напрямую.

Третья причина — сглаживание пиков. Если на сайт неожиданно хлынул трафик (посты в соцсетях, рассылка, распродажа), CDN поглощает основную волну повторяющихся запросов к одним и тем же файлам, и сервер этого почти не замечает.

Cloudflare как самый доступный вариант

Для большинства сайтов проще всего подключить CDN через Cloudflare — у него есть бесплатный тариф, который закрывает базовые задачи: кеширование статики, HTTPS, базовая защита от ботов. Процесс подключения выглядит так.

1. Зарегистрируйтесь на cloudflare.com и добавьте домен через кнопку «Add a site».
2. Cloudflare просканирует текущие DNS-записи домена и покажет их список — проверьте, что все нужные записи (A, CNAME, MX и так далее) подхватились корректно, при необходимости добавьте недостающие вручную.
3. Cloudflare выдаст пару NS-записей вида ns1.cloudflare.com и ns2.cloudflare.com (конкретные имена индивидуальны для каждого аккаунта).
4. Зайдите в панель управления доменом у вашего регистратора и замените текущие NS-записи на выданные Cloudflare.
5. Дождитесь применения — обычно от нескольких минут до пары часов, иногда до суток из-за особенностей DNS-кеширования у разных провайдеров.

После смены NS домен официально управляется через Cloudflare, и именно там теперь настраиваются DNS-записи, включая проксирование. В интерфейсе DNS у каждой записи есть переключатель облака: серое облако — «DNS only», запрос идёт напрямую на ваш сервер, оранжевое облако — «Proxied», трафик идёт через сеть Cloudflare, и только тогда включаются CDN, кеширование и защита. Для сайта нужно включить проксирование (оранжевое облако) на записи, которая указывает на веб-сервер; записи вроде MX для почты обычно оставляют серыми — прокси Cloudflare предназначен для веб-трафика, а не для почтового.

Что кешировать агрессивно, а что нет

Главная ошибка при подключении CDN — единое правило кеширования для всего сайта. Правильный подход — разделить контент на два лагеря.

Кешировать агрессивно и надолго:

• изображения (jpg, png, webp, svg, gif);
• CSS и JS файлы, особенно если у них в имени есть хеш версии;
• шрифты (woff, woff2, ttf);
• статичные документы для скачивания (pdf, zip и подобные).

Эти файлы не меняются от запроса к запросу и одинаковы для всех посетителей — идеальный материал для кеша с большим временем жизни. На вашем сервере это задаётся заголовками ответа:

location ~* \.(jpg|jpeg|png|webp|gif|svg|css|js|woff2?|ttf)$ {
    expires 30d;
    add_header Cache-Control "public, max-age=2592000, immutable";
}

Не кешировать или кешировать с оговорками:

• динамические ответы API (данные пользователя, корзина, статусы заказов);
• страницы с персонализированным содержимым (личный кабинет, авторизация);
• формы с CSRF-токенами — закешированный токен может не совпасть с сессией следующего посетителя.

Для такого контента отдавайте заголовок Cache-Control: no-store или private, чтобы CDN не сохранял ответ и не показал данные одного пользователя другому:

location /api/ {
    add_header Cache-Control "no-store";
}

Между этими двумя крайностями лежит HTML самих страниц. Если сайт в основном статичный (блог, лендинг, документация), HTML тоже можно кешировать — но на короткое время (минуты, а не дни), чтобы обновления публикаций доходили до посетителей достаточно быстро без ручного сброса кеша на каждую правку.

Настройка кеша в Cloudflare

По умолчанию Cloudflare кеширует по расширению файла на основе собственного списка (изображения, стили, скрипты кешируются, HTML — нет). Этого достаточно для старта, но для контроля стоит настроить Cache Rules (в панели: раздел Caching → Cache Rules — этот интерфейс в 2026 году заменил более старые Page Rules у большинства аккаунтов).

Типовое правило для статики в отдельной папке:

• Условие: URI Path содержит /static/ или /assets/
• Действие: Cache Eligibility — Eligible for cache, Edge TTL — задать вручную, например 7 дней

Типовое правило, чтобы явно исключить динамику из кеша:

• Условие: URI Path содержит /api/ или /cart/
• Действие: Cache Eligibility — Bypass cache

Отдельно обратите внимание на Browser Cache TTL — это время, на которое браузер посетителя закешируется сам, отдельно от кеша на узлах Cloudflare. Для статики с версионированием в имени файла (style.a1b2c3.css) его можно ставить в максимум — новая версия файла всё равно придёт под новым именем.

Сброс кеша после обновления сайта

Рано или поздно возникает ситуация: вы обновили картинку или файл стилей, а посетители всё ещё видят старую версию — CDN честно отдаёт то, что закешировал раньше. Есть два рабочих подхода.

Первый и самый надёжный — версионирование имён файлов. Каждое изменение файла сопровождается изменением его имени или добавлением хеша (app.js?v=42 или app.a1b2c3.js). Тогда новая версия — это физически новый URL, и старый кеш просто не мешает, сбрасывать вручную ничего не нужно. Это стандартная практика для собранного фронтенда (webpack, vite и подобные сборщики делают это автоматически).

Второй — ручной сброс кеша (purge) в панели Cloudflare: Caching → Configuration → Purge Cache. Есть вариант «Purge Everything» (сбросить весь кеш домена — самый простой, но и самый грубый способ) и точечный сброс по конкретным URL, если нужно обновить только несколько файлов, не трогая остальной кеш. То же самое можно сделать через API одним запросом, что удобно встроить в скрипт деплоя, чтобы сброс кеша происходил автоматически при каждом обновлении сайта:

curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONE_ID/purge_cache" \
     -H "Authorization: Bearer API_TOKEN" \
     -H "Content-Type: application/json" \
     --data '{"purge_everything":true}'

Для сайтов с частыми обновлениями разумно сочетать оба подхода: версионировать статику, чтобы кеш не мешал в обычной работе, а purge использовать как аварийный рычаг, если что-то закешировалось неправильно или нужно сбросить всё разом.

Что CDN маскирует, а что нет

После включения проксирования запросы к вашему серверу идут не напрямую от посетителей, а с узлов Cloudflare — и это меняет то, что видно снаружи. Если раньше кто угодно мог узнать IP вашего сервера, просто посмотрев на DNS-запись домена, то теперь публично виден только адрес Cloudflare, а не origin-сервера. Это удобно: часть автоматических сканеров и простых DDoS-атак, которые целятся по домену, бьют по инфраструктуре Cloudflare, а не по вашему VPS напрямую.

Но важно понимать границу этой защиты. Маскировка работает только пока настоящий IP сервера действительно неизвестен атакующему. А узнать его можно разными путями, не связанными с DNS-записью домена: старые записи, которые индексировались до подключения CDN и остались в истории (например, в сервисах вроде SecurityTrails); поддомены, которые забыли включить в проксирование и они по-прежнему указывают на сервер напрямую; заголовки писем, если на том же сервере стоит почта; баннеры сервисов, которые видны сканерам вроде Shodan, если порты открыты всему интернету. Если IP уже известен, атакующий бьёт напрямую в обход CDN, и никакая маскировка не помогает — сработает только реальная защита самого сервера.

Поэтому маскировку IP правильно рассматривать как один из слоёв защиты, а не как единственный. Дополните её: закройте на фаерволе сервера прямой доступ по HTTP/HTTPS для всех, кроме IP-диапазонов Cloudflare (актуальный список публикуется на cloudflare.com/ips), смените поддомены, если по старым записям сервер отвечает напрямую, и отключите баннеры сервисов там, где это возможно. Подробно о том, как встраивается сеть доставки контента перед сервером и что при этом настраивается на стороне VPS, разобрано в статье про настройку CDN перед сервером. Если же атака всё-таки застала сервер врасплох, порядок первых действий описан в статье про DDoS-атаку.

Отдельно стоит настроить восстановление реального IP посетителя на стороне вашего веб-сервера — иначе в логах вместо адресов пользователей будут адреса узлов Cloudflare, и любая логика, завязанная на IP (геоблокировки, бан за брутфорс, аналитика), сломается. Cloudflare передаёт настоящий адрес посетителя в заголовке CF-Connecting-IP, и Nginx нужно явно научить его читать:

set_real_ip_from 0.0.0.0/0;
real_ip_header CF-Connecting-IP;

(в проде вместо 0.0.0.0/0 лучше явно перечислить диапазоны Cloudflare из их официального списка, а не доверять заголовку от произвольного источника).

Частые вопросы