> ## Documentation Index
> Fetch the complete documentation index at: https://docs.axottle.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Устранение неполадок CDN

> Типовые сценарии: зависшие операции, конфликты DNS, проблемы с аккаунтом, частичный откат.

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

<Info>Для кого: администратор панели, SRE. Требуемые права: управление CDN и Connection Units.</Info>

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

<Steps>
  <Step title="Аккаунт провайдера">
    Откройте карточку аккаунта и нажмите **Проверить ключи**. Ожидаемый статус — `valid`. `permission_limited` перечислит недостающие роли, `invalid` — значит ключи не проходят аутентификацию.
  </Step>

  <Step title="Операция">
    Откройте раздел **CDN** и найдите последнюю операцию нужного ресурса. Проверьте её шаг и код ошибки.
  </Step>

  <Step title="Ресурс и блок">
    Откройте Connection Unit → **Холст** и выберите CDN-блок. Сверьте домен, аккаунт и текущий статус.
  </Step>

  <Step title="Origin">
    Убедитесь, что входная нода имеет домен и отвечает по HTTPS с валидным сертификатом — без этого провижининг не начнётся.
  </Step>

  <Step title="DNS-зона">
    Проверьте, что зона, покрывающая домен ноды, существует у провайдера и аккаунт имеет к ней доступ (`dns.editor`).
  </Step>
</Steps>

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

### Операция застряла на шаге 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` (блок соединён не с одним нодой). Проверьте также схему графа: <a href="/ru/connection-units/routing">Маршрутизация</a>.

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

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

## Проверка

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

## Откат

Если восстановить провижининг не удаётся:

* готовый CDN деинсталлируйте удалением CDN-блока из Connection Unit с последующим применением — прямой откат `READY`-операции запрещён (HTTP 409);
* подробности — в статье <a href="/ru/cdn/resources-and-operations">Ресурсы и операции</a>.

Связанные страницы: <a href="/ru/cdn/observability">Справочник кодов ошибок</a>, <a href="/ru/cdn/providers">Провайдеры и аккаунты</a>, <a href="/ru/cdn/dns">DNS и Cloudflare AutoDNS</a>.

<Note>Проверено для версии Axottle текущей ветки. Дата проверки: 2026-07-11.</Note>