Перейти к основному содержанию
Почти любая проблема с CDN диагностируется по коду ошибки операции и статусу аккаунта. Начните с порядка диагностики ниже, затем перейдите к своему сценарию.
Для кого: администратор панели, SRE. Требуемые права: управление CDN и Connection Units.

​
Порядок диагностики

1

Аккаунт провайдера

Откройте карточку аккаунта и нажмите Проверить ключи. Ожидаемый статус — valid. permission_limited перечислит недостающие роли, invalid — значит ключи не проходят аутентификацию.
2

Операция

Откройте раздел CDN и найдите последнюю операцию нужного ресурса. Проверьте её шаг и код ошибки.
3

Ресурс и блок

Откройте Connection Unit → Холст и выберите CDN-блок. Сверьте домен, аккаунт и текущий статус.
4

Origin

Убедитесь, что входная нода имеет домен и отвечает по HTTPS с валидным сертификатом — без этого провижининг не начнётся.
5

DNS-зона

Проверьте, что зона, покрывающая домен ноды, существует у провайдера и аккаунт имеет к ней доступ (dns.editor).

​
Типовые сценарии

​
Операция застряла на шаге DNS

Симптомы: состояние DNS_PENDING или PROPAGATING долго не меняется; коды DNS_RECORD_CONFLICT, DNS_PROPAGATION_TIMEOUT.
  1. Проверьте, что аккаунт имеет доступ к DNS-зоне домена ноды — код CDN_DOMAIN_SETUP_FAILED означает, что зон не видно или ни одна не покрывает домен.
  2. При DNS_RECORD_CONFLICT найдите в зоне записи, конфликтующие с доменом доставки (cdn.node.example.com) или с challenge-записями сертификата, и уберите их.
  3. При DNS_PROPAGATION_TIMEOUT проверьте делегирование зоны и повторите применение Connection Unit позже — повторное применение безопасно (операции идемпотентны).

​
Операция застряла на шаге TLS

Симптомы: состояние CERTIFICATE_PENDING; коды CERTIFICATE_VALIDATION_PENDING, CERTIFICATE_ISSUE_FAILED.
  1. Проверьте роль certificate-manager.editor у сервисного аккаунта.
  2. Выпуск сертификата подтверждается через DNS — если challenge-запись не публикуется, смотрите сценарий про DNS выше.
  3. CERTIFICATE_VALIDATION_PENDING означает, что сертификат не выпустился за окно ожидания: повторите применение — операция продолжит с текущего места.

​
Конфликт DNS-записей

Код DNS_RECORD_CONFLICT. В зоне уже есть запись, мешающая опубликовать CNAME домена доставки или challenge-запись. Удалите или переименуйте конфликтующую запись в консоли DNS-провайдера и повторите применение. Не создавайте записи для cdn.<домен-ноды> вручную — этим управляет панель.

​
Аккаунт invalid / expired / permission_limited

  • invalid — ключи не проходят аутентификацию: проверьте, что вставлен полный авторизованный ключ (JSON целиком) и корректный Folder ID; замените ключи через редактирование аккаунта — панель перепроверит их автоматически.
  • expired — срок действия учётных данных истёк: выпустите новые ключи у провайдера и обновите аккаунт.
  • permission_limited — не хватает ролей: панель перечисляет недостающие (для Yandex Cloud — cdn.editor, certificate-manager.editor, dns.editor). Выдайте роли сервисному аккаунту и нажмите Проверить ключи. Для VK Cloud, Selectel и Beget этот статус ожидаем: провайдер ещё не квалифицирован для автоматизации.
Помните: секреты write-only — посмотреть сохранённые ключи нельзя, только заменить новыми.

​
ROLLBACK_PARTIAL: что доделать руками

Откат восстанавливает DNS из снимков, удаляет созданные у провайдера артефакты (CDN-ресурс, origin-группу, сертификат) и освобождает домен доставки. Если часть шагов не удалась, ответ отката перечисляет незавершённые пункты, а операция помечается как требующая внимания.
  1. Прочитайте список незавершённых пунктов в ответе отката / статусе операции.
  2. В консоли провайдера вручную удалите оставшиеся артефакты: CDN-ресурс, origin-группу, сертификат.
  3. В DNS-зоне проверьте записи домена доставки и challenge-записи — приведите их к состоянию «до операции».
  4. После ручной зачистки повторное применение Connection Unit начнёт провижининг заново с чистого состояния.

​
Квалификация провайдера не пройдена

Код NEEDS_QUALIFICATION, блок в статусе blocked. Два случая:
  • Провайдер-кандидат (VK Cloud, Selectel, Beget) или Timeweb: автоматический провижининг для них ещё не доступен — используйте Yandex Cloud для автоматизации либо ручной режим (настройка в консоли провайдера самостоятельно). Сроки квалификации уточняются.
  • Функциональные пробы не прошли (например, CACHE_BYPASS_UNPROVEN): устраните причину и повторно примените Connection Unit — пробы выполнятся заново, и при успехе ресурс перейдёт в ready без пересоздания.

​
Применение Connection Unit падает из-за CDN

Так и задумано (fail-closed): конфигурация не применяется, пока CDN не готов. Смотрите код ошибки в статусе CDN-блока и операции; частые причины — ORIGIN_TLS_FAILED (нет валидного HTTPS на ноде), CDN_AUTOMATION_NOT_AVAILABLE (нет готового аккаунта), CDN_BLOCK_ENTRY_NODE_REQUIRED (блок соединён не с одним нодой). Проверьте также схему графа: Маршрутизация.

​
Когда обращаться в поддержку

  • UNKNOWN_MUTATION_RESULT — состояние аренды домена рассинхронизировано и требует сверки; не пытайтесь чинить пересозданием блоков.
  • ROLLBACK_PARTIAL, который не удаётся закрыть ручной зачисткой.
  • Повторяющиеся PROVIDER_SCHEMA_MISMATCH или PROVIDER_OPERATION_TIMEOUT при работающем сервисе провайдера.
  • Любая ситуация, когда операция «зависла» в промежуточном состоянии и не реагирует ни на повторное применение, ни на откат.

​
Проверка

Проблема решена, когда операция достигла READY, CDN-блок в Connection Unit показывает ready с доменом доставки, а статус аккаунта — valid.

​
Откат

Если восстановить провижининг не удаётся:
  • готовый CDN деинсталлируйте удалением CDN-блока из Connection Unit с последующим применением — прямой откат READY-операции запрещён (HTTP 409);
  • подробности — в статье Ресурсы и операции.
Связанные страницы: Справочник кодов ошибок, Провайдеры и аккаунты, DNS и Cloudflare AutoDNS.
Проверено для версии Axottle текущей ветки. Дата проверки: 2026-07-11.