Cum să Remediați Eroarea „Adresa IP a Serverului Nu a Putut Fi Găsită”
Eroarea "Adresa IP a serverului nu a putut fi găsită" înseamnă că browserul dvs. a trimis o interogare DNS pentru un nume de domeniu și nu a primit nicio adresă IP validă ca răspuns — astfel că nu a fost inițiată nicio conexiune TCP. Cauza principală este aproape întotdeauna o defecțiune undeva în lanțul de rezoluție DNS: un cache local învechit, un resolver configurat greșit, o întârziere de propagare după o modificare a înregistrărilor DNS sau o întrerupere reală a serverului.
Acest ghid acoperă fiecare nivel al acelui lanț — de la cache-ul DNS propriu al browserului până la resolverul recursiv al ISP-ului dvs. și serverul de nume autoritar — cu comenzi exacte, detalii la nivel de registru și cazurile limită pe care tutorialele generice le omit.
Ce se întâmplă de fapt în timpul rezoluției DNS
Înainte de depanare, înțelegerea căii de rezoluție previne efortul irosit. Când introduceți un URL într-un browser, următoarea secvență de căutare se declanșează în ordine:
- Cache-ul DNS al browserului — Chrome, Firefox și Edge mențin fiecare propriul cache DNS în memorie, separat de sistemul de operare.
- Cache-ul resolverului OS — Serviciul Windows DNS Client sau macOS mDNSResponder verifică cache-ul local.
- Fișierul Hosts — Un fișier de suprascrierea statică care are prioritate față de toate rezoluțiile bazate pe rețea.
- Resolverul DNS configurat — De obicei routerul dvs. (acționând ca un forwarder) sau un resolver public configurat direct, cum ar fi `8.8.8.8`.
- Resolverul recursiv al ISP-ului — Resolverul ISP-ului dvs. interoghează ierarhia DNS globală dacă nu are un răspuns în cache.
- Serverul de nume autoritar — Sursa finală de adevăr pentru înregistrările A/AAAA ale domeniului.
O defecțiune la oricare dintre aceste etape produce aceeași eroare generică de browser. Știind care nivel este defect determină ce remediere să aplicați mai întâi.
Pasul 1: Verificați URL-ul și testați domeniul de aplicare
Acest pas pare trivial, dar elimină imediat două dintre cele mai frecvente cauze.
- Verificați greșelile de tastare din bara de adrese, inclusiv TLD-urile incorecte (`.co` vs `.com`, `.net` vs `.org`).
- Testați un al doilea domeniu despre care știți că este activ (de ex., `google.com`). Dacă acela eșuează de asemenea, problema este la nivelul întregii rețele pe mașina dvs., nu specifică domeniului.
- Testați de pe un dispozitiv mobil cu date celulare (nu Wi-Fi). Dacă site-ul se încarcă acolo, problema este locală la rețeaua sau mașina dvs.
- Rulați o căutare DNS rapidă din linia de comandă pentru a ocoli complet browserul:
“`bash
Windows / macOS / Linux
nslookup example.com
“`
Dacă `nslookup` returnează o adresă IP, dar browserul afișează în continuare eroarea, problema este specifică browserului. Dacă `nslookup` eșuează de asemenea, problema se află la nivelul resolverului OS sau mai adânc.
Pasul 2: Ștergeți cache-ul DNS intern al browserului
Fiecare browser major stochează înregistrările DNS independent de sistemul de operare. Ștergerea doar a cache-ului OS ignorând cache-ul browserului este o omisiune frecventă.
Google Chrome și Edge (bazate pe Chromium):
Navigați la următorul URL intern din bara de adrese:
“`
chrome://net-internals/#dns
“`
Faceți clic pe "Clear host cache". Apoi navigați la:
“`
chrome://net-internals/#sockets
“`
Faceți clic pe "Flush socket pools" pentru a șterge și conexiunile TCP învechite legate de adresele IP vechi.
Firefox:
Firefox nu expune o interfață directă de ștergere DNS. Metoda cea mai fiabilă este:
- Deschideți `about:config` în bara de adrese.
- Căutați `network.dnsCacheExpiration`.
- Setați temporar valoarea la `0`, reîncărcați pagina, apoi restaurați-o la `60` (valoarea implicită).
Alternativ, repornirea Firefox cu toate filele închise șterge complet cache-ul DNS.
Ștergerea cookie-urilor și a fișierelor din cache ale browserului poate ajuta și atunci când este implicată o buclă de redirecționare sau un răspuns învechit:
- Chrome: Meniu > More Tools > Clear Browsing Data > selectați Cached images and files și Cookies and other site data > Clear data.
Pasul 3: Ștergeți cache-ul DNS al sistemului de operare
Cache-ul resolverului DNS la nivel de OS stochează înregistrările până la expirarea TTL-ului lor. Dacă un domeniu și-a schimbat recent înregistrările DNS (de ex., o migrare de server sau o schimbare de IP), mașina dvs. poate păstra înregistrarea veche, acum invalidă, mult după expirarea TTL-ului, din cauza unui bug al resolverului sau a unui TTL original foarte ridicat.
Windows (toate versiunile):
Deschideți Command Prompt ca Administrator și rulați:
“`cmd
ipconfig /flushdns
“`
Rezultat așteptat: `Successfully flushed the DNS Resolver Cache.`
Pentru o resetare mai completă, ștergeți și cache-ul NetBIOS:
“`cmd
nbtstat -R
“`
macOS (comenzi specifice versiunii):
| Versiune macOS | Comandă |
|---|
| — | — |
|---|
| Ventura / Sonoma (13/14) | `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder` |
|---|
| Monterey (12) | `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder` |
|---|
| Big Sur (11) | `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder` |
|---|
| Catalina / Mojave (10.15/10.14) | `sudo killall -HUP mDNSResponder` |
|---|
| High Sierra și versiuni anterioare | `sudo killall -HUP mDNSResponder; sudo dscacheutil -flushcache` |
|---|
Linux (systemd-resolved):
“`bash
sudo systemd-resolve –flush-caches
sudo systemd-resolve –statistics # Verify cache was cleared
“`
Dacă folosiți `nscd` în schimb:
“`bash
sudo service nscd restart
“`
Pasul 4: Reporniți routerul și reînnoiți contractul de leasing IP
Routerul dvs. de acasă acționează de obicei ca un forwarder DNS — primește interogările DNS și le transmite resolverului ISP-ului dvs. Un router cu un tabel ARP corupt sau un leasing DHCP învechit poate cauza defecțiuni DNS care arată identic cu problemele de pe server.
Procedura de repornire a routerului:
- Opriți routerul și deconectați-l de la sursa de alimentare.
- Așteptați 30 de secunde complete (condensatoarele trebuie să se descarce pentru o repornire la rece adevărată).
- Porniți-l din nou și așteptați ca toate luminile indicatoare să se stabilizeze înainte de testare.
Reînnoiți adresa IP după repornirea routerului:
*Windows:*
“`cmd
ipconfig /release
ipconfig /renew
“`
*macOS:*
Navigați la System Settings > Network > selectați interfața activă > Details > TCP/IP > Renew DHCP Lease.
*Linux:*
“`bash
sudo dhclient -r && sudo dhclient
“`
Caz limită: Dacă vă aflați pe o rețea corporativă sau universitară cu rezervări DHCP, reînnoirea leasingului poate să nu schimbe IP-ul dvs., dar va reîmprospăta atribuirile serverului DNS transmise prin opțiunea DHCP 6. Acest lucru singur poate rezolva problema dacă echipa IT a schimbat recent adresele serverelor DNS interne.
Pasul 5: Treceți la un resolver DNS public fiabil
Resolverul recursiv al ISP-ului dvs. este adesea veriga cea mai slabă. Resolverii ISP pot suferi de otrăvire a cache-ului, deturnare NXDOMAIN (redirecționarea căutărilor eșuate către pagini de reclame) sau simple întreruperi. Trecerea la un resolver public bine întreținut este adesea cea mai rapidă remediere.
Comparație resolvere DNS
| Furnizor | DNS Primar | DNS Secundar | Suport Protocol | Caracteristică Notabilă |
|---|
| — | — | — | — | — |
|---|
| Google Public DNS | `8.8.8.8` | `8.8.4.4` | DNS-over-HTTPS, DNS-over-TLS | Disponibilitate extrem de ridicată, anycast global |
|---|
| Cloudflare | `1.1.1.1` | `1.0.0.1` | DNS-over-HTTPS, DNS-over-TLS | Cel mai rapid timp mediu de răspuns la nivel global |
|---|
| OpenDNS (Cisco) | `208.67.222.222` | `208.67.220.220` | Standard UDP/TCP | Filtrare opțională a conținutului |
|---|
| Quad9 | `9.9.9.9` | `149.112.112.112` | DNS-over-HTTPS, DNS-over-TLS | Blocare malware prin informații despre amenințări |
|---|
| NextDNS | Personalizat | Personalizat | DNS-over-HTTPS, DNS-over-TLS | Filtrare complet configurabilă per dispozitiv |
|---|
Cum să schimbați DNS pe Windows:
- Deschideți Control Panel > Network and Sharing Center > Change adapter settings.
- Faceți clic dreapta pe adaptorul de rețea activ > Properties.
- Selectați Internet Protocol Version 4 (TCP/IPv4) > Properties.
- Selectați Use the following DNS server addresses și introduceți resolverul ales.
- Repetați pentru Internet Protocol Version 6 (TCP/IPv6) folosind adresele IPv6 ale resolverului ales (de ex., Cloudflare IPv6: `2606:4700:4700::1111` și `2606:4700:4700::1001`).
- Faceți clic pe OK și rulați din nou `ipconfig /flushdns` pentru a șterge orice intrări din cache de la resolverul vechi.
Cum să schimbați DNS pe macOS:
- System Settings > Network > selectați interfața > Details > DNS.
- Faceți clic pe butonul + și adăugați adresele DNS preferate.
- Eliminați intrările vechi atribuite de ISP.
- Faceți clic pe OK > Apply.
Nuanță critică: Schimbarea DNS la nivel de OS nu afectează aplicațiile care folosesc propria rezoluție DNS internă (de ex., unii clienți VPN, anumite browsere cu DNS-over-HTTPS activat). Verificați separat setările DNS ale browserului dvs.
Pasul 6: Inspectați și corectați fișierul Hosts
Fișierul hosts este o suprascrierea DNS statică locală care are prioritate absolută față de toate rezoluțiile bazate pe rețea. O singură intrare malformată sau malițioasă poate bloca silențios un întreg domeniu. Programele malware vizează frecvent acest fișier pentru a redirecționa sau bloca domenii specifice.
Locația fișierului hosts pe Windows:
“`
C:WindowsSystem32driversetchosts
“`
Deschideți cu Notepad rulat ca Administrator. Un fișier hosts legitim ar trebui să conțină doar:
“`
127.0.0.1 localhost
::1 localhost
“`
Orice intrări suplimentare care indică un domeniu către `0.0.0.0`, `127.0.0.1` sau orice adresă IP neașteptată ar trebui investigate și eliminate dacă sunt neautorizate.
Fișierul hosts pe macOS / Linux:
“`bash
sudo nano /etc/hosts
“`
Căutați orice linii care nu sunt comentarii (linii care încep cu `#`) și care fac referire la domeniul pe care încercați să îl accesați. Eliminați-le, salvați fișierul (`Ctrl+X`, apoi `Y` în nano) și ștergeți cache-ul DNS conform descrierii din Pasul 3.
Sfat pro: După editarea fișierului hosts pe Windows, trebuie să ștergeți cache-ul DNS cu `ipconfig /flushdns` pentru ca modificarea să intre în vigoare imediat fără repornire.
Pasul 7: Dezactivați conflictele VPN, Proxy și DNS-over-HTTPS
Clienții VPN și configurațiile proxy sunt printre cele mai trecute cu vederea cauze ale defecțiunilor de rezoluție DNS, în special în mediile enterprise.
Scurgeri și defecțiuni DNS legate de VPN:
Când un VPN este activ, instalează de obicei un adaptor de rețea virtual și redirecționează toate interogările DNS prin tunelul VPN către resolverul intern al furnizorului. Dacă conexiunea VPN se întrerupe, dar adaptorul virtual rămâne activ, interogările DNS sunt trimise într-un tunel mort și expiră. Dezactivați complet clientul VPN (nu doar deconectați) și testați.
Dezactivați proxy pe Windows:
Settings > Network & Internet > Proxy > dezactivați Use a proxy server și Automatically detect settings (acesta din urmă poate cauza întârzieri prin descoperirea WPAD).
Conflicte DNS-over-HTTPS (DoH):
Chrome, Firefox și Edge pot fi configurate să folosească un furnizor DoH specific, ocolind complet resolverul OS. Dacă acel furnizor DoH este inaccesibil sau configurat greșit, rezoluția DNS eșuează silențios.
- Chrome: Settings > Privacy and security > Security > Use secure DNS — verificați furnizorul configurat sau treceți la „With your current service provider.”
- Firefox: Settings > General > derulați la Network Settings > Settings > verificați opțiunea Enable DNS over HTTPS și furnizorul configurat.
Pasul 8: Actualizați sau reinstalați driverele adaptorului de rețea
Driverele de adaptor de rețea corupte sau depășite pot cauza defecțiuni DNS intermitente, pierderi de pachete și întreruperi de conexiune care se manifestă ca erori DNS.
Windows:
- Apăsați `Win + X` > Device Manager.
- Extindeți Network Adapters.
- Faceți clic dreapta pe adaptorul activ > Update driver > Search automatically for drivers.
- Dacă Windows nu găsește nicio actualizare, vizitați site-ul web al producătorului adaptorului (Intel, Realtek, Broadcom) și descărcați direct cel mai recent driver.
- Pentru o reinstalare completă: faceți clic dreapta pe adaptor > Uninstall device > bifați Delete the driver software for this device > reporniți. Windows va reinstala un driver curat la repornire.
Resetare avansată a stivei de rețea Windows (utilizați când actualizările de driver nu ajută):
“`cmd
netsh winsock reset
netsh int ip reset
ipconfig /flushdns
ipconfig /registerdns
“`
Reporniți după rularea tuturor celor patru comenzi. Aceasta resetează catalogul Winsock și stiva TCP/IP la valorile implicite, rezolvând problemele cauzate de malware, dezinstalări eșuate de software VPN sau intrări corupte în stivă.
Pasul 9: Diagnosticați problemele de pe server și de propagare DNS
Dacă toți pașii de pe partea clientului eșuează, problema poate fi externă — fie înregistrările DNS ale domeniului nu se rezolvă la nivel global, fie serverul însuși este inaccesibil.
Verificați dacă domeniul se rezolvă din puncte de vedere externe:
Folosiți aceste instrumente pentru a interoga domeniul din mai multe locații globale simultan:
- dnschecker.org — Afișează propagarea înregistrărilor A pe 100+ servere de nume globale.
- whatsmydns.net — Verifică propagarea DNS pentru înregistrările A, CNAME, MX și alte tipuri de înregistrări.
- downforeveryoneorjustme.com — Confirmă dacă site-ul este inaccesibil la nivel global sau doar din locația dvs.
Întârzieri de propagare DNS:
Dacă un domeniu și-a schimbat recent înregistrarea A, serverele de nume sau găzduirea, propagarea poate dura de la câteva minute până la 48 de ore, în funcție de valoarea TTL setată pe înregistrarea veche. În această perioadă, unii resolveri din lume vor returna adresa IP veche (acum invalidă), în timp ce alții returnează cea nouă. Aceasta este o problemă de administrare server/DNS, nu o problemă de pe partea clientului.
Dacă gestionați singur domeniul și ați migrat recent site-ul pe un server nou — de exemplu, mutând pe un mediu VPS Hosting — verificați că înregistrarea A din zona DNS indică adresa IP a noului server și că TTL-ul vechi a expirat complet.
Verificați direct serverul de nume autoritar:
“`bash
Query the authoritative nameserver directly, bypassing all caches
nslookup example.com ns1.yourdnshost.com
“`
Dacă serverul de nume autoritar returnează IP-ul corect, dar resolverul local nu, problema este propagarea cache-ului. Dacă serverul de nume autoritar însuși nu returnează nicio înregistrare sau returnează o înregistrare incorectă, configurația zonei DNS trebuie corectată.
Pasul 10: Contactați ISP-ul sau furnizorul de găzduire
Dacă domeniul se rezolvă corect din puncte de vedere externe, dar nu din rețeaua dvs., resolverul ISP-ului dvs. poate filtra, bloca sau returna rezultate incorecte pentru acel domeniu. Acest lucru este mai frecvent decât realizează majoritatea utilizatorilor — unii ISP implementează blocarea la nivel DNS pentru conformitate cu reglementările, iar aceste blocări prind ocazional domenii legitime.
Testați folosind temporar un resolver diferit (conform descrierii din Pasul 5). Dacă domeniul se rezolvă corect cu `8.8.8.8` dar nu cu resolverul ISP-ului dvs., contactați ISP-ul și raportați domeniul specific ca blocat sau stocat incorect în cache.
Dacă sunteți proprietarul site-ului și utilizatorii dvs. raportează această eroare, problema poate fi cu configurația de găzduire. Verificați:
- Înregistrarea A a domeniului dvs. indică IP-ul corect al serverului.
- Certificatele SSL sunt valide și nu cauzează bucle de redirecționare care împiedică conexiunea inițială.
- Serverele de nume sunt setate corect la furnizorul dvs. de Înregistrare Domenii.
- Serverul dvs. funcționează efectiv și serviciul web (Apache, Nginx) este activ.
Pentru site-uri cu trafic ridicat sau critice pentru misiune, luați în considerare trecerea la un Server Dedicat pentru a elimina problemele de resurse partajate care pot cauza defecțiuni intermitente DNS sau de conectivitate.
Comparație: Cauze de pe partea clientului vs. cauze de pe server
| Simptom | Cauză Probabilă | Locație Remediere |
|---|
| — | — | — |
|---|
| Eroare pe un browser, funcționează în altul | Cache DNS al browserului sau configurație DoH | Client — setări browser |
|---|
| Eroare pe toate browserele, funcționează pe date mobile | Cache DNS OS sau resolver ISP | Client — ștergeți cache-ul, schimbați DNS |
|---|
| Eroare pe toate dispozitivele din rețea | Problemă DNS router sau întrerupere ISP | Router sau ISP |
|---|
| Eroare doar pentru un domeniu specific | Propagare DNS sau configurație greșită a zonei | Partea server/admin DNS |
|---|
| Eroare la nivel global (confirmat via dnschecker.org) | Server oprit sau zonă DNS ștearsă | Furnizor găzduire / admin server |
|---|
| Eroare după instalare/dezinstalare VPN | Winsock corupt sau rutare DNS | Client — resetare netsh |
|---|
Matrice de decizie practică și concluzii cheie
Parcurgeți această listă de verificare în ordine pentru a minimiza timpul de diagnosticare:
- Confirmați mai întâi domeniul de aplicare. Afectează eroarea un domeniu, un browser, un dispozitiv sau întreaga rețea? Această singură întrebare elimină 80% din pașii irelevanți.
- Rulați `nslookup` înainte de a modifica orice setări. Dacă rezolvă IP-ul, remedierea este la nivel de browser. Dacă eșuează, remedierea este la nivel de OS sau mai adânc.
- Ștergeți în ordinea corectă: mai întâi cache-ul DNS al browserului, apoi cache-ul DNS al OS, apoi repornirea routerului. A le face în ordine inversă irosește timp.
- Ștergeți întotdeauna cache-ul DNS al OS după schimbarea setărilor serverului DNS. Noul resolver nu va fi interogat pentru domeniile deja stocate în cache sub resolverul vechi până când cache-ul nu este șters.
- Verificați fișierul hosts dacă domeniul funcționa recent și s-a oprit brusc. Acesta este un indicator puternic de malware sau un instrument de securitate configurat greșit.
- Folosiți `netsh winsock reset` pe Windows doar ca ultimă soluție — resetează toate intrările Winsock, inclusiv intrările legitime adăugate de software precum clienții VPN, care pot necesita reinstalare ulterioară.
- Dacă sunteți proprietarul site-ului, verificați înregistrările zonei DNS imediat după orice migrare de server. Dacă rulați site-ul pe un VPS cu cPanel, WHM DNS Zone Editor oferă acces direct la toate înregistrările. Dacă sunteți pe Găzduire Web Shared, folosiți secțiunea de gestionare DNS din panoul de control al găzduirii pentru a confirma că înregistrarea A este actuală.
- Pentru defecțiuni DNS legate de email (înregistrările MX nu se rezolvă), verificați separat configurația serverelor de nume ale furnizorului dvs. de Găzduire Email — înregistrările MX sunt independente de înregistrările A și pot eșua independent.
Întrebări frecvente
De ce apare eroarea „server IP address could not be found” doar în Chrome, nu și în Firefox?
Chrome și Firefox mențin cache-uri DNS interne separate și pot fi configurate să folosească furnizori DNS-over-HTTPS diferiți. Dacă Chrome are o intrare în cache învechită sau coruptă, sau furnizorul său DoH este inaccesibil, va eșua în timp ce Firefox reușește folosind resolverul OS. Navigați la `chrome://net-internals/#dns` și faceți clic pe „Clear host cache” pentru a rezolva aceasta.
Cât durează propagarea DNS după schimbarea înregistrării A a unui domeniu?
Timpul de propagare depinde de valoarea TTL (Time To Live) setată pe înregistrare înainte de modificare. Dacă TTL-ul vechi era de 3600 secunde (1 oră), majoritatea resolverilor vor stoca în cache înregistrarea veche până la o oră. Dacă TTL-ul era de 86400 secunde (24 ore), propagarea poate dura până la 48 de ore în cazuri limită. Reducerea TTL-ului la 300 secunde cu câteva ore înainte de o migrare planificată reduce semnificativ timpul de propagare.
Poate un firewall sau un antivirus cauza această eroare DNS?
Da. Software-ul de securitate care include filtrare DNS (Windows Defender, Malwarebytes, Kaspersky etc.) poate intercepta și bloca interogările DNS pentru domenii marcate ca malițioase. Dacă eroarea a apărut imediat după instalarea sau actualizarea software-ului de securitate, dezactivați temporar componenta de protecție DNS (nu întregul antivirus) și testați. Verificați și dacă software-ul a adăugat intrări în fișierul hosts.
Care este diferența dintre `ipconfig /flushdns` și `netsh winsock reset`?
`ipconfig /flushdns` șterge doar cache-ul resolverului DNS Windows — elimină înregistrările DNS stocate în cache astfel încât următoarea interogare să meargă la resolverul configurat proaspăt. `netsh winsock reset` resetează întregul catalog Windows Sockets API la starea sa implicită, remediind corupția mai profundă din stiva de rețea în sine. Resetarea Winsock necesită o repornire și ar trebui folosită doar când ștergerea DNS și actualizările de driver nu au rezolvat problema.
Dacă domeniul se rezolvă corect prin `nslookup` dar browserul afișează în continuare eroarea, ce ar trebui să verific?
Acest scenariu indică de obicei una dintre trei cauze: cache-ul DNS intern al browserului păstrează în continuare o înregistrare învechită (ștergeți-o prin `chrome://net-internals/#dns`), pool-ul de socket-uri al browserului are o conexiune învechită (ștergeți prin `chrome://net-internals/#sockets`), sau o extensie de browser (în special extensii proxy sau VPN) interceptează și eșuează cererea DNS. Dezactivați toate extensiile și testați într-o fereastră privată/incognito pentru a izola interferența extensiilor.
