Jak naprawić błąd ERR_CONNECTION_TIMED_OUT: Kompletny przewodnik techniczny
Błąd ERR_CONNECTION_TIMED_OUT oznacza, że przeglądarka wysłała żądanie połączenia do zdalnego serwera, ale nie otrzymała odpowiedzi w wyznaczonym czasie — zazwyczaj 30 sekund w przeglądarkach opartych na Chromium. Uzgadnianie TCP nigdy nie zostaje zakończone, więc przeglądarka porzuca próbę i wyświetla ten błąd zamiast załadowanej strony.
Nie jest to błąd o jednej przyczynie. Może pochodzić po stronie klienta (Twój komputer, sieć, przeglądarka), z infrastruktury pośredniej (resolwery DNS, proxy, zapory sieciowe) lub po stronie serwera (przeciążone źródło, błędnie skonfigurowany serwer WWW, wygasły SSL lub awaria routingu upstream). Prawidłowe zdiagnozowanie wymaga systematycznego przejścia przez każdą warstwę.
Co tak naprawdę dzieje się podczas przekroczenia limitu czasu połączenia
Gdy wpisujesz URL i naciskasz Enter, przeglądarka wykonuje precyzyjną sekwencję: rozwiązanie DNS, połączenie TCP (SYN / SYN-ACK / ACK), opcjonalne uzgadnianie TLS, a następnie cykl żądanie/odpowiedź HTTP. Błąd przekroczenia limitu czasu oznacza, że proces zatrzymał się gdzieś w tym łańcuchu — najczęściej na etapie połączenia TCP, zanim zostaną wymienione jakiekolwiek dane HTTP.
Zrozumienie, który etap zawiódł, wskazuje, gdzie skupić naprawę. Błąd DNS generuje inny kod błędu (`ERR_NAME_NOT_RESOLVED`). Błąd TLS generuje `ERR_SSL_PROTOCOL_ERROR`. Gdy widzisz konkretnie `ERR_CONNECTION_TIMED_OUT`, wyszukiwanie DNS zakończyło się sukcesem, ale gniazdo TCP nigdy nie otrzymało SYN-ACK od docelowego IP. To znacznie zawęża pole poszukiwań.
Przyczyny główne: dlaczego ten błąd występuje
| Kategoria | Konkretna przyczyna | Strona klienta lub serwera |
|---|
| — | — | — |
|---|
| Sieć | Problem z routingiem ISP, utrata pakietów, przeciążone łącze | Klient |
|---|
| DNS | Nieaktualna pamięć podręczna, nieprawidłowy resolwer, opóźnienie propagacji | Klient |
|---|
| Zapora sieciowa / Bezpieczeństwo | Zapora Windows, oprogramowanie antywirusowe, firmowe proxy blokujące port 80/443 | Klient |
|---|
| Przeglądarka | Uszkodzona pamięć podręczna, wadliwe rozszerzenie, błędna konfiguracja proxy | Klient |
|---|
| Stos TCP/IP | Uszkodzony katalog Winsock, nieprawidłowe ustawienia IP | Klient |
|---|
| Przeciążenie serwera | Wysokie użycie CPU/RAM, wyczerpana kolejka połączeń, DDoS | Serwer |
|---|
| Konfiguracja serwera WWW | `KeepAliveTimeout` zbyt niskie, `MaxClients` przekroczone, błędnie skonfigurowany wirtualny host | Serwer |
|---|
| Infrastruktura hostingowa | Zawieszone konto, reguła zapory sieciowej na VPS, nieprawidłowy IP serwera po migracji | Serwer |
|---|
| CDN / Odwrotne proxy | Źródło nieosiągalne z węzła brzegowego CDN | Infrastruktura |
|---|
Metoda 1: Weryfikacja połączenia internetowego na poziomie sieci
Nie wystarczy „sprawdzić, czy internet działa”. Przeprowadź ustrukturyzowany test:
- Pinguj bramę: Otwórz Wiersz poleceń i uruchom `ping 192.168.1.1` (lub IP swojego routera). Jeśli to nie powiedzie się, problem leży między Twoim komputerem a routerem.
- Pinguj publiczny IP bezpośrednio: Uruchom `ping 8.8.8.8`. Jeśli to się powiedzie, ale strony internetowe nie działają, problem dotyczy DNS, a nie łączności.
- Uruchom traceroute: `tracert google.com` w Windows lub `traceroute google.com` w Linux/macOS. Sprawdź, gdzie przeskoki przestają odpowiadać — to identyfikuje wadliwy segment sieci.
- Uruchom ponownie router: Odłącz go od zasilania na 30 sekund. Wymusza to nową dzierżawę DHCP i ponowne nawiązanie sesji PPPoE/PPPoA z ISP.
- Przetestuj na mobilnym punkcie dostępu: Jeśli strona ładuje się przez LTE, ale nie przez domowe łącze szerokopasmowe, usterka leży po stronie routera — prawdopodobnie u Twojego ISP lub na konkretnej trasie routingu, której używa.
Metoda 2: Opróżnienie i odbudowanie pamięci podręcznej DNS
Zatruta lub nieaktualna pamięć podręczna DNS może przechowywać stary, nieosiągalny adres IP domeny, powodując przekroczenie limitu czasu każdej próby połączenia z serwerem, który nie istnieje już pod tym adresem.
W Windows:
“`
ipconfig /flushdns
ipconfig /registerdns
“`
W macOS (Ventura / Sonoma):
“`
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
“`
W Linux (systemd-resolved):
“`
sudo systemd-resolve –flush-caches
“`
Po opróżnieniu sprawdź, czy pamięć podręczna jest wyczyszczona w Windows za pomocą `ipconfig /displaydns` — wynik powinien być minimalny. Następnie spróbuj ponownie nawiązać połączenie przed wprowadzeniem jakichkolwiek innych zmian, aby ustalić, czy pamięć podręczna DNS była jedyną przyczyną.
Metoda 3: Przełączenie na niezawodny publiczny resolwer DNS
Domyślny resolwer DNS Twojego ISP może być wolny, zawodny lub podlegać filtrowaniu geograficznemu. Zastąpienie go szybkim, publicznym resolwerem często rozwiązuje błędy przekroczenia limitu czasu spowodowane błędami wyszukiwania DNS, które po cichu zwracają nieprawidłowe lub żadne rekordy.
W Windows (IPv4):
- Otwórz Panel sterowania > Sieć i Internet > Centrum sieci i udostępniania > Zmień ustawienia karty sieciowej.
- Kliknij prawym przyciskiem myszy aktywną kartę sieciową i wybierz Właściwości.
- Wybierz Protokół internetowy w wersji 4 (TCP/IPv4) i kliknij Właściwości.
- Wybierz Użyj następujących adresów serwerów DNS i wprowadź preferowany resolwer.
Zalecane publiczne resolwery DNS:
| Dostawca | Podstawowy DNS | Pomocniczy DNS | Obsługiwane protokoły |
|---|
| — | — | — | — |
|---|
| Google Public DNS | 8.8.8.8 | 8.8.4.4 | DNS-over-HTTPS, DNS-over-TLS |
|---|
| Cloudflare | 1.1.1.1 | 1.0.0.1 | DNS-over-HTTPS, DNS-over-TLS |
|---|
| OpenDNS | 208.67.222.222 | 208.67.220.220 | DNSCrypt |
|---|
| Quad9 | 9.9.9.9 | 149.112.112.112 | DNS-over-HTTPS, blokowanie złośliwego oprogramowania |
|---|
Krytyczny przypadek brzegowy: Jeśli niedawno przeniosłeś swoją witrynę na nowy serwer lub zmieniłeś jej rekord A, propagacja DNS może potrwać do 48 godzin. W tym czasie niektórzy użytkownicy będą kierowani na stary IP. Uruchomienie `nslookup yourdomain.com 8.8.8.8` w porównaniu z `nslookup yourdomain.com 1.1.1.1` pozwala porównać, co zwracają różne resolwery — jeśli adresy IP różnią się, jesteś w oknie propagacji, a nie w przypadku prawdziwego błędu przekroczenia limitu czasu.
Metoda 4: Wyczyszczenie pamięci podręcznej przeglądarki, plików cookie i rozszerzeń
Chrome i inne przeglądarki oparte na Chromium przechowują odpowiedzi DNS niezależnie od pamięci podręcznej DNS na poziomie systemu operacyjnego. Ta wewnętrzna pamięć podręczna DNS przeglądarki może przechowywać nieaktualne rekordy nawet po opróżnieniu pamięci podręcznej systemu.
Bezpośrednie wyczyszczenie wewnętrznej pamięci podręcznej DNS Chrome:
- Przejdź do `chrome://net-internals/#dns`
- Kliknij Clear host cache
- Przejdź do `chrome://net-internals/#sockets`
- Kliknij Flush socket pools
Wyczyszczenie danych przeglądania:
- Otwórz Chrome i naciśnij `Ctrl + Shift + Delete`
- Ustaw zakres czasu na Cały czas
- Zaznacz Pliki cookie i inne dane witryn oraz Obrazy i pliki w pamięci podręcznej
- Kliknij Wyczyść dane
Najpierw przetestuj w oknie incognito. Jeśli strona ładuje się w trybie incognito, ale nie w normalnym oknie, winowajcą jest rozszerzenie przeglądarki. Wyłącz wszystkie rozszerzenia przez `chrome://extensions/` i włączaj je ponownie jedno po drugim, aby zidentyfikować sprawcę. Blokery reklam, rozszerzenia VPN i narzędzia bezpieczeństwa są najczęstszymi źródłami zakłóceń.
Metoda 5: Wyłączenie ustawień proxy
Błędnie skonfigurowane lub nieaktualne ustawienia proxy są jedną z najczęściej pomijanych przyczyn tego błędu, szczególnie na komputerach firmowych lub po odinstalowaniu oprogramowania VPN, które pozostawiło ustawienia proxy.
Przez Chrome:
- Przejdź do Ustawienia > System > Otwórz ustawienia proxy komputera
- W sekcji Ręczna konfiguracja proxy upewnij się, że opcja Użyj serwera proxy jest wyłączona
- W sekcji Automatyczna konfiguracja proxy upewnij się, że opcja Użyj skryptu konfiguracji jest wyłączona, chyba że celowo używasz pliku PAC
Przez Ustawienia Windows bezpośrednio:
- Otwórz Ustawienia > Sieć i Internet > Serwer proxy
- Wyłącz wszystkie ręczne wpisy proxy
- Włącz Automatycznie wykryj ustawienia tylko jeśli Twoja sieć tego wymaga
Przez Wiersz poleceń (najszybsza metoda):
“`
netsh winhttp reset proxy
“`
Resetuje to ustawienia proxy WinHTTP do bezpośredniego połączenia, omijając wszelkie systemowe proxy, które mogło zostać ustawione przez oprogramowanie.
Metoda 6: Resetowanie stosu TCP/IP i katalogu Winsock
Uszkodzenie katalogu Winsock — implementacji API gniazd Berkeley w Windows — może powodować sporadyczne lub trwałe błędy połączeń, które wyglądają identycznie jak przekroczenia limitu czasu po stronie serwera. Jest to szczególnie powszechne po usunięciu złośliwego oprogramowania, nieudanych aktualizacjach sterowników sieciowych lub agresywnej aktywności oprogramowania antywirusowego.
Otwórz Wiersz poleceń jako Administrator i uruchom te polecenia kolejno:
“`
netsh winsock reset
netsh int ip reset resetlog.txt
ipconfig /release
ipconfig /flushdns
ipconfig /renew
“`
Uruchom ponownie komputer po wykonaniu wszystkich poleceń. Plik `resetlog.txt` zostanie utworzony w bieżącym katalogu roboczym i rejestruje każdy klucz rejestru, który został zresetowany — przydatne do audytu tego, co było uszkodzone.
W Linux odpowiednikiem resetowania stanu sieci jest:
“`
sudo systemctl restart NetworkManager
sudo ip route flush cache
“`
Metoda 7: Audyt reguł zapory sieciowej i oprogramowania antywirusowego
Zapora Windows Defender i zewnętrzne pakiety zabezpieczeń mogą po cichu blokować połączenia wychodzące do określonych portów, zakresów IP lub domen. Blokada nie powoduje natychmiastowego błędu „odmowa połączenia” — zamiast tego pakiety są odrzucane, a przeglądarka czeka, aż zostanie osiągnięty próg limitu czasu.
Tymczasowy test diagnostyczny:
- Przejdź do Panel sterowania > System i zabezpieczenia > Zapora Windows Defender
- Kliknij Włącz lub wyłącz Zaporę Windows Defender
- Tymczasowo wyłącz ją dla sieci prywatnych i publicznych
- Spróbuj nawiązać połączenie
Jeśli strona ładuje się przy wyłączonej zaporze, natychmiast ją włącz ponownie, a następnie utwórz konkretną regułę wychodzącą zezwalającą na ruch do dotkniętej domeny lub IP, zamiast pozostawiać zaporę wyłączoną. Przejdź do Ustawienia zaawansowane > Reguły wychodzące > Nowa reguła, aby skonfigurować to precyzyjnie.
W przypadku oprogramowania antywirusowego: Większość nowoczesnych pakietów zawiera funkcję inspekcji HTTPS lub „tarczy internetowej”, która wykonuje przechwycenie man-in-the-middle ruchu TLS. Może to przerywać połączenia, jeśli certyfikat główny oprogramowania antywirusowego nie jest zaufany przez przeglądarkę lub jeśli oprogramowanie antywirusowe nieprawidłowo oznacza docelowy serwer. Tymczasowe wyłączenie komponentu tarczy internetowej (nie całego oprogramowania antywirusowego) jest bardziej precyzyjnym testem niż wyłączenie całej ochrony.
Metoda 8: Resetowanie flag Chrome i predyktora sieci
Eksperymentalne flagi Chrome i funkcje przewidywania sieci mogą czasami powodować problemy z połączeniem, szczególnie po aktualizacjach przeglądarki, które zmieniają sposób działania tych funkcji.
Wyłączenie przewidywania sieci:
- Przejdź do Ustawienia > Prywatność i bezpieczeństwo > Pliki cookie i inne dane witryn
- Przewiń do Wstępne ładowanie stron w celu szybszego przeglądania i wyszukiwania i wyłącz tę opcję
Resetowanie wszystkich flag Chrome do wartości domyślnych:
- Przejdź do `chrome://flags`
- Kliknij Reset all w prawym górnym rogu
- Uruchom ponownie Chrome
Resetowanie wszystkich ustawień stosu sieciowego Chrome:
- Przejdź do Ustawienia > Zaawansowane > Resetuj i wyczyść > Przywróć ustawienia do oryginalnych wartości domyślnych
Nie powoduje to usunięcia zakładek ani haseł, ale resetuje strony startowe, ustawienia nowej karty, przypięte karty, ustawienia treści, pliki cookie i rozszerzenia — zapewniając w efekcie czystą bazę konfiguracji sieci.
Metoda 9: Zwiększenie limitu czasu połączenia TCP (zaawansowane)
Domyślnie Windows czeka około 21 sekund przed uznaniem próby połączenia TCP za nieudaną (na podstawie wartości rejestru `TcpMaxConnectRetransmissions`, która domyślnie wynosi 2 retransmisje z wykładniczym wycofaniem). W wolnych lub przeciążonych sieciach może to być zbyt krótko.
Dostosowanie przez Edytor rejestru (Windows):
- Otwórz `regedit`
- Przejdź do `HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters`
- Znajdź lub utwórz wartość DWORD o nazwie `TcpMaxConnectRetransmissions`
- Ustaw ją na `3` lub `4` (szesnastkowo), aby zezwolić na więcej prób retransmisji
Ważne: Zwiększa to czas, przez jaki Windows będzie czekać przed rezygnacją z połączenia TCP. Nie naprawia to podstawowej przyczyny — po prostu daje więcej czasu wolnym serwerom lub przeciążonym trasom na odpowiedź. Używaj tego tylko jako narzędzia diagnostycznego lub w konkretnych przypadkach użycia, takich jak łączenie się z geograficznie odległymi serwerami.
Metoda 10: Weryfikacja, czy serwer jest rzeczywiście osiągalny
Przed poświęceniem więcej czasu na naprawy po stronie klienta, potwierdź, czy problem leży po stronie serwera. Witryna może być całkowicie nieosiągalna z powodu zawieszonego konta hostingowego, reguły zapory sieciowej po stronie serwera lub błędnie skonfigurowanego serwera WWW — żadnego z tych problemów nie możesz naprawić z poziomu przeglądarki.
Narzędzia do sprawdzania osiągalności serwera z zewnętrznych punktów obserwacyjnych:
- downforeveryoneorjustme.com — Proste sprawdzenie dostępności/niedostępności z jednej lokalizacji
- downdetector.com — Agreguje raporty użytkowników dla głównych usług
- tools.pingdom.com — Testuje czas odpowiedzi z wielu globalnych lokalizacji
- mxtoolbox.com/SuperTool — Testuje DNS, nagłówki HTTP i łączność
- check-host.net — Pingi i sprawdzenia HTTP z dziesiątek węzłów geograficznych jednocześnie
Uruchom `curl -v https://yourdomain.com` z terminala, aby zobaczyć dokładny punkt awarii — czy połączenie TCP jest odrzucone, przekracza limit czasu, czy też nawiązuje się pomyślnie, ale zwraca kod błędu HTTP. To pojedyncze polecenie mówi więcej niż jakiekolwiek narzędzie z interfejsem graficznym.
Przyczyny po stronie serwera: co sprawdzić, jeśli jesteś właścicielem witryny
Jeśli jesteś właścicielem witryny i Twoi odwiedzający zgłaszają `ERR_CONNECTION_TIMED_OUT`, problem prawie na pewno leży w Twojej infrastrukturze. Najczęstsze przyczyny po stronie serwera to:
Wyczerpanie kolejki połączeń serwera WWW:
W Apache dyrektywa `MaxClients` (lub `MaxRequestWorkers` w Apache 2.4+) ogranicza jednoczesne połączenia. Po osiągnięciu tego limitu nowe połączenia kolejkują się i ostatecznie przekraczają limit czasu. Sprawdź bieżącą konfigurację:
“`
apache2ctl -V | grep -i mpm
grep -i maxrequestworkers /etc/apache2/apache2.conf
“`
W Nginx odpowiednikiem jest `worker_connections` w bloku `events` i `worker_processes`. Częstą błędną konfiguracją jest ustawienie `worker_processes` na `1` na serwerze wielordzeniowym, co tworzy wąskie gardło.
Zapora sieciowa blokująca ruch przychodzący na porcie 80/443:
Jeśli zarządzasz środowiskiem VPS Hosting, sprawdź reguły iptables lub nftables:
“`
iptables -L INPUT -n -v | grep -E "80|443"
“`
Brak reguły ACCEPT dla portów 80 i 443 spowoduje, że wszystkie połączenia przeglądarki będą po cichu przekraczać limit czasu. Sprawdź również, czy zapora sieciowa panelu sterowania hostingu (CSF, UFW lub Firewalld) nie zablokowała przypadkowo tych portów po aktualizacji zabezpieczeń.
Problemy z certyfikatem SSL powodujące przekroczenie limitu czasu uzgadniania TLS:
Wygasły lub błędnie skonfigurowany certyfikat SSL może powodować zawieszenie uzgadniania TLS, co w niektórych przypadkach brzegowych objawia się jako przekroczenie limitu czasu połączenia, a nie błąd certyfikatu — szczególnie przy użyciu starszych wersji TLS lub błędnie skonfigurowanych zestawów szyfrów. Zweryfikuj swój certyfikat za pomocą:
“`
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com
“`
Wyczerpanie zasobów serwera:
Wysokie użycie CPU lub RAM może spowodować, że proces serwera WWW stanie się nieodpowiadający. Na serwerze Linux sprawdź:
“`
top -b -n 1 | head -20
free -h
ss -s
“`
Polecenie `ss -s` pokazuje podsumowanie stanów gniazd — duża liczba połączeń w stanie `TIME-WAIT` lub `CLOSE-WAIT` wskazuje na problemy z obsługą połączeń, które spowodują przekroczenie limitu czasu nowych połączeń.
Błędna konfiguracja DNS po migracji serwera:
Jeśli niedawno przeniosłeś swoją witrynę na Serwer dedykowany lub zmieniłeś dostawcę hostingu, sprawdź, czy rekord A Twojej domeny wskazuje na prawidłowy adres IP i czy TTL starych rekordów wygasł. Użyj `dig yourdomain.com +trace`, aby prześledzić pełny łańcuch rozwiązywania DNS od serwerów głównych w dół.
Porównanie ERR_CONNECTION_TIMED_OUT z podobnymi błędami przeglądarki
| Kod błędu | Co oznacza | Najbardziej prawdopodobna przyczyna |
|---|
| — | — | — |
|---|
| ERR_CONNECTION_TIMED_OUT | Wysłano TCP SYN, nie odebrano SYN-ACK w limicie czasu | Zapora odrzucająca pakiety, przeciążenie serwera, awaria routingu |
|---|
| ERR_CONNECTION_REFUSED | TCP SYN otrzymał RST w odpowiedzi | Brak usługi nasłuchującej na tym porcie, zapora wysyłająca RST |
|---|
| ERR_NAME_NOT_RESOLVED | Wyszukiwanie DNS nie zwróciło żadnego wyniku | Błędna konfiguracja DNS, niezarejestrowana domena, NXDOMAIN |
|---|
| ERR_SSL_PROTOCOL_ERROR | Uzgadnianie TLS nie powiodło się | Wygasły certyfikat, niezgodność protokołów, niekompatybilność zestawu szyfrów |
|---|
| ERR_EMPTY_RESPONSE | TCP połączono, ale serwer nie wysłał żadnych danych | Awaria serwera WWW, pusta odpowiedź z aplikacji |
|---|
| ERR_CONNECTION_RESET | Połączenie zostało zresetowane w trakcie sesji | Przerwa w sieci, limit połączeń po stronie serwera, reset proxy |
|---|
| 504 Gateway Timeout | Odwrotne proxy przekroczyło limit czasu oczekiwania na źródło | Zbyt wolny serwer źródłowy, awaria połączenia upstream |
|---|
Zrozumienie tej tabeli ma kluczowe znaczenie operacyjne: jeśli rozwiązujesz problemy z własnym serwerem, konkretny błąd widziany przez użytkowników dokładnie wskazuje, którą warstwę stosu należy zbadać w pierwszej kolejności.
Praktyczna macierz decyzyjna: którą naprawę zastosować najpierw
Użyj tej sekwencji, aby zminimalizować czas diagnostyki:
- Czy możesz dotrzeć do innych stron internetowych? Nie — najpierw napraw lokalne połączenie sieciowe lub połączenie z ISP (Metody 1, 6). Tak — przejdź do kroku 2.
- Czy strona ładuje się na innym urządzeniu lub sieci? Tak — problem leży po stronie klienta (Metody 2, 3, 4, 5, 7). Nie — problem prawdopodobnie leży po stronie serwera lub dotyczy propagacji DNS.
- Czy zewnętrzny sprawdzacz (check-host.net) pokazuje stronę jako niedostępną z wielu lokalizacji? Tak — skontaktuj się z administratorem serwera lub dostawcą hostingu. Nie — problem dotyczy regionalnego routingu lub Twojego konkretnego ISP.
- Czy strona ładuje się w trybie incognito? Tak — przyczyną jest rozszerzenie przeglądarki lub dane w pamięci podręcznej (Metoda 4). Nie — przejdź do napraw na poziomie DNS i sieci.
- Czy niedawno zmieniłeś rekordy DNS lub migrowałeś serwery? Tak — poczekaj na propagację DNS i zweryfikuj rekordy za pomocą `dig` lub `nslookup`. Nie — sprawdź zaporę sieciową po stronie serwera i konfigurację serwera WWW.
Jeśli zarządzasz własną infrastrukturą serwerową — czy to na VPS z cPanel, czy w środowisku bare-metal — zawsze sprawdzaj logi serwera przed poświęcaniem czasu na naprawy po stronie klienta. Log błędów Apache (`/var/log/apache2/error.log`) i log błędów Nginx (`/var/log/nginx/error.log`) będą zawierać wyraźne zapisy błędów połączeń, zdarzeń wyczerpania zasobów i błędów konfiguracji.
Dla zespołów zarządzających wieloma domenami, centralizacja Rejestracji domen i zarządzania DNS u jednego dostawcy znacznie zmniejsza ryzyko błędów przekroczenia limitu czasu związanych z propagacją, spowodowanych podzielonymi konfiguracjami DNS lub wygasłymi rejestracjami domen.
Kluczowe wnioski techniczne
- `ERR_CONNECTION_TIMED_OUT` konkretnie wskazuje na błąd na poziomie TCP — pakiet SYN został wysłany, ale nie odebrano SYN-ACK. Odróżnia to go od błędów DNS, błędów TLS i błędów na poziomie HTTP.
- Zawsze testuj z zewnętrznego punktu obserwacyjnego (check-host.net, curl ze zdalnego serwera) przed założeniem, że problem leży na Twoim lokalnym komputerze.
- Chrome utrzymuje własną wewnętrzną pamięć podręczną DNS oddzielną od systemu operacyjnego. Opróżnienie tylko pamięci podręcznej systemu operacyjnego przez `ipconfig /flushdns` jest niewystarczające — musisz również wyczyścić `chrome://net-internals/#dns`.
- Po stronie serwera ciche odrzucanie pakietów przez reguły zapory sieciowej jest najczęstszą przyczyną tego konkretnego błędu. Odmowa połączenia (`RST`) generowałaby inny kod błędu.
- Opóźnienia propagacji DNS po migracjach serwera są często błędnie diagnozowane jako błędy przekroczenia limitu czasu. Zawsze weryfikuj za pomocą `nslookup` względem wielu resolwerów przed dalszym badaniem.
- W przypadku produkcyjnych serwerów WWW regularnie monitoruj dane wyjściowe `ss -s`. Rosnąca liczba `CLOSE-WAIT` wskazuje na błędy obsługi gniazd na poziomie aplikacji, które ostatecznie spowodują przekroczenie limitu czasu połączeń pod obciążeniem.
Często zadawane pytania
Dlaczego ERR_CONNECTION_TIMED_OUT pojawia się tylko na jednej konkretnej stronie, ale nie na innych?
Prawie zawsze oznacza to, że docelowy serwer jest nieosiągalny z Twojej sieci — albo serwer jest niedostępny, jego IP zmieniło się z powodu propagacji DNS, albo reguła zapory sieciowej na serwerze blokuje Twój zakres IP. Użyj zewnętrznego sprawdzacza, takiego jak check-host.net, aby potwierdzić, czy strona jest globalnie nieosiągalna, czy tylko nieosiągalna z Twojej lokalizacji.
Czy opróżnienie pamięci podręcznej DNS naprawia ERR_CONNECTION_TIMED_OUT?
Może, ale tylko jeśli przyczyną jest nieaktualny rekord DNS wskazujący na stary IP serwera. Jeśli rekord DNS jest prawidłowy, a serwer jest rzeczywiście nieosiągalny, opróżnienie pamięci podręcznej nie pomoże. Zawsze sprawdzaj, na jaki adres IP rozwiązuje się domena, używając `nslookup` przed i po opróżnieniu.
Czy VPN może powodować ERR_CONNECTION_TIMED_OUT?
Tak. VPN kieruje Twój ruch przez własne serwery i resolwery DNS. Jeśli serwer VPN jest przeciążony, geograficznie odległy lub ma problem z routingiem do docelowej witryny, zobaczysz błędy przekroczenia limitu czasu. Odłącz VPN i przetestuj bezpośrednio. Z drugiej strony, niektóre witryny blokują zakresy IP węzłów wyjściowych VPN na poziomie zapory sieciowej, co również spowoduje ten błąd.
Jak naprawić ERR_CONNECTION_TIMED_OUT na serwerze, którym zarządzam?
Sprawdzaj w tej kolejności: (1) potwierdź, że proces serwera WWW działa (`systemctl status nginx` lub `apache2`), (2) sprawdź, czy porty 80 i 443 są otwarte w zaporze sieciowej (`iptables -L` lub `ufw status`), (3) sprawdź użycie zasobów serwera za pomocą `top` i `free -h`, (4) przejrzyj log błędów serwera WWW w poszukiwaniu odmów połączeń lub komunikatów o wyczerpaniu procesów roboczych, (5) potwierdź, że Twój certyfikat SSL jest ważny i nie wygasł.
Czy ERR_CONNECTION_TIMED_OUT to to samo co 504 Gateway Timeout?
Nie. 504 Gateway Timeout to błąd na poziomie HTTP zwracany przez odwrotne proxy (takie jak Nginx lub CDN), gdy nie może uzyskać odpowiedzi od upstream serwera źródłowego w skonfigurowanym limicie czasu. `ERR_CONNECTION_TIMED_OUT` to błąd na poziomie przeglądarki, który występuje przed odebraniem jakiejkolwiek odpowiedzi HTTP — samo połączenie TCP nigdy nie zostaje zakończone. Oba wskazują na przekroczenie limitu czasu, ale na różnych warstwach stosu sieciowego.
