Сбой CDN: как понять, что сайт недоступен не из-за хостинга

CDN обычно подключают, чтобы сайт открывался быстрее и выдерживал больше запросов. Но у этой пользы есть обратная сторона: когда CDN работает нестабильно, владелец сайта может видеть странную картину. Главная страница открывается у части пользователей, картинки не загружаются, API отвечает ошибками, а хостинг при этом выглядит исправным.

Такие ситуации сложно разбирать на глаз. Нужно отделить несколько уровней: домен, DNS, CDN, исходный сервер, приложение и отдельные страницы. Ниже — практический алгоритм, который помогает понять, действительно ли виноват CDN, когда стоит проверять хостинг, а когда лучше сразу подключать мониторинг и собирать факты.

Почему CDN может стать причиной недоступности сайта

CDN находится между посетителем и вашим сервером. Пользователь обращается к домену, DNS направляет его к CDN, а CDN уже отдает кешированную страницу, картинку, файл стилей или передает запрос на исходный сервер. Если любой из этих участков работает неправильно, сайт может выглядеть «упавшим», хотя причина будет не в коде сайта.

Повод снова вспомнить о такой диагностике дают публичные статус-страницы инфраструктурных провайдеров. Например, на странице Gcore за 7 мая 2026 года описана деградация CDN в нескольких европейских локациях и reroute трафика: https://status.gcore.com/cmovh5xel04m6q3bft0t2fczb. В другом инциденте Gcore отдельно перечислял CDN, API, Customer Portal и другие сервисы как затронутые компоненты: https://status.gcore.com/cmnoh7mql01a5dlxxr074mefo. У Cloudflare статус-страница также разделяет CDN/Cache, Dashboard, API, DNS, SSL Certificate Provisioning и другие части платформы: https://www.cloudflarestatus.com/.

Это не значит, что нужно отказываться от CDN. Скорее наоборот: CDN остается полезным слоем для скорости и защиты. Но владелец сайта должен понимать, что «сайт не открывается» — слишком общий симптом. За ним может стоять проблема в edge-локации, правилах кеша, SSL на CDN, маршрутизации, DNS-записях или соединении CDN с origin-сервером.

Как выглядит сбой CDN для пользователя

Сбой CDN редко выглядит одинаково у всех. Именно поэтому его легко перепутать с проблемой хостинга.

Типичные признаки:

• сайт открывается в одном городе, но не открывается в другом;
• HTML загружается, но не подгружаются CSS, JS или изображения;
• главная страница работает, а личный кабинет или корзина возвращает 502, 503 или 504;
• после очистки кеша CDN сайт внезапно начинает отдавать старую или пустую страницу;
• панель управления CDN недоступна, поэтому нельзя быстро изменить правила;
• API сайта отвечает нестабильно, хотя статические файлы открываются нормально;
• SSL-ошибка появляется только через CDN, а при прямом обращении к серверу сертификат корректен.

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

Что проверить в первую очередь

Откройте разные типы URL

Не ограничивайтесь главной страницей. Проверьте несколько адресов:

• главную страницу;
• страницу товара или услуги;
• файл стилей или скрипт;
• изображение;
• страницу авторизации;
• простой технический URL, если он есть, например health-check.

Если HTML открывается, а статика нет, вероятен сбой на уровне CDN, кеша или правил доставки файлов. Если не работает только динамический раздел, CDN может быть исправен, а ошибка находится на origin-сервере или в приложении.

Проверьте статус-код

В браузере ошибка часто выглядит упрощенно. Лучше посмотреть HTTP-ответ. На рабочем компьютере можно выполнить:

curl -I https://example.ru/

Важны не только 200, 301 или 500. Обратите внимание на заголовки, которые добавляет CDN: Via, X-Cache, CF-Cache-Status, Server, Age и похожие. У разных провайдеров названия отличаются, но смысл один: они помогают понять, кто отдал ответ — CDN или исходный сервер.

Пример: если ответ 503 приходит вместе с заголовками CDN, это еще не доказывает, что виноват CDN. CDN мог честно передать ошибку origin-сервера. Но это уже повод проверить вторую точку: доступен ли origin напрямую.

Сравните сайт через CDN и origin

Если вы знаете IP исходного сервера и понимаете, что делаете, можно проверить сайт в обход CDN. Для HTTPS это не всегда просто: сертификат и виртуальный хост должны совпадать. В типовом случае используют команду вида:

curl -I --resolve example.ru:443:203.0.113.10 https://example.ru/

IP здесь примерный. Его нельзя копировать в реальную проверку. Нужно подставить адрес своего origin-сервера.

Результаты читаются так:

• через CDN ошибка, напрямую origin отвечает 200 — вероятна проблема CDN, кеша, SSL или маршрутизации до CDN;
• через CDN 200, напрямую origin ошибка — CDN может отдавать кеш, но реальный сервер уже сломан;
• оба варианта дают ошибку — нужно проверять приложение, сервер, базу данных, лимиты хостинга или сетевую доступность;
• напрямую origin не отвечает, но CDN иногда открывает страницы — пользователи видят остатки кеша, а не полностью рабочий сайт.

Как отличить CDN от DNS-проблемы

DNS отвечает за то, куда ведет домен. CDN часто подключается через CNAME или через nameserver-провайдера. Поэтому сбой DNS и сбой CDN могут выглядеть похоже.

Проверьте, что домен вообще разрешается:

dig example.ru A dig www.example.ru CNAME

Если DNS возвращает NXDOMAIN, SERVFAIL или пустой ответ, проблема может быть не в CDN-доставке, а в доменной зоне, DNSSEC, делегировании или ошибке у DNS-провайдера. Если DNS стабильно указывает на CDN, но HTTP-запросы возвращают ошибки, двигайтесь дальше по цепочке.

Полезно проверять домен через несколько резолверов: провайдера, публичный DNS и корпоративную сеть. Иногда ошибка видна только там, где включена строгая проверка DNSSEC или где еще живет старый кеш.

Как понять, что проблема на стороне origin-сервера

CDN не заменяет сервер. Он может кешировать часть контента, но динамические страницы, формы, корзина, поиск и личный кабинет обычно зависят от origin.

Проверьте такие признаки:

• в логах сервера есть всплеск 500, 502, 503 или 504;
• база данных отвечает медленно;
• закончились ресурсы CPU, RAM или диска;
• веб-сервер отклоняет соединения от IP-адресов CDN;
• firewall или fail2ban заблокировал CDN как «подозрительный» источник;
• после деплоя изменились редиректы, cookies или заголовки кеширования;
• SSL на origin истек, хотя публичный сертификат на CDN еще действителен.

Практический пример: интернет-магазин открывается, но оформление заказа возвращает 504. Статика при этом грузится из кеша CDN. Владелец видит «сайт работает», а клиент не может купить. В такой ситуации мониторить только главную страницу недостаточно. Нужна проверка критических URL, где видна реальная бизнес-функция.

Что делать во время сбоя

Зафиксируйте симптомы

Сохраните время начала, URL, статус-коды, заголовки ответа, скриншоты ошибок и регионы, где проблема воспроизводится. Это поможет и вашей команде, и поддержке провайдера. Фраза «сайт иногда не работает» почти бесполезна. Набор фактов «страница /checkout возвращает 504 с 10:20, статика 200, origin напрямую 200, через CDN 504» уже похож на техническую задачу.

Проверьте статус-страницу провайдера

Если у CDN-провайдера есть инцидент, не нужно тратить время на хаотичную перенастройку. Но статус-страница не всегда обновляется мгновенно. Поэтому отсутствие сообщения не доказывает, что сбоя нет. Сравнивайте статус-страницу со своими проверками.

Не очищайте кеш без причины

При проблемах origin-сервера кеш CDN может временно спасать часть страниц. Массовая очистка кеша в такой момент иногда ухудшает ситуацию: CDN перестает отдавать сохраненные копии и начинает чаще обращаться к серверу, который уже перегружен. Перед purge нужно понимать, что именно вы хотите исправить.

Подготовьте аварийный план заранее

Хорошо, если до инцидента уже понятно:

• кто имеет доступ к CDN и DNS;
• где лежит IP origin-сервера;
• какие URL критичны для бизнеса;
• как временно отключить проблемное правило;
• кому писать в поддержку провайдера;
• как сообщить клиентам о сбое.

Во время аварии такие вещи вспоминаются медленно, особенно если сайт уже теряет заявки.

Почему ручной проверки недостаточно

Ручная проверка помогает разобраться в моменте, но она не ловит начало проблемы. Владелец узнает о сбое от клиента, из рекламы, из чата поддержки или случайно при открытии сайта. Это поздно.

Автоматический мониторинг нужен, чтобы регулярно проверять сайт без участия человека. Он помогает заметить:

• смену статус-кода;
• резкий рост времени ответа;
• недоступность страницы;
• ошибку на конкретном URL;
• ситуацию, когда сайт формально отвечает, но нужный текст на странице исчез;
• сбой после деплоя, изменения DNS или настройки CDN.

Чтобы не проверять сайт вручную, можно настроить автоматический мониторинг в Web-Puls. Он помогает регулярно проверять доступность сайта и быстрее узнать, если страница перестала открываться или начала отвечать ошибкой.

Какие проверки стоит настроить для сайта за CDN

Минимальный набор для небольшого проекта:

1. Главная страница — чтобы видеть общую доступность домена.
2. Важная посадочная страница — чтобы не терять рекламный трафик.
3. Страница товара, услуги или формы заявки — чтобы проверять бизнес-сценарий.
4. Статический файл — чтобы отдельно контролировать доставку CSS, JS или изображений.
5. Техническая страница проверки — если она есть и не раскрывает приватные данные.

Для интернет-магазина можно добавить страницу корзины или авторизации, но без выполнения действий, которые создают заказ или меняют данные. Для SaaS-проекта полезно следить за страницей входа, публичной документацией и API health-check.

Если проблема связана с DNS, SSL, хостингом, CDN или серверными ошибками и ее нужно не только заметить, но и разобрать технически, можно отправить заявку на платную профессиональную поддержку через форму https://web-puls.ru/support/ или воспользоваться контактами https://web-puls.ru/contacts/.

Чеклист диагностики CDN-сбоя

Используйте этот порядок, чтобы не пропустить важный слой:

1. Проверьте сайт из браузера и зафиксируйте точное сообщение об ошибке.
2. Получите HTTP-статус и заголовки ответа.
3. Откройте несколько URL: HTML, статику, динамическую страницу, форму или API.
4. Сравните доступность через разные сети: офис, мобильный интернет, внешний сервис проверки.
5. Посмотрите DNS-ответы и CNAME на CDN.
6. Если возможно, проверьте origin напрямую.
7. Сверьтесь со статус-страницей CDN-провайдера.
8. Проверьте логи origin-сервера и лимиты хостинга.
9. Не очищайте кеш и не меняйте DNS, пока не понятно, какой слой сломан.
10. После восстановления оставьте мониторинг, чтобы следующий сбой был замечен раньше.

Вывод

CDN ускоряет сайт и снижает нагрузку на сервер, но он не отменяет диагностику. Когда сайт недоступен, важно понять, где именно возникла проблема: в DNS, CDN, origin-сервере, приложении или отдельной странице. Без такого разделения легко лечить не тот слой и терять время.

Лучший подход — сочетать ручную проверку для разбора причины и автоматический мониторинг для раннего обнаружения. Тогда вы узнаете о сбое раньше клиентов, быстрее соберете факты и сможете точнее обратиться к провайдеру, разработчику или технической поддержке.