ERR_CONNECTION_REFUSED: Ce Înseamnă și Cum să-l Remediați Complet

Eroarea ERR_CONNECTION_REFUSED înseamnă că browserul dvs. a trimis o cerere de conexiune către un server web, iar acel server a respins-o activ — nu a ignorat-o, ci a refuzat explicit handshake-ul TCP. Acesta este un mod de eșec fundamental diferit față de un timeout (ERR_CONNECTION_TIMED_OUT) sau o eroare DNS (ERR_NAME_NOT_RESOLVED), iar această distincție contează enorm atunci când se diagnostichează cauza principală.

În termeni practici, când Chrome afișează "This site can't be reached. 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 către clientul dvs., sau stiva de rețea locală este configurată greșit și rutează cererea incorect înainte ca aceasta să ajungă vreodată la server. Identificarea care dintre aceste trei categorii se aplică situației dvs. este calea cea mai rapidă spre o soluție.

Înțelegerea mecanicii la nivel TCP

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

Această distincție are o implicație practică de diagnosticare: dacă conexiunea ar fi eliminată silențios de un firewall, ați vedea ERR_CONNECTION_TIMED_OUT. O conexiune refuzată înseamnă că ceva răspunde activ — ceea ce înseamnă că gazda este accesibilă la nivel de rețea, dar serviciul de pe portul țintă este indisponibil sau blocat.

Cauzele comune la nivel de port includ:

• Procesul serverului web (Apache, Nginx, Node.js) s-a blocat sau s-a oprit
• Serverul ascultă pe un port non-standard, iar 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 upstream
• Aplicația din spatele proxy-ului s-a blocat, lăsând proxy-ul fără un backend către care să redirecționeze

Cauze principale: O analiză structurată

Cauze de pe partea clientului

Cauze de pe partea serverului

Ghid pas cu pas de diagnosticare și remediere

Pasul 1: Determinați dacă problema este globală sau locală

Înainte de a modifica orice setări locale, stabiliți dacă site-ul este inaccesibil 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 — pingează ținta 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 partea serverului și în afara controlului 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, a regulilor firewall și a rețelei upstream. Dacă rulați un mediu de VPS Hosting, verificați mai întâi lista de procese a serverului dvs. și configurația firewall.

Pasul 2: Verificați dacă 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 ce porturi:

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

Dacă rezultatul este gol 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

Verificați, de asemenea, 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ă Servere Dedicate, verificați, de asemenea, dacă regulile firewall upstream sau regulile grupului de securitate ale furnizorului dvs. de hosting blochează portul la perimetrul rețelei — acesta este separat de firewall-ul la nivel de sistem de operare.

Pasul 3: Reporniți routerul și goliți starea rețelei locale

Pentru problemele de pe partea clientului, o repornire a routerului șterge tabelele NAT, contractele DHCP și orice eșecuri de rutare tranzitorii. Deconectați routerul timp de 30 de secunde, apoi reconectați-l. Aceasta este deosebit de eficientă când eroarea a apărut brusc fără nicio modificare de configurare.

Pasul 4: Goliți cache-ul DNS

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

Pe Windows:

ipconfig /flushdns

Pe macOS (Ventura, Sonoma și cele mai moderne versiuni):

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Pe Linux (systemd-resolved):

sudo systemd-resolve --flush-caches

După golire, 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: Ștergeți cache-ul browserului și cookie-urile

În Google Chrome, navigați la chrome://settings/clearBrowserData sau utilizați comanda rapidă de la tastatură:

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

Setați intervalul de timp la Tot timpul, bifați Imagini și fișiere cached și Cookie-uri și alte date ale site-ului, apoi faceți clic pe Ștergeți datele. Reporniți Chrome complet (nu doar tab-ul) înainte de a testa din nou.

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ă cached sau o extensie de browser este vinovată.

Pasul 6: Auditați și dezactivați setările proxy

Un server proxy configurat greșit sau inactiv 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-un Command Prompt cu drepturi ridicate:

netsh winhttp reset proxy

Pe macOS:

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

După dezactivarea proxy-ului, testați site-ul. Dacă se încarcă, configurarea proxy-ului a fost cauza. Fie reconfigurați-l corect, fie eliminați-l complet.

Pasul 7: Schimbați rezolvatorul DNS

Rezolvatorul DNS implicit al ISP-ului dvs. poate returna rezultate incorecte, poate experimenta o întrerupere sau poate bloca activ anumite domenii. Trecerea la un rezolvator public elimină această variabilă.

Rezolvatoare DNS publice recomandate:

Pe Windows (prin PowerShell):

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

Pe macOS:

Mergeți la 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 rezolvatorul:

sudo systemctl restart systemd-resolved

Pasul 8: Dezactivați temporar firewall-ul și antivirusul

Unele produse antivirus și firewall-uri bazate pe gazdă interceptează traficul HTTPS printr-un proxy local și pot emite pachete RST 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 diagnosticare) confirmă dacă ele 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 diferit și o rețea diferită

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

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

Pasul 10: Verificați problemele de configurare SSL/TLS (Administratori de server)

Un certificat SSL configurat greșit poate determina serverul să se blocheze sau să refuze conexiunile TLS, pe care Chrome le raportează ca ERR_CONNECTION_REFUSED în loc de o eroare de certificat în unele cazuri limită. Utilizați următoarele pentru a testa din linia de comandă:

curl -vI https://yourdomain.com

Căutați etapa de handshake TLS în rezultatul verbose. Un eșec aici indică o problemă cu certificatul sau suita de cifrare. Puteți testa, de asemenea, cu:

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

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

ERR_CONNECTION_REFUSED vs. erori similare de browser

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

Cazuri limită avansate și capcane

Conflicte de rezoluție IPv6 vs. IPv4: Dacă un domeniu se rezolvă la o adresă IPv6, dar rețeaua dvs. nu suportă corect IPv6, Chrome poate încerca o conexiune IPv6 care este refuzată, apoi nu reușește să treacă rapid la IPv4. 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.

Cloudflare sau CDN care cachează erori de origine învechite: Dacă un site utilizează Cloudflare și serverul de origine cade, Cloudflare poate servi o versiune cached pentru o perioadă, apoi poate începe să returneze erori 521 (conexiune refuzată de origine) sau 522, pe care Chrome le poate afișa ca ERR_CONNECTION_REFUSED în funcție de modul în care eroarea este proxiată.

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

Conflicte de porturi ale serverului de email: 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 poată lega.

Limitări ale găzduirii partajate: În mediile de Web Hosting Partajat, un refuz de conexiune poate indica că serverul furnizorului de hosting este supraîncărcat, contul a fost suspendat sau înregistrările DNS ale domeniului nu indică încă IP-ul partajat corect. Verificați panoul de control al găzduirii pentru starea contului și configurarea DNS.

Matrice de decizie practică: Ce remediere să aplicați mai întâi

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

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

Întrebări frecvente

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 de resetare TCP, respingând conexiunea imediat. ERR_CONNECTION_TIMED_OUT înseamnă că nu s-a primit niciun răspuns în perioada de timeout — pachetele au fost eliminate silențios. O conexiune refuzată apare mai rapid și indică o respingere activă, în timp ce un timeout sugerează o regulă de rutare sau firewall DROP.

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 configurat greșit determină procesul serverului web să eșueze la pornire sau să se blocheze la gestionarea conexiunilor 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.

De ce apare ERR_CONNECTION_REFUSED doar pe un singur site specific?

Dacă eroarea este izolată la un singur domeniu, cele mai probabile cauze sunt: serviciul web al serverului țintă s-a blocat, firewall-ul serverului blochează intervalul dvs. de IP, î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.

Cum remediez ERR_CONNECTION_REFUSED pe localhost?

Serverul de aplicații nu rulează sau este legat la un port diferit față 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.

Golirea DNS rezolvă întotdeauna ERR_CONNECTION_REFUSED?

Doar când cauza principală este o intrare DNS cached învechită care indică o adresă IP unde serviciul nu mai rulează. Dacă serverul este inaccesibil, firewall-ul blochează conexiunea sau proxy-ul este configurat greșit, golirea DNS 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.