Как да поправим грешката „IP адресът на сървъра не може да бъде намерен”

Грешката "Server IP address could not be found" означава, че браузърът ви е изпратил DNS заявка за домейн и не е получил валиден IP адрес в отговор — така че не е бил направен опит за TCP връзка. Основната причина почти винаги е повреда някъде в DNS веригата за разрешаване: остарял локален кеш, неправилно конфигуриран резолвър, забавяне на разпространението след промяна на DNS запис или реален срив на сървъра.

Това ръководство обхваща всеки слой от тази верига — от вътрешния DNS кеш на браузъра до рекурсивния резолвър на вашия интернет доставчик и авторитетния сървър за имена — с точни команди, подробности на ниво регистър и крайни случаи, които общите ръководства пропускат.

Какво всъщност се случва по време на DNS разрешаване

Преди да започнете отстраняване на проблеми, разбирането на пътя на разрешаване предотвратява загубата на усилия. Когато въведете URL адрес в браузър, следната последователност от търсения се изпълнява по ред:

1. DNS кеш на браузъра — Chrome, Firefox и Edge поддържат собствен DNS кеш в паметта, отделен от операционната система.
2. Кеш на OS резолвъра — Услугата 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` също се провали, проблемът е на ниво OS резолвър или по-дълбоко.

Стъпка 2: Изчистете вътрешния DNS кеш на браузъра

Всеки основен браузър кешира DNS записи независимо от операционната система. Изчистването само на OS кеша, като се игнорира кешът на браузъра, е честа грешка.

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 кеша му.

Изчистването на бисквитките и кешираните файлове на браузъра също може да помогне, когато е налице цикъл на пренасочване или остарял отговор:

• Chrome: Меню > Още инструменти > Изчистване на данните за сърфиране > изберете Кеширани изображения и файлове и Бисквитки и други данни на сайта > Изчистване на данните.

Стъпка 3: Изчистете DNS кеша на операционната система

DNS кешът на резолвъра на ниво OS съхранява записи до изтичането на техния TTL. Ако даден домейн наскоро е променил DNS записите си (напр. миграция на сървър или промяна на IP адрес), вашата машина може да задържа стария, вече невалиден запис дълго след изтичането на TTL му поради грешка в резолвъра или много висок оригинален TTL.

Windows (всички версии):

Отворете Command Prompt като Администратор и изпълнете:

“`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 на ниво OS не засяга приложения, които използват собствено вградено DNS разрешаване (напр. някои VPN клиенти, определени браузъри с активиран DNS-over-HTTPS). Проверете DNS настройките на браузъра си отделно.

Стъпка 6: Прегледайте и коригирайте hosts файла

Hosts файлът е локален статичен DNS заместител, който има абсолютен приоритет пред всяко мрежово разрешаване. Един единствен неправилно форматиран или злонамерен запис може безшумно да блокира цял домейн. Зловредният софтуер често атакува този файл, за да пренасочи или блокира конкретни домейни.

Местоположение на hosts файла в Windows:

“`

C:WindowsSystem32driversetchosts

“`

Отворете с Notepad, стартиран като Администратор. Легитимният 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 discovery).

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

Chrome, Firefox и Edge могат да бъдат конфигурирани да използват конкретен DoH доставчик, заобикаляйки напълно OS резолвъра. Ако този DoH доставчик е недостъпен или неправилно конфигуриран, DNS разрешаването се проваля безшумно.

• Chrome: Настройки > Поверителност и сигурност > Сигурност > Използване на защитен DNS — проверете конфигурирания доставчик или превключете на „С вашия текущ доставчик на услуги”.
• Firefox: Настройки > Общи > превъртете до Мрежови настройки > Настройки > проверете опцията Активиране на DNS over 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) е активна.

За сайтове с голям трафик или критично значение, помислете за преминаване към Dedicated сървър, за да елиминирате проблеми със споделени ресурси, които могат да причинят периодични DNS или свързаност повреди.

Сравнение: Причини от страна на клиента срещу причини от страна на сървъра

Практическа матрица за вземане на решения и основни изводи

Преминете през този контролен списък по ред, за да минимизирате времето за диагностика:

• Първо потвърдете обхвата. Грешката засяга ли един домейн, един браузър, едно устройство или цялата мрежа? Този единствен въпрос елиминира 80% от нерелевантните стъпки.
• Изпълнете `nslookup` преди да промените каквито и да е настройки. Ако разреши IP адреса, решението е на ниво браузър. Ако се провали, решението е на ниво OS или по-дълбоко.
• Изчиствайте в правилния ред: първо DNS кешът на браузъра, след това DNS кешът на OS, след това рестартиране на рутера. Правенето им в обратен ред губи време.
• Винаги изчиствайте OS DNS кеша след промяна на настройките на DNS сървъра. Новият резолвър няма да бъде запитан за домейни, вече кеширани под стария резолвър, докато кешът не бъде изчистен.
• Проверете hosts файла, ако домейнът е работил наскоро и внезапно е спрял. Това е силен индикатор за зловреден софтуер или неправилно конфигуриран инструмент за сигурност.
• Използвайте `netsh winsock reset` в Windows само като последна мярка — нулира всички Winsock записи, включително легитимни записи, добавени от софтуер като VPN клиенти, които може да се наложи да бъдат преинсталирани след това.
• Ако сте собственик на сайт, проверете DNS зоната си незабавно след всяка миграция на сървър. Ако управлявате сайта си на VPS с cPanel, редакторът на DNS зони в WHM предоставя директен достъп до всички записи. Ако сте на Споделен уеб хостинг, използвайте секцията за управление на DNS в контролния панел на хостинга, за да потвърдите, че A записът е актуален.
• За DNS повреди, свързани с имейл (MX записи, които не се разрешават), проверете конфигурацията на сървърите за имена на вашия доставчик на Имейл хостинг отделно — MX записите са независими от A записите и могат да се провалят независимо.

Често задавани въпроси

Защо грешката „server IP address could not be found” се появява само в Chrome, но не и в Firefox?

Chrome и Firefox поддържат отделни вътрешни DNS кешове и могат да бъдат конфигурирани да използват различни DNS-over-HTTPS доставчици. Ако Chrome има остарял или повреден кеш запис, или DoH доставчикът му е недостъпен, той ще се провали, докато Firefox успява, използвайки OS резолвъра. Навигирайте до `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` изчиства само кеша на Windows DNS резолвъра — премахва кешираните DNS записи, така че следващата заявка отива директно към конфигурирания резолвър. `netsh winsock reset` нулира целия каталог на Windows Sockets API до неговото стандартно състояние, поправяйки по-дълбока корупция в самия мрежов стек. Нулирането на Winsock изисква рестартиране и трябва да се използва само когато изчистването на DNS и актуализациите на драйверите не са разрешили проблема.

Ако домейнът се разрешава правилно чрез `nslookup`, но браузърът все още показва грешка, какво трябва да проверя?

Този сценарий обикновено сочи към една от три причини: вътрешният DNS кеш на браузъра все още съдържа остарял запис (изчистете го чрез `chrome://net-internals/#dns`), пулът от сокети на браузъра има остаряла връзка (изчистете чрез `chrome://net-internals/#sockets`), или разширение на браузъра (особено прокси или VPN разширения) прихваща и проваля DNS заявката. Деактивирайте всички разширения и тествайте в частен/инкогнито прозорец, за да изолирате намесата на разширения.