Довідник помилок / Subdomain not resolving

Субдомен не працює, хоча домен відкривається

Субдомен на кшталт blog.example.com - це окреме імʼя з власним DNS-записом, тому працездатність example.com нічого про нього не каже. Строго кажучи, «не резолвиться» означає, що запит до DNS саме цього імені повернув порожньо: браузер не отримав IP і навіть не дійшов до вашого сервера, а на екрані зʼявляється DNS_PROBE_FINISHED_NXDOMAIN у Chrome, «сервер не знайдено» у Firefox або «Could not resolve host» у curl. Цю фразу вживають і ширше: імʼя резолвиться, але відкривається не той сайт, порожня сторінка хостингу чи попередження про сертифікат, а це вже інша проблема, на боці сервера. Перевірка на цій сторінці розрізняє ці два випадки за один крок, бо шукає A, AAAA і CNAME для точного імені, яке ви введете.

Перевірте свій сайт

>

Через що виникає

Найчастіше запису для цього імені просто немає або його додали не в ту зону: у реєстратора чи в старого провайдера, чиї сервери імен уже не відповідають за домен. Друга за поширеністю причина - час: щойно створений або змінений запис ще лежить у чужих кешах зі старим значенням, і поки не спливе попередній TTL, частина інтернету бачить порожнечу. Якщо ж запис існує, причина переїжджає на сервер: для цього імені не налаштовано сайт, тому відкривається типова сторінка хостингу, чужий сайт або 404, а деякі панелі створюють DNS-запис і не створюють віртуальний хост, тож правильний DNS нічого не гарантує. Рідше, але легко проґавити: CNAME, що стоїть на одному імені з іншими записами (так робити не можна, і відповіді стають непередбачуваними), wildcard *.example.com, який перебиває застарілий конкретний запис, і сертифікат, виданий лише на example.com та www, - тоді буде попередження про безпеку, а не помилка пошуку імені.

Як виправити

  1. Запустіть перевірку на цій сторінці для повного імені: blog.example.com, а не example.com. Якщо A, AAAA і CNAME порожні, запису немає або він ще не розійшовся, і виправляти треба в DNS (кроки 2-4). Якщо хоч один запис повернувся, з DNS усе гаразд, а проблема на сервері (кроки 5-6).
  2. Додайте або виправте запис у тій зоні, яку насправді обслуговують ваші сервери імен: звірте NS-записи з перевірки з провайдером, у чиїй панелі ви редагуєте DNS, бо запис у покинутій зоні ніхто не читає. Вкажіть A (і AAAA, якщо використовуєте IPv6) на IP сервера або CNAME на цільове імʼя. Якщо домен на Cloudflare, запис має бути саме в панелі Cloudflare, і для проксійованого запису нормально бачити адреси Cloudflare, а не ваш IP.
  3. Не змішуйте типи записів на одному імені: CNAME має бути єдиним записом для цього імені, тому поруч не повинно лишатися ні A, ні MX, ні TXT. Якщо розраховуєте на wildcard *.example.com, приберіть застарілий конкретний запис для цього субдомена: конкретний запис завжди має пріоритет над wildcard, а багато провайдерів застосовують wildcard лише на один рівень углиб.
  4. Дайте час TTL, перш ніж робити висновки: після правки повторіть перевірку через 5-30 хвилин, спробуйте ще й з мобільного інтернету і почистіть власний кеш через ipconfig /flushdns (Windows), dscacheutil -flushcache (macOS) або chrome://net-internals/#dns. Зміна серверів імен усього домену, на відміну від одного запису, розходиться помітно довше.
  5. Якщо перевірка повернула запис, відкрийте субдомен і подивіться, що саме відповідає сервер: типова сторінка хостингу, чужий сайт або 404 означають, що для цього імені не налаштовано жодного віртуального хоста. Додайте субдомен у панелі керування хостингом або впишіть імʼя у ServerName/server_name віртуального хоста і перезавантажте вебсервер, а також перевірте, що корінь сайту вказує на потрібну теку.
  6. Якщо ж браузер лається на сертифікат, значить, сертифікат не покриває це імʼя: перевипустіть його разом із субдоменом або візьміть wildcard-сертифікат. Там, де SSL видається автоматично, замовляйте випуск лише після того, як DNS-запис почав резолвитися, бо перевірка вимагає робочого імені.

Схожі помилки