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

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

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

Коротко: сначала получите HTTP-ответ публичного домена, затем сравните его с origin и проверьте DNS. Не меняйте настройки CDN и не очищайте кеш, пока не определили проблемный слой.

Что сделать прямо сейчас

Начните с точного адреса, на котором посетитель увидел ошибку: страницы услуги, товара, формы, корзины или API. Вставьте этот URL в разовую проверку Web-Puls. Она покажет HTTP-код, время ответа и базовые признаки проблемы на публичном пути через CDN. Форма быстрой проверки находится и внизу статьи; IP origin в нее вводить не нужно.

Сохраните результат вместе со временем проверки, затем отдельно сравните его с ответом origin, если его адрес известен ответственному специалисту. Дальнейшее действие зависит от расхождения:

1. Публичный URL и origin возвращают ожидаемый ответ — повторите проверку во время следующей жалобы и поставьте критичный URL на мониторинг.
2. Публичный URL дает таймаут или 5xx, а origin отвечает нормально — сохраните заголовки CDN и проверьте его статус, SSL, правила и маршрут до origin.
3. Публичный URL и origin одновременно дают ошибку — переходите к логам сервера, приложения и базы данных: CDN, вероятно, только передает сбой.
4. Ошибка возникает только в части сетей или регионов — зафиксируйте сеть, регион и время, затем сопоставьте их с логами CDN/WAF и повторными проверками.

Повторяющийся сбой требует истории внешних проверок, а текущая ошибка, которая уже мешает заявкам, оплате или рекламе, — технической диагностики. В обоих случаях сначала нужны URL, время, код ответа и описание последнего изменения.

Как проверить доступность CDN

Проверка CDN должна отвечать на два вопроса: доступен ли сайт посетителю и отвечает ли origin-сервер без промежуточного слоя. Для первичной диагностики:

1. Откройте публичный URL и получите его HTTP-код и заголовки ответа.
2. Проверьте тот же hostname из другой сети или региона.
3. Сравните загрузку HTML, изображения или CSS-файла и динамической страницы.
4. Если известен IP origin, безопасно сравните ответ напрямую с правильным hostname.
5. Сверьте результат со статус-страницей CDN и логами исходного сервера.

Разовая проверка сайта покажет публичный ответ, DNS и базовые признаки CDN. Сравнение с origin нужно выполнять отдельно: не публикуйте его IP и не отключайте защиту ради теста.

Если публичный домен возвращает 203, 521, 522, 523 или 524, используйте отдельный чеклист по HTTP 203 и ошибкам Cloudflare 521–524. Код 203 означает успешный ответ через промежуточный узел, а 521–524 показывают, на каком этапе CDN потеряла связь с origin.

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

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

Публичные статус-страницы помогают быстро проверить массовый инцидент. Например, Gcore отдельно публикует состояние CDN и маршрутизации, а Cloudflare разделяет статусы CDN/Cache, Dashboard, API, DNS и выпуска сертификатов на своей странице состояния.

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

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

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

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

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

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

Три типовых сценария CDN-сбоя

Кеш скрывает падение origin. Главная страница отвечает 200 OK из кеша, но карточка товара, форма или API возвращает 504. Проверьте публично и через origin не только главную, но и критичный динамический URL. В мониторинг добавьте обе страницы как отдельные проверки.

Ошибка возникает только через CDN. Origin стабильно отдает ожидаемую страницу, а публичный домен отвечает 502, 525, 526 или таймаутом. Не очищайте весь кеш: сначала сохраните заголовки ответа, проверьте SSL-режим CDN, разрешенные IP на origin и статус провайдера.

Сбой виден только части посетителей. Из одной сети сайт открывается, а из другой появляется 403, 429, TLS-ошибка или таймаут. Зафиксируйте точное время и проблемную сеть, сравните DNS и конечный IP, затем проверьте правила WAF, геофильтры и состояние нужной edge-локации.

Эти сценарии требуют разных действий: в первом нужен контроль бизнес-URL и origin, во втором — разбор связи CDN с origin, в третьем — данные из проблемной сети. Один успешный ответ главной страницы не закрывает ни один из трех случаев.

Чем деградация CDN отличается от полного сбоя

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

Проверяйте деградацию как матрицу, а не одной командой:

| Что сравнить | На что смотреть | |---|---| | Один URL несколько раз | чередование 200, 5xx и таймаутов, разброс времени ответа | | HTML, статика и API | какой класс ресурсов ухудшился | | Несколько сетей или регионов | привязана ли проблема к отдельной edge-локации или маршруту | | Публичный домен и origin | ухудшает ли ответ CDN или исходный сервер | | Кешированные ответы и cache miss | возникает ли задержка только при обращении к origin |

Панель CDN дополняет внешнюю проверку, но не заменяет ее. Cloudflare Cache Analytics показывает, какая доля трафика обслуживается из кеша и какие URL уходят на origin. Amazon CloudFront публикует operational metrics и позволяет строить сигналы, например по доле ответов 5xx. Для своего проекта задайте базовый уровень времени ответа и допустимую долю ошибок заранее: универсальный порог без учета трафика и бизнес-URL будет произвольным.

Считайте восстановление подтвержденным, когда критичные URL стабильно отвечают из нужных сетей, время ответа вернулось к обычному диапазону, ошибки не повторяются, а поведение кеша и origin соответствует настройкам. Одного зеленого статуса провайдера или одного успешного запроса недостаточно.

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

Откройте разные типы 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. Промежуточный сервер мог передать ошибку origin. Поэтому следующим шагом проверьте исходный сервер напрямую.

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

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

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

Важно: IP 203.0.113.10 приведен только как пример. Подставьте адрес своего origin-сервера и не публикуйте его, если CDN используется для защиты источника.

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

• через 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

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

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

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

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

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

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

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

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

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

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

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

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

Результаты этих проверок лучше хранить вместе: публичный URL, время, код, регион, заголовки CDN и ответ origin образуют диагностический контекст, которого нет у одиночного скриншота.

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

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

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

Источники

• Cloudflare Cache Analytics
• Amazon CloudFront: мониторинг метрик через CloudWatch

Вывод

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

Если сбой повторяется и влияет на заявки, оплату или рекламу, добавьте критичный URL в мониторинг Web-Puls. Перед настройкой сохраните время, код, регион и заголовки ответа — так проверка будет контролировать конкретный риск, а не только главную страницу.