Ошибка Cloudflare 1016 Origin DNS Error означает, что Cloudflare получил запрос, но не смог определить IP-адрес исходного сервера (origin). Обычно причина находится в DNS-записи сайта или в цели CNAME, а не в браузере посетителя.
Короткий порядок действий: найдите точный hostname с ошибкой, проверьте его A/AAAA/CNAME в Cloudflare, убедитесь, что конечная цель CNAME разрешается в действующий IP, затем перепроверьте запись на авторитетных DNS-серверах. Перезапуск сайта и перевыпуск SSL-сертификата стоит отложить, пока DNS не исправлен.
Что означает ошибка 1016
Cloudflare работает между посетителем и вашим сервером. Чтобы передать запрос дальше, ему нужно знать адрес origin. Если адрес нельзя получить через DNS, Cloudflare показывает страницу 1016.
Это отличает 1016 от ошибок соединения с уже найденным сервером. При 521–524 адрес origin обычно известен, но сервер отказывается от соединения, недоступен или отвечает слишком долго. Ошибка 526 относится к проверке SSL-сертификата origin.
Официальное описание причин и специальных сценариев есть в документации Cloudflare.
Сначала зафиксируйте точку сбоя
Проверяйте точное имя из адресной строки: example.com, www.example.com, api.example.com могут иметь разные записи. Если 1016 появляется только на одном поддомене, изменение главного домена не поможет.
Перед правками сохраните точный URL, время проверки, последние изменения DNS или хостинга, а также скриншот страницы и Ray ID, если он показан. Не помещайте в скриншоты пароли, токены и закрытые адреса панелей.
Порядок диагностики Cloudflare 1016
1. Проверьте запись hostname в Cloudflare
Откройте DNS-зону и найдите имя, на котором возникает ошибка. Для обычного сайта рабочая схема выглядит так:
- A указывает на действующий IPv4-адрес origin;
- AAAA указывает на действующий IPv6-адрес origin;
- CNAME указывает на hostname, который в итоге разрешается в действующий A или AAAA.
Проверьте опечатки и неверный поддомен. После переноса сайта сравните значение с актуальными данными хостинга. Не копируйте в поле origin публичный IP проксируемого домена: это может быть адрес Cloudflare, а не вашего сервера.
Если запись отсутствует, создайте её по данным провайдера. Неизвестный адрес лучше уточнить у хостинга, а не подбирать по старым письмам или DNS-кэшам.
2. Проследите CNAME до конечной цели
CNAME перенаправляет DNS-разрешение на другое имя. Если внешний провайдер удалил это имя или его DNS возвращает NXDOMAIN/SERVFAIL, Cloudflare не сможет найти origin.
Проверьте цель отдельно:
dig target.example.net A +short
dig target.example.net AAAA +short
dig target.example.net CNAME +shortПовторяйте проверку для следующего CNAME, пока цепочка не закончится действующим A или AAAA. Пустой ответ только для A ещё не доказывает сбой: у цели может быть AAAA или следующая CNAME-запись. Если конечное имя не разрешается, исправление требуется в его DNS-зоне или у владельца внешнего сервиса.
3. Проверьте авторитетные DNS
Сначала узнайте серверы, которые отвечают за домен:
dig example.com NS +shortЗатем запросите точный hostname у одного из найденных серверов:
dig @authoritative-ns.example www.example.com A
dig @authoritative-ns.example www.example.com CNAMEПодставьте реальные NS из первого ответа. Если нужной записи нет уже там, ожидание очистки кэша не поможет: проверьте, в той ли зоне вы внесли изменение и делегирован ли домен на ожидаемые серверы.
У проксируемой записи ответ для A может содержать адрес Cloudflare. Это нормально для публичного запроса и подтверждает наличие записи, но значение origin всё равно нужно сверять в панели.
4. Проверьте переносы и внешние сервисы
Частый сценарий — сайт переехал, старый сервер или внешний hostname отключили, а CNAME остался прежним. Сравните текущую схему с данными нового хостинга и проверьте отдельно корневой домен, www и технические поддомены.
Не удаляйте записи пакетом. Сначала определите, какие имена обслуживают сайт, почту, API и подтверждение домена: у них разные назначения.
5. Учтите специальную конфигурацию
Если обычные записи корректны, проверьте используемую ветку:
- в Cloudflare Load Balancing должны разрешаться hostname задействованных origin-пулов;
- в Cloudflare for SaaS важны активный custom hostname и корректный fallback origin;
- в частичной CNAME-конфигурации запись должна существовать у авторитетного DNS-провайдера;
- для Workers и Spectrum действуют отдельные требования к целевому hostname.
Эти настройки не нужны обычному сайту с одной зоной. Не меняйте их «на всякий случай», если они не участвуют в маршруте запроса.
Что не исправляет 1016
Перезагрузка CMS, очистка кэша страницы и смена PHP не создают отсутствующую DNS-запись. Перевыпуск сертификата тоже не поможет, пока Cloudflare не может найти сервер.
Переключение записи в DNS only иногда используют для изоляции проблемы, но это меняет маршрут трафика и может раскрыть origin. Делайте это только если понимаете последствия и можете безопасно вернуть исходную схему.
Как проверить исправление
После изменения проверьте по порядку:
- запись в Cloudflare соответствует данным хостинга;
- цель CNAME разрешается до A или AAAA;
- авторитетные DNS отвечают ожидаемо;
- точный URL открывается без страницы 1016;
- критичные страницы доступны с внешней сети.
Для общего разбора DNS-сбоев пригодится материал «DNS-ошибка: почему сайт не открывается и что проверить». Если Cloudflare уже находит origin, но не может подключиться к нему, переходите к диагностике ошибок 521–524.
Как быстрее заметить повторный сбой
Web-Puls может регулярно проверять критичный URL и сообщать, если он перестал открываться. Мониторинг не исправляет DNS сам, но помогает зафиксировать начало сбоя и убедиться, что доступность восстановилась после изменений.
Если записи выглядят корректно, а 1016 сохраняется, соберите hostname, время, Ray ID и безопасное описание DNS-схемы. Отправьте это через форму профессиональной поддержки — так специалист сможет начать диагностику с конкретных данных.