15%

Economisește 15% la toate serviciile de găzduire

Testează-ți abilitățile și obține Reducere la orice plan de găzduire

Utilizați codul:

Skills
Începeți
09.10.2024

Cum să Remediați Eroarea ERR_CONNECTION_TIMED_OUT: Un Ghid Tehnic Complet

Eroarea ERR_CONNECTION_TIMED_OUT înseamnă că browserul tău a trimis o cerere de conexiune către un server la distanță, dar nu a primit niciun răspuns în intervalul de timp alocat — de obicei 30 de secunde în browserele bazate pe Chromium. Handshake-ul TCP nu se finalizează niciodată, astfel că browserul abandonează tentativa și afișează această eroare în loc de pagina încărcată.

Aceasta nu este o eroare cu o singură cauză. Poate proveni din partea clientului (mașina ta, rețeaua ta, browserul tău), din infrastructura intermediară (rezolvatori DNS, proxy-uri, firewall-uri) sau din partea serverului (origine supraîncărcată, server web configurat greșit, SSL expirat sau eroare de rutare upstream). Diagnosticarea corectă necesită parcurgerea sistematică a fiecărui nivel.

Ce Se Întâmplă de Fapt în Timpul unui Timeout de Conexiune

Când tastezi un URL și apeși Enter, browserul tău execută o secvență precisă: rezoluție DNS, conexiune TCP (SYN / SYN-ACK / ACK), handshake TLS opțional, apoi ciclul de cerere/răspuns HTTP. O eroare de timeout înseamnă că procesul s-a blocat undeva în acel lanț — cel mai frecvent la etapa de conexiune TCP, înainte ca orice date HTTP să fie schimbate.

Înțelegerea etapei care a eșuat îți spune unde să concentrezi remedierea. O eroare DNS produce un cod de eroare diferit (`ERR_NAME_NOT_RESOLVED`). O eroare TLS produce `ERR_SSL_PROTOCOL_ERROR`. Când vezi `ERR_CONNECTION_TIMED_OUT` în mod specific, căutarea DNS a reușit, dar socket-ul TCP nu a primit niciodată un SYN-ACK de la IP-ul țintă. Aceasta restrânge considerabil câmpul de investigație.

Cauze Principale: De Ce Apare Această Eroare

CategorieCauză SpecificăPartea Clientului sau Serverului
RețeaProblemă de rutare ISP, pierdere de pachete, legătură congestionatăClient
DNSCache expirat, rezolvator greșit, întârziere de propagareClient
Firewall / SecuritateWindows Firewall, antivirus, proxy corporativ care blochează portul 80/443Client
BrowserCache corupt, extensie defectă, configurare greșită a proxy-uluiClient
Stivă TCP/IPCatalog Winsock corupt, setări IP incorecteClient
Supraîncărcare ServerCPU/RAM ridicat, coadă de conexiuni epuizată, DDoSServer
Configurare Server Web`KeepAliveTimeout` prea mic, `MaxClients` depășit, virtual host configurat greșitServer
Infrastructură HostingCont suspendat, regulă de firewall pe VPS, IP server greșit după migrareServer
CDN / Reverse ProxyOriginea inaccesibilă din nodul edge CDNInfrastructură

Metoda 1: Verifică Conexiunea la Internet la Nivelul Rețelei

Nu te limita doar la a „verifica dacă internetul funcționează.” Rulează un test structurat:

  • Ping la gateway: Deschide Command Prompt și rulează `ping 192.168.1.1` (sau IP-ul routerului tău). Dacă aceasta eșuează, problema este între mașina ta și router.
  • Ping direct la un IP public: Rulează `ping 8.8.8.8`. Dacă aceasta reușește, dar site-urile web eșuează, problema este DNS, nu conectivitatea.
  • Rulează un traceroute: `tracert google.com` pe Windows sau `traceroute google.com` pe Linux/macOS. Caută unde se opresc răspunsurile hop-urilor — aceasta identifică segmentul de rețea defect.
  • Repornește routerul: Oprește-l timp de 30 de secunde. Aceasta forțează un nou lease DHCP și restabilește sesiunea PPPoE/PPPoA cu ISP-ul tău.
  • Testează pe un hotspot mobil: Dacă site-ul se încarcă prin LTE, dar nu prin broadband-ul de acasă, defecțiunea este upstream de routerul tău — probabil ISP-ul tău sau o cale de rutare specifică pe care o folosesc.

Metoda 2: Golește și Reconstruiește Cache-ul DNS

Un cache DNS otrăvit sau expirat poate stoca o adresă IP veche, inaccesibilă pentru un domeniu, determinând fiecare tentativă de conexiune să expire față de un server care nu mai există la acea adresă.

Pe Windows:

“`

ipconfig /flushdns

ipconfig /registerdns

“`

Pe macOS (Ventura / Sonoma):

“`

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

“`

Pe Linux (systemd-resolved):

“`

sudo systemd-resolve –flush-caches

“`

După golire, verifică dacă cache-ul este gol pe Windows cu `ipconfig /displaydns` — rezultatul ar trebui să fie minimal. Apoi încearcă din nou conexiunea înainte de a face alte modificări, astfel încât să poți izola dacă cache-ul DNS a fost singura cauză.

Metoda 3: Treci la un Rezolvator DNS Public Fiabil

Rezolvatorul DNS implicit al ISP-ului tău poate fi lent, nesigur sau supus filtrării geografice. Înlocuirea lui cu un rezolvator public rapid rezolvă adesea erorile de timeout cauzate de eșecuri ale căutărilor DNS care returnează în mod silențios înregistrări incorecte sau niciuna.

Pe Windows (IPv4):

  1. Deschide Control Panel > Network and Internet > Network and Sharing Center > Change adapter settings.
  2. Fă clic dreapta pe adaptorul activ și selectează Properties.
  3. Selectează Internet Protocol Version 4 (TCP/IPv4) și fă clic pe Properties.
  4. Selectează Use the following DNS server addresses și introdu rezolvatorul preferat.

Rezolvatori DNS publici recomandați:

FurnizorDNS PrimarDNS SecundarSuport Protocol
Google Public DNS8.8.8.88.8.4.4DNS-over-HTTPS, DNS-over-TLS
Cloudflare1.1.1.11.0.0.1DNS-over-HTTPS, DNS-over-TLS
OpenDNS208.67.222.222208.67.220.220DNSCrypt
Quad99.9.9.9149.112.112.112DNS-over-HTTPS, blocare malware

Caz limită critic: Dacă ai migrat recent site-ul web pe un server nou sau ai schimbat înregistrarea A, propagarea DNS poate dura până la 48 de ore. În această perioadă, unii utilizatori vor fi direcționați către IP-ul vechi. Rulând `nslookup yourdomain.com 8.8.8.8` față de `nslookup yourdomain.com 1.1.1.1` poți compara ce returnează diferiți rezolvatori — dacă IP-urile diferă, ești într-o fereastră de propagare, nu o eroare de timeout reală.

Chrome și alte browsere bazate pe Chromium stochează răspunsurile DNS independent de cache-ul DNS la nivel de sistem de operare. Acest cache DNS intern al browserului poate păstra înregistrări expirate chiar și după ce golești cache-ul sistemului.

Golește direct cache-ul DNS intern al Chrome:

  1. Navighează la `chrome://net-internals/#dns`
  2. Fă clic pe Clear host cache
  3. Navighează la `chrome://net-internals/#sockets`
  4. Fă clic pe Flush socket pools

Golește datele de navigare:

  1. Deschide Chrome și apasă `Ctrl + Shift + Delete`
  2. Setează intervalul de timp la All time
  3. Bifează Cookies and other site data și Cached images and files
  4. Fă clic pe Clear data

Testează mai întâi într-o fereastră Incognito. Dacă site-ul se încarcă în Incognito, dar nu într-o fereastră normală, o extensie de browser este vinovată. Dezactivează toate extensiile prin `chrome://extensions/` și reactivează-le una câte una pentru a identifica vinovatul. Blocantele de reclame, extensiile VPN și instrumentele de securitate sunt cele mai frecvente surse de interferență.

Metoda 5: Dezactivează Setările Proxy

O configurare proxy greșită sau expirată este una dintre cele mai frecvent trecute cu vederea cauze ale acestei erori, în special pe mașinile corporative sau după dezinstalarea unui software VPN care a lăsat setările proxy în urmă.

Prin Chrome:

  1. Mergi la Settings > System > Open your computer's proxy settings
  2. Sub Manual proxy setup, asigură-te că Use a proxy server este dezactivat
  3. Sub Automatic proxy setup, asigură-te că Use setup script este dezactivat, cu excepția cazului în care folosești intenționat un fișier PAC

Prin Windows Settings direct:

  1. Deschide Settings > Network & Internet > Proxy
  2. Dezactivează toate intrările proxy manuale
  3. Activează Automatically detect settings doar dacă rețeaua ta o necesită

Prin Command Prompt (metoda cea mai rapidă):

“`

netsh winhttp reset proxy

“`

Aceasta resetează setările proxy WinHTTP la conexiune directă, ocolind orice proxy la nivel de sistem care ar fi putut fi setat de software.

Metoda 6: Resetează Stiva TCP/IP și Catalogul Winsock

Coruperea catalogului Winsock — implementarea Windows a API-ului Berkeley sockets — poate cauza eșecuri de conexiune intermitente sau persistente care arată identic cu timeout-urile de pe partea serverului. Aceasta este deosebit de frecventă după eliminarea malware-ului, actualizări eșuate ale driverelor de rețea sau activitate agresivă a antivirusului.

Deschide Command Prompt ca Administrator și rulează aceste comenzi secvențial:

“`

netsh winsock reset

netsh int ip reset resetlog.txt

ipconfig /release

ipconfig /flushdns

ipconfig /renew

“`

Repornește mașina după rularea tuturor comenzilor. Fișierul `resetlog.txt` va fi creat în directorul tău de lucru și înregistrează fiecare cheie de registry care a fost resetată — util pentru auditarea a ceea ce a fost corupt.

Pe Linux, echivalentul pentru resetarea stării rețelei este:

“`

sudo systemctl restart NetworkManager

sudo ip route flush cache

“`

Metoda 7: Auditează Regulile Firewall și Antivirus

Windows Defender Firewall și suitele de securitate terțe pot bloca în mod silențios conexiunile outbound către porturi specifice, intervale IP sau domenii. Blocarea nu produce o eroare imediată de „conexiune refuzată” — în schimb, pachetele sunt abandonate, iar browserul așteaptă până când pragul de timeout este atins.

Test de diagnostic temporar:

  1. Mergi la Control Panel > System and Security > Windows Defender Firewall
  2. Fă clic pe Turn Windows Defender Firewall on or off
  3. Dezactivează-l temporar pentru rețelele private și publice
  4. Încearcă conexiunea

Dacă site-ul se încarcă cu firewall-ul dezactivat, reactivează-l imediat și apoi creează o regulă outbound specifică pentru a permite traficul către domeniul sau IP-ul afectat, în loc să lași firewall-ul dezactivat. Navighează la Advanced Settings > Outbound Rules > New Rule pentru a configura aceasta precis.

Pentru software-ul antivirus: Majoritatea suitelor moderne includ o funcție de inspecție HTTPS sau „web shield” care efectuează o interceptare man-in-the-middle a traficului TLS. Aceasta poate întrerupe conexiunile dacă certificatul root al antivirusului nu este de încredere pentru browser, sau dacă antivirusul marchează incorect serverul țintă. Dezactivarea temporară a componentei web shield (nu a întregului antivirus) este un test mai chirurgical decât dezactivarea întregii protecții.

Metoda 8: Resetează Flag-urile Chrome și Predictorul de Rețea

Flag-urile experimentale ale Chrome și funcțiile de predicție a rețelei pot cauza ocazional probleme de conexiune, în special după actualizările browserului care schimbă modul în care se comportă aceste funcții.

Dezactivează predicția rețelei:

  1. Mergi la Settings > Privacy and security > Cookies and other site data
  2. Derulează la Preload pages for faster browsing and searching și dezactivează-o

Resetează toate flag-urile Chrome la valorile implicite:

  1. Navighează la `chrome://flags`
  2. Fă clic pe Reset all în colțul din dreapta sus
  3. Relansează Chrome

Resetează toate setările stivei de rețea ale Chrome:

  1. Mergi la Settings > Advanced > Reset and clean up > Restore settings to their original defaults

Aceasta nu șterge marcajele sau parolele, dar resetează paginile de pornire, setările pentru filă nouă, filele fixate, setările de conținut, cookie-urile și extensiile — oferindu-ți efectiv o bază de configurare a rețelei curată.

Metoda 9: Mărește Timeout-ul Conexiunii TCP (Avansat)

În mod implicit, Windows așteaptă aproximativ 21 de secunde înainte de a declara eșuată o tentativă de conexiune TCP (bazat pe valoarea de registry `TcpMaxConnectRetransmissions`, care implicit este 2 retransmisii cu backoff exponențial). Pe rețele lente sau congestionare, aceasta poate fi prea scurtă.

Ajustează prin Registry Editor (Windows):

  1. Deschide `regedit`
  2. Navighează la `HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters`
  3. Găsește sau creează o valoare DWORD numită `TcpMaxConnectRetransmissions`
  4. Setează-o la `3` sau `4` (hexazecimal) pentru a permite mai multe tentative de retransmisie

Important: Aceasta mărește timpul pe care Windows îl va aștepta înainte de a renunța la o conexiune TCP. Nu remediază cauza de bază — pur și simplu oferă mai mult timp serverelor lente sau rutelor congestionare să răspundă. Folosește aceasta doar ca instrument de diagnostic sau pentru cazuri de utilizare specifice, cum ar fi conectarea la servere geografic îndepărtate.

Metoda 10: Verifică Dacă Serverul Este Accesibil

Înainte de a petrece mai mult timp pe remedieri de pe partea clientului, confirmă dacă problema este pe partea serverului. Un site web poate fi complet inaccesibil din cauza unui cont de hosting suspendat, a unei reguli de firewall pe server sau a unui server web configurat greșit — niciunul dintre acestea nu poate fi remediat din browser.

Instrumente pentru verificarea accesibilității serverului din puncte externe:

  • downforeveryoneorjustme.com — Verificare simplă sus/jos dintr-o singură locație
  • downdetector.com — Agregează rapoartele utilizatorilor pentru serviciile majore
  • tools.pingdom.com — Testează timpul de răspuns din mai multe locații globale
  • mxtoolbox.com/SuperTool — Testează DNS, anteturi HTTP și conectivitate
  • check-host.net — Ping-uri și verificări HTTP din zeci de noduri geografice simultan

Rulează `curl -v https://yourdomain.com` dintr-un terminal pentru a vedea punctul exact al eșecului — dacă conexiunea TCP este refuzată, expiră sau reușește, dar returnează un cod de eroare HTTP. Această singură comandă îți spune mai mult decât orice instrument GUI.

Cauze de pe Partea Serverului: Ce să Verifici Dacă Deții Site-ul

Dacă ești proprietarul site-ului web și vizitatorii tăi raportează `ERR_CONNECTION_TIMED_OUT`, problema este aproape sigur în infrastructura ta. Cele mai frecvente cauze de pe partea serverului sunt:

Epuizarea cozii de conexiuni a serverului web:

În Apache, directiva `MaxClients` (sau `MaxRequestWorkers` în Apache 2.4+) limitează conexiunile simultane. Când această limită este atinsă, noile conexiuni se pun în coadă și în cele din urmă expiră. Verifică configurația curentă:

“`

apache2ctl -V | grep -i mpm

grep -i maxrequestworkers /etc/apache2/apache2.conf

“`

În Nginx, echivalentul este `worker_connections` în blocul `events` și `worker_processes`. O configurare greșită frecventă este setarea `worker_processes` la `1` pe un server multi-core, creând un bottleneck.

Firewall care blochează traficul incoming pe portul 80/443:

Dacă gestionezi un mediu VPS Hosting, verifică regulile tale iptables sau nftables:

“`

iptables -L INPUT -n -v | grep -E "80|443"

“`

O regulă ACCEPT lipsă pentru porturile 80 și 443 va face ca toate conexiunile browserului să expire în mod silențios. Verifică de asemenea că firewall-ul panoului de control al hosting-ului tău (CSF, UFW sau Firewalld) nu a blocat din greșeală aceste porturi după o actualizare de securitate.

Probleme cu certificatul SSL care cauzează timeout-uri la handshake-ul TLS:

Un certificat SSL expirat sau configurat greșit poate face ca handshake-ul TLS să se blocheze, ceea ce se manifestă ca un timeout de conexiune mai degrabă decât o eroare de certificat în unele cazuri limită — în special când se folosesc versiuni TLS mai vechi sau suite de cifrare configurate greșit. Verifică certificatul cu:

“`

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

“`

Epuizarea resurselor pe server:

Utilizarea ridicată a CPU sau RAM poate face procesul serverului web să devină neresponsiv. Pe un server Linux, verifică:

“`

top -b -n 1 | head -20

free -h

ss -s

“`

Comanda `ss -s` arată rezumatul stărilor socket-urilor — un număr mare de conexiuni în starea `TIME-WAIT` sau `CLOSE-WAIT` indică probleme de gestionare a conexiunilor care vor face ca noile conexiuni să expire.

Configurare DNS greșită după migrarea serverului:

Dacă ai mutat recent site-ul pe un Server Dedicat sau ai schimbat furnizorul de hosting, verifică că înregistrarea A a domeniului tău indică adresa IP corectă și că TTL-ul a expirat pe înregistrările vechi. Folosește `dig yourdomain.com +trace` pentru a urmări lanțul complet de rezoluție DNS de la serverele root în jos.

Compararea ERR_CONNECTION_TIMED_OUT cu Erori Similare de Browser

Cod EroareCe ÎnseamnăCauza Cea Mai Probabilă
ERR_CONNECTION_TIMED_OUTSYN TCP trimis, niciun SYN-ACK primit în intervalul de timeoutFirewall care abandonează pachete, supraîncărcare server, eroare de rutare
ERR_CONNECTION_REFUSEDSYN TCP a primit RST ca răspunsNiciun serviciu care ascultă pe acel port, firewall care trimite RST
ERR_NAME_NOT_RESOLVEDCăutarea DNS nu a returnat niciun rezultatConfigurare DNS greșită, domeniu neînregistrat, NXDOMAIN
ERR_SSL_PROTOCOL_ERRORHandshake TLS eșuatCertificat expirat, nepotrivire de protocol, incompatibilitate suite de cifrare
ERR_EMPTY_RESPONSETCP conectat, dar serverul nu a trimis dateCrash server web, răspuns gol din aplicație
ERR_CONNECTION_RESETConexiunea a fost resetată în mijlocul sesiuniiÎntrerupere de rețea, limită de conexiuni pe server, resetare proxy
504 Gateway TimeoutReverse proxy a expirat așteptând origineaServer de origine prea lent, eroare de conexiune upstream

Înțelegerea acestui tabel este importantă din punct de vedere operațional: dacă depanezi propriul server, eroarea specifică pe care o văd utilizatorii tăi îți spune exact ce nivel al stivei să investighezi mai întâi.

Matrice de Decizie Practică: Ce Remediere să Aplici Mai Întâi

Folosește această secvență pentru a minimiza timpul de diagnostic:

  1. Poți accesa alte site-uri web? Nu — remediază mai întâi rețeaua locală sau conexiunea ISP (Metodele 1, 6). Da — treci la pasul 2.
  2. Se încarcă site-ul pe un alt dispozitiv sau rețea? Da — problema este pe partea clientului (Metodele 2, 3, 4, 5, 7). Nu — problema este probabil pe partea serverului sau propagarea DNS.
  3. Un verificator extern (check-host.net) arată site-ul ca inaccesibil din mai multe locații? Da — contactează administratorul serverului sau furnizorul de hosting. Nu — problema este rutarea regională sau ISP-ul tău specific.
  4. Se încarcă site-ul în modul Incognito? Da — o extensie de browser sau date din cache este cauza (Metoda 4). Nu — treci la remedieri la nivel DNS și de rețea.
  5. Ai schimbat recent înregistrările DNS sau ai migrat servere? Da — așteaptă propagarea DNS și verifică înregistrările cu `dig` sau `nslookup`. Nu — verifică firewall-ul de pe server și configurarea serverului web.

Dacă rulezi propria infrastructură de server — fie pe un VPS cu cPanel sau un mediu bare-metal — verifică întotdeauna jurnalele serverului înainte de a petrece timp pe remedieri de pe partea clientului. Jurnalul de erori Apache (`/var/log/apache2/error.log`) și jurnalul de erori Nginx (`/var/log/nginx/error.log`) vor conține înregistrări explicite ale eșecurilor de conexiune, evenimentelor de epuizare a resurselor și erorilor de configurare.

Pentru echipele care gestionează mai multe domenii, menținerea Înregistrării Domeniilor și a gestionării DNS centralizate sub un singur furnizor reduce semnificativ riscul erorilor de timeout legate de propagare cauzate de configurații DNS divizate sau înregistrări de domeniu expirate.

Concluzii Tehnice Cheie

  • `ERR_CONNECTION_TIMED_OUT` indică în mod specific un eșec la nivel TCP — pachetul SYN a fost trimis, dar niciun SYN-ACK nu a fost primit. Aceasta îl distinge de erorile DNS, erorile TLS și erorile la nivel HTTP.
  • Testează întotdeauna dintr-un punct extern (check-host.net, curl de pe un server la distanță) înainte de a presupune că problema este pe mașina ta locală.
  • Chrome menține propriul cache DNS intern separat de cel al sistemului de operare. Golirea doar a cache-ului sistemului de operare prin `ipconfig /flushdns` este insuficientă — trebuie să golești și `chrome://net-internals/#dns`.
  • Pe partea serverului, abandonarea silențioasă a pachetelor din regulile de firewall este cea mai frecventă cauză a acestei erori specifice. O conexiune refuzată (`RST`) ar produce un cod de eroare diferit.
  • Întârzierile de propagare DNS după migrările serverelor sunt frecvent diagnosticate greșit ca erori de timeout. Verifică întotdeauna cu `nslookup` față de mai mulți rezolvatori înainte de a investiga mai departe.
  • Pentru serverele web de producție, monitorizează regulat rezultatul `ss -s`. Un număr în creștere de `CLOSE-WAIT` indică bug-uri de gestionare a socket-urilor la nivel de aplicație care vor cauza în cele din urmă timeout-uri de conexiune sub sarcină.

Întrebări Frecvente

De ce apare ERR_CONNECTION_TIMED_OUT doar pe un anumit site web, dar nu pe altele?

Aceasta înseamnă aproape întotdeauna că serverul țintă este inaccesibil din rețeaua ta în mod specific — fie serverul este oprit, IP-ul său s-a schimbat din cauza propagării DNS, fie o regulă de firewall pe server blochează intervalul tău de IP. Folosește un verificator extern precum check-host.net pentru a confirma dacă site-ul este inaccesibil la nivel global sau doar din locația ta.

Golirea cache-ului DNS remediază ERR_CONNECTION_TIMED_OUT?

Poate, dar numai dacă cauza este o înregistrare DNS expirată care indică un IP vechi al serverului. Dacă înregistrarea DNS este corectă și serverul este cu adevărat inaccesibil, golirea cache-ului nu va ajuta. Verifică întotdeauna la ce adresă IP se rezolvă domeniul folosind `nslookup` înainte și după golire.

Poate un VPN cauza ERR_CONNECTION_TIMED_OUT?

Da. Un VPN rutează traficul tău prin propriile servere și rezolvatori DNS. Dacă serverul VPN este supraîncărcat, geografic îndepărtat sau are o problemă de rutare către site-ul țintă, vei vedea erori de timeout. Deconectează VPN-ul și testează direct. În mod alternativ, unele site-uri blochează intervalele de IP ale nodurilor de ieșire VPN la nivel de firewall, ceea ce va produce de asemenea această eroare.

Cum remediez ERR_CONNECTION_TIMED_OUT pe un server pe care îl gestionez?

Verifică în această ordine: (1) confirmă că procesul serverului web rulează (`systemctl status nginx` sau `apache2`), (2) verifică că porturile 80 și 443 sunt deschise în firewall-ul tău (`iptables -L` sau `ufw status`), (3) verifică utilizarea resurselor serverului cu `top` și `free -h`, (4) revizuiește jurnalul de erori al serverului web pentru refuzuri de conexiune sau mesaje de epuizare a worker-ilor, (5) confirmă că certificatul SSL este valid și nu a expirat.

ERR_CONNECTION_TIMED_OUT este același lucru cu un 504 Gateway Timeout?

Nu. Un 504 Gateway Timeout este o eroare la nivel HTTP returnată de un reverse proxy (cum ar fi Nginx sau un CDN) când nu poate obține un răspuns de la serverul de origine upstream în intervalul de timeout configurat. `ERR_CONNECTION_TIMED_OUT` este o eroare la nivel de browser care apare înainte ca orice răspuns HTTP să fie primit — conexiunea TCP în sine nu se finalizează niciodată. Ambele indică un timeout, dar la niveluri diferite ale stivei de rețea.

15%

Economisește 15% la toate serviciile de găzduire

Testează-ți abilitățile și obține Reducere la orice plan de găzduire

Utilizați codul:

Skills
Începeți