Як виправити помилку «IP-адресу сервера не вдалося знайти»

Помилка "Server IP address could not be found" означає, що ваш браузер надіслав DNS-запит для доменного імені та не отримав у відповідь жодної дійсної IP-адреси — тому TCP-з’єднання так і не було встановлено. Першопричина майже завжди криється у збої десь у ланцюжку DNS-розпізнавання: застарілий локальний кеш, неправильно налаштований резолвер, затримка поширення після зміни DNS-запису або справжній збій на стороні сервера.

Цей посібник охоплює кожен рівень цього ланцюжка — від власного DNS-кешу браузера до рекурсивного резолвера вашого провайдера та авторитетного сервера імен — з точними командами, деталями на рівні реєстру та граничними випадками, які типові посібники пропускають.

Що насправді відбувається під час DNS-розпізнавання

Перш ніж розпочати усунення несправностей, розуміння шляху розпізнавання допоможе уникнути зайвих зусиль. Коли ви вводите URL у браузер, наступна послідовність пошуку виконується по порядку:

1. DNS-кеш браузера — Chrome, Firefox та Edge кожен підтримують власний DNS-кеш у пам’яті, окремо від ОС.
2. Кеш резолвера ОС — служба Windows DNS Client або macOS mDNSResponder перевіряє свій локальний кеш.
3. Файл hosts — статичний файл перевизначення, який має пріоритет над усіма мережевими методами розпізнавання.
4. Налаштований DNS-резолвер — зазвичай ваш маршрутизатор (що діє як форвардер) або безпосередньо налаштований публічний резолвер, наприклад `8.8.8.8`.
5. Рекурсивний резолвер провайдера — резолвер вашого провайдера запитує глобальну ієрархію DNS, якщо у нього немає кешованої відповіді.
6. Авторитетний сервер імен — остаточне джерело істини для записів A/AAAA домену.

Збій на будь-якому з цих етапів призводить до однієї й тієї ж загальної помилки браузера. Знання того, який рівень зламано, визначає, яке виправлення застосувати першим.

Крок 1: Перевірте URL та визначте масштаб проблеми

Цей крок здається тривіальним, але одразу усуває дві найпоширеніші причини.

• Перевірте наявність друкарських помилок в адресному рядку, включаючи неправильні TLD (`.co` проти `.com`, `.net` проти `.org`).
• Перевірте другий домен, який, як ви знаєте, працює (наприклад, `google.com`). Якщо він також не відкривається, проблема стосується всієї мережі на вашому пристрої, а не конкретного домену.
• Перевірте з мобільного пристрою через мобільні дані (не Wi-Fi). Якщо сайт там завантажується, проблема локальна для вашої мережі або пристрою.
• Виконайте швидкий DNS-пошук з командного рядка, щоб обійти браузер повністю:

“`bash

Windows / macOS / Linux

nslookup example.com

“`

Якщо `nslookup` повертає IP-адресу, але браузер все одно видає помилку, проблема стосується конкретно браузера. Якщо `nslookup` також не спрацьовує, проблема знаходиться на рівні резолвера ОС або глибше.

Крок 2: Очистіть внутрішній DNS-кеш браузера

Кожен основний браузер кешує DNS-записи незалежно від операційної системи. Очищення лише кешу ОС без урахування кешу браузера є поширеною помилкою.

Google Chrome та Edge (на основі Chromium):

Перейдіть за наступною внутрішньою URL-адресою в адресному рядку:

“`

chrome://net-internals/#dns

“`

Натисніть "Clear host cache". Потім перейдіть до:

“`

chrome://net-internals/#sockets

“`

Натисніть "Flush socket pools", щоб також очистити застарілі TCP-з’єднання, прив’язані до старих IP-адрес.

Firefox:

Firefox не надає прямого інтерфейсу для очищення DNS. Найнадійніший метод:

1. Відкрийте `about:config` в адресному рядку.
2. Знайдіть `network.dnsCacheExpiration`.
3. Тимчасово встановіть значення `0`, перезавантажте сторінку, потім відновіть до `60` (за замовчуванням).

Як альтернатива, перезапуск Firefox із закритими всіма вкладками повністю очищає його DNS-кеш.

Очищення файлів cookie та кешованих файлів браузера також може допомогти, коли задіяна петля перенаправлення або застаріла відповідь:

• Chrome: Меню > Додаткові інструменти > Видалити дані веб-перегляду > виберіть Кешовані зображення та файли та Файли cookie та інші дані сайтів > Видалити дані.

Крок 3: Очистіть DNS-кеш операційної системи

DNS-кеш резолвера на рівні ОС зберігає записи до закінчення їхнього TTL. Якщо домен нещодавно змінив свої DNS-записи (наприклад, міграція сервера або зміна IP), ваш пристрій може зберігати старий, тепер недійсний запис довго після закінчення його TTL через помилку резолвера або дуже високий початковий TTL.

Windows (всі версії):

Відкрийте командний рядок від імені адміністратора та виконайте:

“`cmd

ipconfig /flushdns

“`

Очікуваний результат: `Successfully flushed the DNS Resolver Cache.`

Для більш ретельного скидання також очистіть кеш NetBIOS:

“`cmd

nbtstat -R

“`

macOS (команди для конкретних версій):

Linux (systemd-resolved):

“`bash

sudo systemd-resolve –flush-caches

sudo systemd-resolve –statistics # Verify cache was cleared

“`

Якщо використовується `nscd`:

“`bash

sudo service nscd restart

“`

Крок 4: Перезапустіть маршрутизатор та оновіть IP-оренду

Ваш домашній маршрутизатор зазвичай діє як DNS-форвардер — він отримує ваші DNS-запити та пересилає їх до резолвера вашого провайдера. Маршрутизатор із пошкодженою ARP-таблицею або застарілою DHCP-орендою може спричиняти збої DNS, які виглядають ідентично проблемам на стороні сервера.

Процедура перезапуску маршрутизатора:

1. Вимкніть маршрутизатор та від’єднайте його від джерела живлення.
2. Зачекайте повних 30 секунд (конденсаторам потрібно розрядитися для справжнього холодного перезавантаження).
3. Увімкніть його знову та зачекайте, поки всі індикатори стабілізуються, перш ніж тестувати.

Оновіть свою IP-адресу після перезапуску маршрутизатора:

*Windows:*

“`cmd

ipconfig /release

ipconfig /renew

“`

*macOS:*

Перейдіть до Системні налаштування > Мережа > виберіть активний інтерфейс > Деталі > TCP/IP > Оновити DHCP-оренду.

*Linux:*

“`bash

sudo dhclient -r && sudo dhclient

“`

Граничний випадок: Якщо ви перебуваєте в корпоративній або університетській мережі з резервуваннями DHCP, оновлення оренди може не змінити вашу IP-адресу, але оновить призначення DNS-серверів, що передаються параметром DHCP 6. Це саме по собі може вирішити проблему, якщо ваш IT-відділ нещодавно змінив адреси своїх внутрішніх DNS-серверів.

Крок 5: Перейдіть на надійний публічний DNS-резолвер

Рекурсивний резолвер вашого провайдера часто є найслабшою ланкою. Резолвери провайдерів можуть страждати від отруєння кешу, перехоплення NXDOMAIN (перенаправлення невдалих пошуків на рекламні сторінки) або простих збоїв. Перехід на добре підтримуваний публічний резолвер часто є найшвидшим виправленням.

Порівняння DNS-резолверів

Як змінити DNS у Windows:

1. Відкрийте Панель керування > Центр мереж і спільного доступу > Змінити параметри адаптера.
2. Клацніть правою кнопкою миші на активному мережевому адаптері > Властивості.
3. Виберіть Протокол Інтернету версії 4 (TCP/IPv4) > Властивості.
4. Виберіть Використовувати такі адреси DNS-серверів та введіть обраний резолвер.
5. Повторіть для Протоколу Інтернету версії 6 (TCP/IPv6), використовуючи IPv6-адреси обраного резолвера (наприклад, Cloudflare IPv6: `2606:4700:4700::1111` та `2606:4700:4700::1001`).
6. Натисніть OK та знову виконайте `ipconfig /flushdns`, щоб очистити всі кешовані записи від старого резолвера.

Як змінити DNS на macOS:

1. Системні налаштування > Мережа > виберіть інтерфейс > Деталі > DNS.
2. Натисніть кнопку + та додайте бажані DNS-адреси.
3. Видаліть старі записи, призначені провайдером.
4. Натисніть OK > Застосувати.

Важливий нюанс: Зміна DNS на рівні ОС не впливає на застосунки, які використовують власне вбудоване DNS-розпізнавання (наприклад, деякі VPN-клієнти, певні браузери з увімкненим DNS-over-HTTPS). Перевірте налаштування DNS вашого браузера окремо.

Крок 6: Перевірте та виправте файл hosts

Файл hosts — це локальний статичний DNS-перевизначувач, який має абсолютний пріоритет над усіма мережевими методами розпізнавання. Один неправильний або шкідливий запис може непомітно заблокувати цілий домен. Шкідливе програмне забезпечення часто атакує цей файл, щоб перенаправляти або блокувати певні домени.

Розташування файлу hosts у Windows:

“`

C:WindowsSystem32driversetchosts

“`

Відкрийте за допомогою Блокнота, запущеного від імені адміністратора. Легітимний файл hosts повинен містити лише:

“`

127.0.0.1 localhost

::1 localhost

“`

Будь-які додаткові записи, що вказують домен на `0.0.0.0`, `127.0.0.1` або будь-яку несподівану IP-адресу, слід дослідити та видалити, якщо вони не авторизовані.

Файл hosts у macOS / Linux:

“`bash

sudo nano /etc/hosts

“`

Шукайте будь-які рядки, що не є коментарями (рядки, що починаються з `#`) і посилаються на домен, до якого ви намагаєтеся отримати доступ. Видаліть їх, збережіть файл (`Ctrl+X`, потім `Y` у nano) та очистіть DNS-кеш, як описано в кроці 3.

Порада: Після редагування файлу hosts у Windows необхідно очистити DNS-кеш за допомогою `ipconfig /flushdns`, щоб зміни набули чинності негайно без перезавантаження.

Крок 7: Вимкніть конфлікти VPN, проксі та DNS-over-HTTPS

VPN-клієнти та конфігурації проксі є одними з найбільш недооцінених причин збоїв DNS-розпізнавання, особливо в корпоративних середовищах.

Витоки та збої DNS, пов’язані з VPN:

Коли VPN активний, він зазвичай встановлює віртуальний мережевий адаптер та перенаправляє всі DNS-запити через VPN-тунель до внутрішнього резолвера провайдера. Якщо VPN-з’єднання обривається, але віртуальний адаптер залишається активним, DNS-запити надсилаються в мертвий тунель і завершуються тайм-аутом. Повністю вимкніть VPN-клієнт (не просто відключіться) та перевірте.

Вимкнення проксі у Windows:

Параметри > Мережа та Інтернет > Проксі > вимкніть Використовувати проксі-сервер та Автоматично визначати параметри (останнє може спричиняти затримки через виявлення WPAD).

Конфлікти DNS-over-HTTPS (DoH):

Chrome, Firefox та Edge можна налаштувати на використання певного DoH-провайдера, повністю обходячи резолвер ОС. Якщо цей DoH-провайдер недоступний або неправильно налаштований, DNS-розпізнавання мовчки завершується невдачею.

• Chrome: Налаштування > Конфіденційність і безпека > Безпека > Використовувати безпечний DNS — перевірте налаштованого провайдера або перейдіть на «З вашим поточним постачальником послуг».
• Firefox: Налаштування > Загальні > прокрутіть до Параметри мережі > Налаштування > перевірте параметр Увімкнути DNS через HTTPS та налаштованого провайдера.

Крок 8: Оновіть або перевстановіть драйвери мережевого адаптера

Пошкоджені або застарілі драйвери мережевого адаптера можуть спричиняти переривчасті збої DNS, втрату пакетів та розриви з’єднання, що проявляються як помилки DNS.

Windows:

1. Натисніть `Win + X` > Диспетчер пристроїв.
2. Розгорніть Мережеві адаптери.
3. Клацніть правою кнопкою миші на активному адаптері > Оновити драйвер > Автоматичний пошук драйверів.
4. Якщо Windows не знаходить оновлення, відвідайте веб-сайт виробника адаптера (Intel, Realtek, Broadcom) та завантажте останній драйвер безпосередньо.
5. Для повного перевстановлення: клацніть правою кнопкою миші на адаптері > Видалити пристрій > поставте прапорець Видалити програмне забезпечення драйвера для цього пристрою > перезавантажте. Windows перевстановить чистий драйвер під час перезапуску.

Розширене скидання мережевого стека Windows (використовуйте, коли оновлення драйверів не допомагає):

“`cmd

netsh winsock reset

netsh int ip reset

ipconfig /flushdns

ipconfig /registerdns

“`

Перезавантажте після виконання всіх чотирьох команд. Це скидає каталог Winsock та стек TCP/IP до стандартних значень, вирішуючи проблеми, спричинені шкідливим ПЗ, невдалим видаленням VPN-програмного забезпечення або пошкодженими записами стека.

Крок 9: Діагностика проблем на стороні сервера та поширення DNS

Якщо всі кроки на стороні клієнта не допомогли, проблема може бути зовнішньою — або DNS-записи домену не розпізнаються глобально, або сам сервер недоступний.

Перевірте, чи розпізнається домен із зовнішніх точок спостереження:

Використовуйте ці інструменти для запиту домену з кількох глобальних місць одночасно:

• dnschecker.org — Показує поширення запису A через 100+ глобальних серверів імен.
• whatsmydns.net — Перевіряє поширення DNS для записів A, CNAME, MX та інших типів.
• downforeveryoneorjustme.com — Підтверджує, чи сайт глобально недоступний, чи недоступний лише з вашого місця розташування.

Затримки поширення DNS:

Якщо домен нещодавно змінив свій запис A, сервери імен або хостинг, поширення може тривати від кількох хвилин до 48 годин залежно від значення TTL, встановленого на старому записі. Протягом цього часу деякі резолвери у світі повертатимуть стару (тепер недійсну) IP-адресу, тоді як інші повертатимуть нову. Це проблема на стороні сервера/адміністрування DNS, а не на стороні клієнта.

Якщо ви самостійно керуєте доменом і нещодавно перенесли свій сайт на новий сервер — наприклад, переїхали на середовище VPS Хостинг — переконайтеся, що запис A у вашій DNS-зоні вказує на IP-адресу нового сервера та що старий TTL повністю закінчився.

Перевірте авторитетний сервер імен безпосередньо:

“`bash

Query the authoritative nameserver directly, bypassing all caches

nslookup example.com ns1.yourdnshost.com

“`

Якщо авторитетний сервер імен повертає правильну IP-адресу, але ваш локальний резолвер — ні, проблема полягає в поширенні кешу. Якщо сам авторитетний сервер імен не повертає жодного запису або повертає неправильний запис, конфігурацію DNS-зони необхідно виправити.

Крок 10: Зверніться до свого провайдера або хостинг-провайдера

Якщо домен правильно розпізнається із зовнішніх точок спостереження, але не з вашої мережі, резолвер вашого провайдера може фільтрувати, блокувати або повертати неправильні результати для цього домену. Це трапляється частіше, ніж більшість користувачів усвідомлює — деякі провайдери впроваджують блокування на рівні DNS для дотримання нормативних вимог, і ці блокування іноді зачіпають легітимні домени.

Перевірте, тимчасово використовуючи інший резолвер (як описано в кроці 5). Якщо домен правильно розпізнається з `8.8.8.8`, але не з резолвером вашого провайдера, зверніться до провайдера та повідомте про конкретний домен як неправильно заблокований або кешований.

Якщо ви власник сайту і ваші користувачі повідомляють про цю помилку, проблема може бути пов’язана з конфігурацією вашого хостингу. Перевірте:

• Запис A вашого домену вказує на правильну IP-адресу сервера.
• Ваші SSL-сертифікати дійсні та не спричиняють петель перенаправлення, що перешкоджають початковому з’єднанню.
• Ваші сервери імен правильно налаштовані у вашого провайдера реєстрації доменів.
• Ваш сервер дійсно працює та веб-служба (Apache, Nginx) активна.

Для сайтів із великим трафіком або критично важливих сайтів розгляньте можливість переходу на виділений сервер, щоб усунути проблеми зі спільними ресурсами, які можуть спричиняти переривчасті збої DNS або підключення.

Порівняння: причини на стороні клієнта та сервера

Практична матриця рішень та ключові висновки

Пройдіть цей контрольний список по порядку, щоб мінімізувати час діагностики:

• Спочатку визначте масштаб. Помилка стосується одного домену, одного браузера, одного пристрою або всієї мережі? Це єдине питання усуває 80% нерелевантних кроків.
• Виконайте `nslookup` перед зміною будь-яких налаштувань. Якщо він розпізнає IP, виправлення на рівні браузера. Якщо не вдається, виправлення на рівні ОС або глибше.
• Очищайте в правильному порядку: спочатку DNS-кеш браузера, потім DNS-кеш ОС, потім перезапуск маршрутизатора. Виконання у зворотному порядку витрачає час.
• Завжди очищайте DNS-кеш ОС після зміни налаштувань DNS-сервера. Новий резолвер не буде запитуватися для доменів, вже кешованих під старим резолвером, поки кеш не буде очищено.
• Перевірте файл hosts, якщо домен нещодавно працював і раптово перестав. Це є сильним індикатором шкідливого ПЗ або неправильно налаштованого інструменту безпеки.
• Використовуйте `netsh winsock reset` у Windows лише як останній засіб — він скидає всі записи Winsock, включаючи легітимні записи, додані програмним забезпеченням на кшталт VPN-клієнтів, які може знадобитися перевстановити після цього.
• Якщо ви власник сайту, перевіряйте записи своєї DNS-зони одразу після будь-якої міграції сервера. Якщо ви запускаєте свій сайт на VPS з cPanel, редактор DNS-зон WHM надає прямий доступ до всіх записів. Якщо ви на спільному веб-хостингу, використовуйте розділ керування DNS у панелі керування хостингом, щоб підтвердити актуальність запису A.
• Для збоїв DNS, пов’язаних з електронною поштою (записи MX не розпізнаються), перевірте конфігурацію сервера імен вашого провайдера поштового хостингу окремо — записи MX є незалежними від записів A і можуть виходити з ладу незалежно.

FAQ

Чому помилка «server IP address could not be found» з’являється лише в Chrome, але не у Firefox?

Chrome та Firefox підтримують окремі внутрішні DNS-кеші та можуть бути налаштовані на використання різних DNS-over-HTTPS провайдерів. Якщо Chrome має застарілий або пошкоджений запис кешу, або його DoH-провайдер недоступний, він завершиться невдачею, тоді як Firefox успішно використовуватиме резолвер ОС. Перейдіть до `chrome://net-internals/#dns` та натисніть «Clear host cache», щоб вирішити цю проблему.

Скільки часу займає поширення DNS після зміни запису A домену?

Час поширення залежить від значення TTL (Time To Live), встановленого на записі до зміни. Якщо старий TTL становив 3600 секунд (1 година), більшість резолверів кешуватимуть старий запис до однієї години. Якщо TTL становив 86400 секунд (24 години), поширення може тривати до 48 годин у граничних випадках. Зниження TTL до 300 секунд за кілька годин до запланованої міграції значно скорочує час поширення.

Чи може брандмауер або антивірус спричиняти цю помилку DNS?

Так. Програмне забезпечення безпеки, що включає DNS-фільтрацію (Windows Defender, Malwarebytes, Kaspersky тощо), може перехоплювати та блокувати DNS-запити для доменів, позначених як шкідливі. Якщо помилка з’явилася одразу після встановлення або оновлення програмного забезпечення безпеки, тимчасово вимкніть компонент DNS-захисту (не весь антивірус) та перевірте. Також перевірте, чи не додало програмне забезпечення записи до вашого файлу hosts.

У чому різниця між `ipconfig /flushdns` та `netsh winsock reset`?

`ipconfig /flushdns` очищає лише кеш резолвера DNS Windows — він видаляє кешовані DNS-записи, щоб наступний запит надійшов до налаштованого резолвера з нуля. `netsh winsock reset` скидає весь каталог Windows Sockets API до стандартного стану, виправляючи глибше пошкодження самого мережевого стека. Скидання Winsock вимагає перезавантаження та повинно використовуватися лише тоді, коли очищення DNS та оновлення драйверів не вирішили проблему.

Якщо домен правильно розпізнається через `nslookup`, але браузер все одно показує помилку, що слід перевірити?

Цей сценарій зазвичай вказує на одну з трьох причин: внутрішній DNS-кеш браузера все ще містить застарілий запис (очистіть його через `chrome://net-internals/#dns`), пул сокетів браузера має застаріле з’єднання (очистіть через `chrome://net-internals/#sockets`), або розширення браузера (особливо проксі або VPN-розширення) перехоплює та не виконує DNS-запит. Вимкніть усі розширення та перевірте у приватному/інкогніто вікні, щоб ізолювати втручання розширень.