ERR_CONNECTION_REFUSED: Ce înseamnă și cum să o rezolvi complet

Eroarea ERR_CONNECTION_REFUSED înseamnă că browserul tău a trimis o cerere de conexiune la un server web, iar acel server a respins-o în mod activ — nu a ignorat-o, ci a refuzat în mod explicit handshake-ul TCP. Aceasta este un mod de eșec fundamental diferit de o expirare a timpului (ERR_CONNECTION_TIMED_OUT) sau o eșec DNS (ERR_NAME_NOT_RESOLVED), iar această distincție contează enorm atunci când diagnostichezi cauza rădăcinii.

În termeni practici, când Chrome afișează “Acest site nu poate fi accesat. ERR_CONNECTION_REFUSED,” înseamnă unul din trei lucruri: serverul țintă nu ascultă pe portul solicitat, un firewall sau un strat de securitate trimite un pachet TCP RST (reset) înapoi la clientul tău, sau stack-ul tău de rețea local este configurat greșit și rutează cererea incorect înainte ca aceasta să ajungă vreodată la server. Identificarea care din aceste trei categorii se aplică situației tale este cea mai rapidă cale către o soluție.

Înțelegerea mecanicii la nivel TCP

Majoritatea ghidurilor de depanare a browserului tratează ERR_CONNECTION_REFUSED ca o problemă de rețea vagă. Nu este. La nivelul TCP, o conexiune refuzată înseamnă că serverul (sau un intermediar) a trimis înapoi un pachet RST/ACK în răspuns la pachetul SYN al browserului dvs. Aceasta este o respingere explicită, nu o cădere silențioasă.

Această distincție are o implicație practică de diagnostic: dacă conexiunea ar fi cădută în tăcere de un firewall, ați vedea ERR_CONNECTION_TIMED_OUT. O conexiune refuzată înseamnă că ceva răspunde în mod activ — ceea ce înseamnă că gazda este accesibilă la nivel de rețea, dar serviciul pe portul țintă nu este disponibil sau este blocat.

Cauzele comune la nivel de port includ:

• Procesul serverului web (Apache, Nginx, Node.js) s-a prăbușit sau s-a oprit
• Serverul ascultă pe un port non-standard și URL-ul nu îl specifică
• Un firewall bazat pe gazdă (iptables, ufw, Windows Defender Firewall) respinge conexiunile pe portul 80 sau 443
• Un proxy invers (HAProxy, Nginx, Cloudflare) este configurat incorect și returnează pachete RST în amonte
• Aplicația din spatele proxy-ului s-a prăbușit, lăsând proxy-ul fără un backend către care să redirecționeze

Cauze Principale: O Analiză Structurată

Cauze pe Partea Client

Cauze pe Partea Server

Ghid de Diagnostic și Reparare Pas cu Pas

Pasul 1: Determinați dacă Problema Este Globală sau Locală

Înainte de a modifica orice setări locale, stabiliți dacă site-ul este inactiv pentru toată lumea sau doar pentru dvs. Utilizați aceste instrumente:

• downforeveryoneorjustme.com — verificare simplă sus/jos
• isitdownrightnow.com — include istoricul timpului de răspuns
• ping.pe — face ping țintei din mai multe locații globale simultan

Dacă site-ul este accesibil din noduri externe, dar nu de pe mașina dvs., problema este locală. Dacă este inaccesibil la nivel global, problema este pe server și nu este sub controlul dvs. — contactați administratorul site-ului sau așteptați.

Pentru administratorii de server care gestionează propria infrastructură, un site inaccesibil la nivel global justifică o investigație imediată a procesului serverului web, regulilor firewall-ului și rețelei upstream. Dacă rulați un mediu VPS Hosting, verificați mai întâi lista proceselor serverului și configurația firewall-ului.

Pasul 2: Verificați că Serverul Ascultă Efectiv (Pentru Administratorii de Server)

Dacă administrați serverul în cauză, conectați-vă prin SSH și rulați următoarele pentru a confirma ce ascultă pe care porturi:

sudo ss -tlnp | grep -E ':80|:443'

Dacă ieșirea este goală pentru portul 80 sau 443, procesul serverului web nu rulează. Reporniți-l:

# For Nginx
sudo systemctl restart nginx

# For Apache
sudo systemctl restart apache2

# Check status
sudo systemctl status nginx

De asemenea, verificați că firewall-ul dvs. nu blochează conexiunile de intrare:

# Check iptables rules
sudo iptables -L INPUT -n -v

# If using ufw
sudo ufw status verbose

Dacă portul 443 este blocat, permiteți-l:

sudo ufw allow 443/tcp
sudo ufw allow 80/tcp
sudo ufw reload

Pentru administratorii care rulează Dedicated Servers, verificați de asemenea dacă regulile firewall-ului upstream sau grupul de securitate al furnizorului de hosting blochează portul la perimetrul rețelei — aceasta este separat de firewall-ul la nivel OS.

Pasul 3: Reporniți Routerul și Curățați Starea Rețelei Locale

Pentru problemele pe partea client, o repornire a routerului șterge tabelele NAT, leasurile DHCP și orice eșecuri de rutare tranzitorii. Deconectați routerul timp de 30 de secunde, apoi reconectați-l. Aceasta este deosebit de eficace atunci când eroarea a apărut brusc fără nicio schimbare de configurație.

Pasul 4: Curățați Cache-ul DNS

O intrare de cache DNS veche care indică o adresă IP veche sau dezafectată este una dintre cele mai frecvente cauze ale ERR_CONNECTION_REFUSED pe partea client. Serverul de la adresa IP din cache poate să nu mai ruleze site-ul țintă.

• Pe Windows:

ipconfig /flushdns

• Pe macOS (Ventura, Sonoma și majoritatea versiunilor moderne):

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

• Pe Linux (systemd-resolved):

sudo systemd-resolve --flush-caches

După curățare, verificați la ce IP se rezolvă acum domeniul:

nslookup example.com
# or
dig +short example.com

Comparați aceasta cu IP-ul cunoscut al site-ului. Dacă diferă, propagarea DNS poate fi încă în curs.

Pasul 5: Curățați Cache-ul și Cookie-urile Browserului

În Google Chrome, navigați la chrome://settings/clearBrowserData sau utilizați combinația de taste:

• Windows/Linux: Ctrl + Shift + Delete
• macOS: Cmd + Shift + Delete

Setați intervalul de timp la Toată perioada, bifați Imagini și fișiere în cache și Cookie-uri și alte date de site, apoi faceți clic pe Ștergeți datele. Reporniți Chrome complet (nu doar fila) înainte de a retesta.

Pentru un test mai rapid fără a șterge datele, deschideți o fereastră Incognito (Ctrl + Shift + N). Dacă site-ul se încarcă în Incognito, dar nu într-o fereastră normală, o resursă din cache sau o extensie de browser este vinovată.

Pasul 6: Auditați și Dezactivați Setările Proxy

Un server proxy configurat incorect sau mort este o cauză frecventă a ERR_CONNECTION_REFUSED pe toate site-urile simultan. Chrome utilizează setările proxy ale sistemului în mod implicit.

• Pe Windows:

Navigați la Setări > Sistem > Proxy și dezactivați “Utilizați un server proxy” dacă este activat fără știrea dvs. Alternativ, rulați aceasta dintr-o Linie de comandă cu drepturi de administrator:

netsh winhttp reset proxy

• Pe macOS

Accesați Setări sistem > Rețea, selectați interfața dvs. activă, faceți clic pe Detalii, apoi pe fila Proxy-uri, și debifați toate protocoalele proxy active.

După dezactivarea proxy-ului, testați site-ul. Dacă se încarcă, configurația proxy-ului dvs. era cauza. Fie reconfigurați-o corect, fie eliminați-o complet.

Pasul 7: Schimbați Rezolverul DNS

Rezolverul DNS implicit al furnizorului dvs. de internet poate returna rezultate incorecte, poate experimenta o întrerupere sau poate bloca activ anumite domenii. Trecerea la un rezolver public elimină această variabilă.

Rezolvere DNS publice recomandate:

• Pe Windows (via PowerShell):

Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ServerAddresses ("1.1.1.1","1.0.0.1")

• Pe macOS:

Accesați Setări sistem > Rețea > [Interfața dvs.] > Detalii > DNS, eliminați intrările existente și adăugați 1.1.1.1 și 1.0.0.1.

• Pe Linux (systemd-resolved):

Editați /etc/systemd/resolved.conf:

[Resolve]
DNS=1.1.1.1 1.0.0.1
FallbackDNS=8.8.8.8 8.8.4.4

Apoi reporniți rezolverul:

sudo systemctl restart systemd-resolved

Pasul 8: Dezactivați Temporar Firewall-ul și Antivirus-ul

Unele produse antivirus și firewall-uri bazate pe gazdă interceptează traficul HTTPS printr-un proxy local și pot emite pachete RST atunci când motorul lor de inspecție eșuează sau când domeniul țintă se află pe o listă de blocare. Dezactivarea lor temporară (doar în scopuri de diagnostic) confirmă dacă sunt cauza.

Dacă dezactivarea software-ului de securitate rezolvă eroarea, adăugați o excepție specifică pentru domeniul țintă în loc să lăsați software-ul dezactivat. Reactivați-l imediat după testare.

Pasul 9: Testați cu un Browser și o Rețea Diferite

Testați URL-ul în Firefox, Edge sau Safari. Dacă se încarcă într-un alt browser, problema este specifică Chrome — probabil un profil corupt, o extensie care nu funcționează corect sau o setare proxy specifică Chrome. Încercați să creați un nou profil Chrome pentru a izola problema.

Dacă site-ul eșuează în toate browserele, treceți la un hotspot mobil. Dacă se încarcă pe date mobile, furnizorul dvs. de internet sau routerul dvs. de acasă este sursa problemei.

Pasul 10: Verificați Problemele de Configurare SSL/TLS (Administratorii de Server)

Un certificat SSL configurat incorect poate cauza serverului să se prăbușească sau să refuze conexiunile TLS, pe care Chrome le raportează ca ERR_CONNECTION_REFUSED în loc de o eroare de certificat în unele cazuri extreme. Utilizați următoarele pentru a testa din linia de comandă:

curl -vI https://yourdomain.com

Căutați etapa handshake-ului TLS în ieșirea detaliată. O eșec aici indică o problemă de certificat sau suite de cifruri. Puteți testa și cu:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

Dacă certificatul SSL dvs. a expirat sau este configurat incorect, reînnoirea sau înlocuirea acestuia rezolvă problema. Asigurați-vă că Certificatele SSL sunt valide, corect înlănțuite și instalate pe interfața serverului corect.

ERR_CONNECTION_REFUSED vs. Erori similare din browser

Înțelegerea modului în care această eroare diferă de erorile conexe previne diagnosticarea greșită:

Cazuri avansate și capcane

1) Conflicte de rezoluție IPv6 vs. IPv4:

Dacă un domeniu se rezolvă la o adresă IPv6 dar rețeaua dvs. nu suportă IPv6 corect, Chrome poate încerca o conexiune IPv6 care este refuzată, apoi nu reușește să revină la IPv4 rapid. Dezactivarea temporară a IPv6 pe adaptorul de rețea poate confirma acest lucru. Pe Linux, puteți forța IPv4 cu curl -4 https://example.com.

2) Cloudflare sau CDN cache cu erori de origine stale:

Dacă un site folosește Cloudflare și serverul de origine se oprește, Cloudflare poate servi o versiune cache pentru o vreme, apoi începe să returneze erori 521 (origin refused connection) sau 522, pe care Chrome le poate afișa ca ERR_CONNECTION_REFUSED în funcție de modul în care eroarea este proxied.

3) Medii de dezvoltare localhost:

Dezvoltatorii văd frecvent ERR_CONNECTION_REFUSED atunci când accesează localhost:3000 sau similar. Cauza este aproape întotdeauna că procesul serverului de dezvoltare nu rulează, s-a prăbușit sau este legat la 127.0.0.1 pe un port diferit decât cel așteptat. Rulați ss -tlnp | grep node (sau procesul relevant) pentru a confirma ce ascultă de fapt.

4) Conflicte de porturi ale serverului de e-mail:

Dacă rulați Email Hosting pe același server ca aplicația dvs. web, asigurați-vă că conflictele de porturi între SMTP (25, 587), IMAP (993) și HTTP/HTTPS (80, 443) nu determină serverul web să nu se lege.

5) Limitări ale găzduirii partajate:

În mediile de Shared Web Hosting, o refuzare de conexiune poate indica faptul că serverul furnizorului de găzduire este supraîncărcat, contul a fost suspendat sau DNS domeniului nu indică încă IP-ul partajat corect. Verificați panoul de control al găzduirii dvs. pentru starea contului și configurația DNS.

Matrice practică de decizie: Care remediere să se aplice mai întâi

Utilizați această listă de verificare pentru triaj eficient:

• Eroarea apare pe toate site-urile web simultan — Verificați mai întâi setările proxy și configurația VPN/firewall
• Eroarea apare doar pe un domeniu specific — Verificați dacă site-ul este inactiv la nivel global; apoi goliți cache-ul DNS
• Eroarea apare doar în Chrome, nu și în alte browsere — Ștergeți cache-ul Chrome, dezactivați extensiile sau creați un nou profil Chrome
• Eroarea apare doar pe rețeaua dvs., nu și pe datele mobile — Reporniți routerul; verificați DNS la nivel ISP sau firewall
• Eroarea apare după o schimbare de configurare a serverului — Verificați starea procesului serverului web, legările porturilor și regulile firewall pe server
• Eroarea apare intermitent sub sarcină — Investigați epuizarea resurselor (descriptori de fișiere, memorie, limite de conexiuni) pe server
• Eroarea apare doar pe HTTPS, nu și pe HTTP — Investigați validitatea certificatului SSL și configurația TLS
• Eroarea a apărut după schimbarea setărilor DNS — Anulați modificările DNS și goliți cache-ul; verificați dacă noul resolver este accesibil

Întrebări frecvente

1) Care este diferența dintre ERR_CONNECTION_REFUSED și ERR_CONNECTION_TIMED_OUT?

ERR_CONNECTION_REFUSED înseamnă că serverul (sau un firewall) a trimis activ un pachet TCP reset, respingând conexiunea imediat. ERR_CONNECTION_TIMED_OUT înseamnă că nu s-a primit niciun răspuns în perioada de timeout — pachetele au fost pur și simplu abandonate. O conexiune respinsă apare mai rapid și indică o respingere activă, în timp ce un timeout sugerează o regulă de DROP a rutării sau firewall-ului.

2) Poate ERR_CONNECTION_REFUSED să fie cauzat de un certificat SSL expirat?

Indirect, da. În unele configurații de server, un certificat SSL expirat sau incorect configurat determină procesul serverului web să eșueze la pornire sau să se prăbușească atunci când gestionează conexiuni TLS, rezultând în niciun listener pe portul 443. Chrome raportează apoi ERR_CONNECTION_REFUSED deoarece nimic nu ascultă, chiar dacă cauza de bază este o problemă de certificat.

3) De ce apare ERR_CONNECTION_REFUSED doar pe un anumit site web?

Dacă eroarea este izolată la un singur domeniu, cele mai probabile cauze sunt: serviciul web al serverului țintă s-a prăbușit, firewall-ul serverului vă blochează gama de IP-uri, înregistrările DNS ale domeniului indică o adresă IP veche unde nu rulează niciun serviciu, sau site-ul a fost închis. Utilizați curl -v https://thatdomain.com dintr-o rețea sau server diferit pentru a izola cauza.

4) Cum remediez ERR_CONNECTION_REFUSED pe localhost?

Serverul de aplicații nu rulează sau este legat la un port diferit de cel pe care îl solicitați. Confirmați ce ascultă cu ss -tlnp pe Linux/macOS sau netstat -ano | findstr :PORT pe Windows. Porniți procesul serverului de aplicații și asigurați-vă că este legat la 0.0.0.0 sau 127.0.0.1 pe portul așteptat.

5) Golirea DNS-ului remediază întotdeauna ERR_CONNECTION_REFUSED?

Doar atunci când cauza de bază este o intrare de cache DNS veche care indică o adresă IP unde serviciul nu mai rulează. Dacă serverul este inactiv, firewall-ul blochează conexiunea sau proxy-ul este incorect configurat, golirea DNS-ului nu va avea niciun efect. Utilizați dig sau nslookup pentru a verifica rezoluția DNS înainte și după golire pentru a confirma dacă DNS a fost de fapt problema.