Как да поправите грешката ERR_CONNECTION_TIMED_OUT: Пълно техническо ръководство

Грешката ERR_CONNECTION_TIMED_OUT означава, че браузърът ви е изпратил заявка за връзка към отдалечен сървър, но не е получил отговор в рамките на определеното времево ограничение — обикновено 30 секунди при браузъри, базирани на Chromium. TCP ръкостискането никога не се завършва, така че браузърът изоставя опита и показва тази грешка вместо заредена страница.

Това не е повреда с единична причина. Тя може да произхожда от страната на клиента (вашата машина, вашата мрежа, вашият браузър), от междинната инфраструктура (DNS резолвери, прокси сървъри, защитни стени) или от страната на сървъра (претоварен сървър, неправилно конфигуриран уеб сървър, изтекъл SSL или повреда в маршрутизирането нагоре по веригата). Правилната диагностика изисква систематично преминаване през всеки слой.

Какво всъщност се случва при изтичане на времето за връзка

Когато въведете URL адрес и натиснете Enter, браузърът ви изпълнява точна последователност: DNS резолюция, TCP връзка (SYN / SYN-ACK / ACK), незадължително TLS ръкостискане, след което цикълът на HTTP заявка/отговор. Грешката за изтичане на времето означава, че процесът е спрял някъде в тази верига — най-често на етапа на TCP връзката, преди да бъдат обменени каквито и да е HTTP данни.

Разбирането кой етап е неуспешен ви казва къде да насочите усилията си за отстраняване. Неуспехът на DNS генерира различен код за грешка (`ERR_NAME_NOT_RESOLVED`). Неуспехът на TLS генерира `ERR_SSL_PROTOCOL_ERROR`. Когато виждате конкретно `ERR_CONNECTION_TIMED_OUT`, DNS търсенето е успяло, но TCP сокетът никога не е получил SYN-ACK от целевия IP. Това значително стеснява полето.

Основни причини: Защо възниква тази грешка

Метод 1: Проверете интернет връзката си на мрежово ниво

Не просто „проверявайте дали интернетът работи.” Изпълнете структуриран тест:

• Пингнете шлюза: Отворете Command Prompt и изпълнете `ping 192.168.1.1` (или IP адреса на вашия рутер). Ако това не успее, проблемът е между вашата машина и рутера.
• Пингнете публичен IP директно: Изпълнете `ping 8.8.8.8`. Ако това успее, но уебсайтовете не работят, проблемът е в DNS, а не в свързаността.
• Изпълнете traceroute: `tracert google.com` на Windows или `traceroute google.com` на Linux/macOS. Потърсете къде хоповете спират да отговарят — това идентифицира неуспешния мрежов сегмент.
• Рестартирайте рутера си: Изключете го от захранването за 30 секунди. Това принуждава нов DHCP наем и възстановява PPPoE/PPPoA сесията с вашия ISP.
• Тествайте на мобилна точка за достъп: Ако сайтът се зарежда по LTE, но не и по домашния ви широколентов достъп, проблемът е нагоре по веригата от вашия рутер — вероятно вашият ISP или конкретен маршрут, който използват.

Метод 2: Изчистете и възстановете DNS кеша

Отровен или остарял DNS кеш може да съхранява стар, недостъпен IP адрес за домейн, причинявайки всеки опит за връзка да изтече към сървър, който вече не съществува на този адрес.

На Windows:

“`

ipconfig /flushdns

ipconfig /registerdns

“`

На macOS (Ventura / Sonoma):

“`

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

“`

На Linux (systemd-resolved):

“`

sudo systemd-resolve –flush-caches

“`

След изчистването проверете дали кешът е изчистен на Windows с `ipconfig /displaydns` — изходът трябва да е минимален. След това опитайте отново връзката, преди да правите каквито и да е други промени, за да можете да изолирате дали DNS кешът е бил единствената причина.

Метод 3: Преминете към надежден публичен DNS резолвер

DNS резолверът по подразбиране на вашия ISP може да е бавен, ненадежден или подложен на географско филтриране. Замяната му с бърз, публичен резолвер често разрешава грешките при изтичане на времето, причинени от неуспешни DNS търсения, които безшумно връщат неправилни или никакви записи.

На Windows (IPv4):

1. Отворете Control Panel > Network and Internet > Network and Sharing Center > Change adapter settings.
2. Щракнете с десния бутон върху активния адаптер и изберете Properties.
3. Изберете Internet Protocol Version 4 (TCP/IPv4) и щракнете върху Properties.
4. Изберете Use the following DNS server addresses и въведете предпочитания от вас резолвер.

Препоръчани публични DNS резолвери:

Критичен краен случай: Ако наскоро сте мигрирали уебсайта си към нов сървър или сте променили A записа му, разпространението на DNS може да отнеме до 48 часа. През този период някои потребители ще бъдат насочени към стария IP. Изпълнението на `nslookup yourdomain.com 8.8.8.8` спрямо `nslookup yourdomain.com 1.1.1.1` ви позволява да сравните какво връщат различните резолвери — ако IP адресите се различават, намирате се в период на разпространение, а не в истинска грешка при изтичане на времето.

Метод 4: Изчистете кеша, бисквитките и разширенията на браузъра

Chrome и другите браузъри, базирани на Chromium, кешират DNS отговори независимо от DNS кеша на ниво операционна система. Този вътрешен DNS кеш на браузъра може да съдържа остарели записи дори след като изчистите системния кеш.

Изчистете вътрешния DNS кеш на Chrome директно:

1. Отидете на `chrome://net-internals/#dns`
2. Щракнете върху Clear host cache
3. Отидете на `chrome://net-internals/#sockets`
4. Щракнете върху Flush socket pools

Изчистете данните за сърфиране:

1. Отворете Chrome и натиснете `Ctrl + Shift + Delete`
2. Задайте времевия диапазон на All time
3. Отметнете Cookies and other site data и Cached images and files
4. Щракнете върху Clear data

Първо тествайте в прозорец за инкогнито. Ако сайтът се зарежда в инкогнито режим, но не и в нормален прозорец, виновникът е разширение на браузъра. Деактивирайте всички разширения чрез `chrome://extensions/` и ги активирайте едно по едно, за да идентифицирате нарушителя. Блокерите на реклами, VPN разширенията и инструментите за сигурност са най-честите източници на смущения.

Метод 5: Деактивирайте настройките на прокси

Неправилно конфигурирана или остаряла конфигурация на прокси е една от най-често пренебрегваните причини за тази грешка, особено на корпоративни машини или след деинсталиране на VPN софтуер, който е оставил прокси настройки.

Чрез Chrome:

1. Отидете на Settings > System > Open your computer's proxy settings
2. Под Manual proxy setup се уверете, че Use a proxy server е превключено на Off
3. Под Automatic proxy setup се уверете, че Use setup script е превключено на Off, освен ако умишлено не използвате PAC файл

Чрез настройките на Windows директно:

1. Отворете Settings > Network & Internet > Proxy
2. Деактивирайте всички ръчни прокси записи
3. Активирайте Automatically detect settings само ако вашата мрежа го изисква

Чрез Command Prompt (най-бърз метод):

“`

netsh winhttp reset proxy

“`

Това нулира WinHTTP прокси настройките до директна връзка, заобикаляйки всеки системен прокси, който може да е бил зададен от софтуер.

Метод 6: Нулирайте TCP/IP стека и Winsock каталога

Повредата в Winsock каталога — имплементацията на Windows на Berkeley sockets API — може да причини периодични или постоянни грешки при връзката, които изглеждат идентично на изтичания от страна на сървъра. Това е особено често срещано след премахване на зловреден софтуер, неуспешни актуализации на мрежови драйвери или агресивна антивирусна активност.

Отворете Command Prompt като администратор и изпълнете тези команди последователно:

“`

netsh winsock reset

netsh int ip reset resetlog.txt

ipconfig /release

ipconfig /flushdns

ipconfig /renew

“`

Рестартирайте машината си след изпълнение на всички команди. Файлът `resetlog.txt` ще бъде създаден в работната ви директория и регистрира всеки ключ в регистъра, който е бил нулиран — полезно за одит на това, което е било повредено.

На Linux еквивалентът за нулиране на мрежовото състояние е:

“`

sudo systemctl restart NetworkManager

sudo ip route flush cache

“`

Метод 7: Проверете правилата на защитната стена и антивирусната програма

Windows Defender Firewall и пакети за сигурност на трети страни могат безшумно да блокират изходящи връзки към конкретни портове, IP диапазони или домейни. Блокирането не генерира незабавна грешка „connection refused” — вместо това пакетите се отхвърлят и браузърът чака, докато се достигне прагът за изтичане на времето.

Временен диагностичен тест:

1. Отидете на Control Panel > System and Security > Windows Defender Firewall
2. Щракнете върху Turn Windows Defender Firewall on or off
3. Временно го деактивирайте за частни и публични мрежи
4. Опитайте връзката

Ако сайтът се зарежда с деактивирана защитна стена, незабавно я активирайте отново и след това създайте конкретно правило за изходящ трафик, за да разрешите трафика към засегнатия домейн или IP, вместо да оставяте защитната стена изключена. Отидете на Advanced Settings > Outbound Rules > New Rule, за да конфигурирате това прецизно.

За антивирусен софтуер: Повечето съвременни пакети включват функция за HTTPS инспекция или „уеб щит”, която извършва прихващане на TLS трафика тип „човек по средата”. Това може да наруши връзките, ако основният сертификат на антивирусната програма не се доверява от браузъра, или ако антивирусната програма неправилно маркира целевия сървър. Временното деактивиране на компонента за уеб щит (а не на цялата антивирусна програма) е по-прецизен тест от деактивирането на цялата защита.

Метод 8: Нулирайте флаговете на Chrome и мрежовия предиктор

Експерименталните флагове на Chrome и функциите за мрежово предсказване понякога могат да причинят проблеми с връзката, особено след актуализации на браузъра, които променят поведението на тези функции.

Деактивирайте мрежовото предсказване:

1. Отидете на Settings > Privacy and security > Cookies and other site data
2. Превъртете до Preload pages for faster browsing and searching и го деактивирайте

Нулирайте всички флагове на Chrome до стойностите по подразбиране:

1. Отидете на `chrome://flags`
2. Щракнете върху Reset all в горния десен ъгъл
3. Рестартирайте Chrome

Нулирайте всички настройки на мрежовия стек на Chrome:

1. Отидете на Settings > Advanced > Reset and clean up > Restore settings to their original defaults

Това не изтрива отметките или паролите, но нулира началните страници, настройките за нов раздел, закачените раздели, настройките за съдържание, бисквитките и разширенията — като ви дава чиста базова конфигурация на мрежата.

Метод 9: Увеличете времето за изчакване на TCP връзката (разширено)

По подразбиране Windows изчаква приблизително 21 секунди, преди да обяви неуспех на опит за TCP връзка (въз основа на стойността в регистъра `TcpMaxConnectRetransmissions`, която по подразбиране е 2 повторни предавания с експоненциално нарастване). При бавни или претоварени мрежи това може да е твърде кратко.

Коригирайте чрез Registry Editor (Windows):

1. Отворете `regedit`
2. Отидете на `HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters`
3. Намерете или създайте DWORD стойност с име `TcpMaxConnectRetransmissions`
4. Задайте я на `3` или `4` (шестнадесетично), за да разрешите повече опити за повторно предаване

Важно: Това увеличава времето, което Windows ще изчака, преди да се откаже от TCP връзка. То не отстранява основната причина — просто дава повече време на бавни сървъри или претоварени маршрути да отговорят. Използвайте това само като диагностичен инструмент или за конкретни случаи на употреба, като например свързване към географски отдалечени сървъри.

Метод 10: Проверете дали сървърът е действително достъпен

Преди да прекарате повече време в поправки от страна на клиента, потвърдете дали проблемът е от страна на сървъра. Уебсайт може да е напълно недостъпен поради спрян хостинг акаунт, правило на защитна стена от страна на сървъра или неправилно конфигуриран уеб сървър — нито едно от които не можете да поправите от браузъра си.

Инструменти за проверка на достъпността на сървъра от външни точки:

• downforeveryoneorjustme.com — Проста проверка дали е нагоре/надолу от едно местоположение
• downdetector.com — Обобщава потребителски доклади за основни услуги
• tools.pingdom.com — Тества времето за отговор от множество глобални местоположения
• mxtoolbox.com/SuperTool — Тества DNS, HTTP заглавки и свързаност
• check-host.net — Пинг и HTTP проверки от десетки географски възли едновременно

Изпълнете `curl -v https://yourdomain.com` от терминал, за да видите точната точка на неуспех — дали TCP връзката е отказана, изтича или успява, но връща HTTP код за грешка. Тази единична команда ви казва повече от всеки GUI инструмент.

Причини от страна на сървъра: Какво да проверите, ако притежавате уебсайта

Ако сте собственик на уебсайта и посетителите ви съобщават за `ERR_CONNECTION_TIMED_OUT`, проблемът е почти сигурно във вашата инфраструктура. Най-честите причини от страна на сървъра са:

Изчерпване на опашката за връзки на уеб сървъра:

В Apache директивата `MaxClients` (или `MaxRequestWorkers` в Apache 2.4+) ограничава едновременните връзки. Когато се достигне този лимит, новите връзки се нареждат на опашка и в крайна сметка изтичат. Проверете текущата си конфигурация:

“`

apache2ctl -V | grep -i mpm

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

“`

В Nginx еквивалентът е `worker_connections` в блока `events` и `worker_processes`. Честа неправилна конфигурация е задаването на `worker_processes` на `1` на многоядрен сървър, създавайки тесно място.

Защитна стена, блокираща входящия трафик на порт 80/443:

Ако управлявате среда за VPS хостинг, проверете правилата на iptables или nftables:

“`

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

“`

Липсващо правило ACCEPT за портове 80 и 443 ще накара всички браузърни връзки да изтичат безшумно. Проверете също дали защитната стена на вашия хостинг контролен панел (CSF, UFW или Firewalld) не е блокирала случайно тези портове след актуализация на сигурността.

Проблеми с SSL сертификата, причиняващи изтичания при TLS ръкостискане:

Изтекъл или неправилно конфигуриран SSL сертификат може да накара TLS ръкостискането да спре, което в някои крайни случаи се проявява като изтичане на времето за връзка, а не като грешка на сертификата — особено при използване на по-стари TLS версии или неправилно конфигурирани шифрови набори. Проверете сертификата си с:

“`

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

“`

Изчерпване на ресурсите на сървъра:

Високото използване на CPU или RAM може да накара процеса на уеб сървъра да стане неотзивчив. На Linux сървър проверете:

“`

top -b -n 1 | head -20

free -h

ss -s

“`

Командата `ss -s` показва обобщение на състоянията на сокетите — голям брой връзки в състояние `TIME-WAIT` или `CLOSE-WAIT` показва проблеми с обработката на връзките, които ще накарат новите връзки да изтичат.

Неправилна DNS конфигурация след миграция на сървъра:

Ако наскоро сте преместили сайта си на Dedicated сървър или сте сменили хостинг доставчика си, проверете дали A записът на домейна ви сочи към правилния IP адрес и дали TTL на старите записи е изтекъл. Използвайте `dig yourdomain.com +trace`, за да проследите пълната верига на DNS резолюция от основните сървъри надолу.

Сравнение на ERR_CONNECTION_TIMED_OUT с подобни грешки в браузъра

Разбирането на тази таблица е оперативно важно: ако отстранявате проблеми на собствения си сървър, конкретната грешка, която виждат потребителите ви, ви казва точно кой слой на стека да разследвате първо.

Практическа матрица за вземане на решения: Коя поправка да приложите първо

Използвайте тази последователност, за да минимизирате времето за диагностика:

1. Можете ли да достигнете до други уебсайтове? Не — първо поправете локалната мрежа или ISP връзката (Методи 1, 6). Да — преминете към стъпка 2.
2. Зарежда ли се сайтът на различно устройство или мрежа? Да — проблемът е от страна на клиента (Методи 2, 3, 4, 5, 7). Не — проблемът е вероятно от страна на сървъра или разпространение на DNS.
3. Показва ли външна проверка (check-host.net) сайта като недостъпен от множество местоположения? Да — свържете се с администратора на сървъра или вашия хостинг доставчик. Не — проблемът е регионално маршрутизиране или вашият конкретен ISP.
4. Зарежда ли се сайтът в режим инкогнито? Да — причината е разширение на браузъра или кешираните данни (Метод 4). Не — преминете към поправки на ниво DNS и мрежа.
5. Променихте ли наскоро DNS записи или мигрирахте ли сървъри? Да — изчакайте разпространението на DNS и проверете записите с `dig` или `nslookup`. Не — проверете защитната стена от страна на сървъра и конфигурацията на уеб сървъра.

Ако управлявате собствена сървърна инфраструктура — независимо дали на VPS с cPanel или в среда с голям метал — винаги проверявайте сървърните логове, преди да прекарвате време в поправки от страна на клиента. Логът за грешки на Apache (`/var/log/apache2/error.log`) и логът за грешки на Nginx (`/var/log/nginx/error.log`) ще съдържат изрични записи за грешки при връзката, събития за изчерпване на ресурсите и грешки в конфигурацията.

За екипи, управляващи множество домейни, централизирането на регистрацията на домейни и управлението на DNS при един доставчик значително намалява риска от грешки при изтичане на времето, свързани с разпространението, причинени от разделени DNS конфигурации или изтекли регистрации на домейни.

Ключови технически изводи

• `ERR_CONNECTION_TIMED_OUT` конкретно показва повреда на TCP ниво — SYN пакетът е изпратен, но не е получен SYN-ACK. Това го отличава от DNS грешки, TLS грешки и HTTP грешки.
• Винаги тествайте от външна точка (check-host.net, curl от отдалечен сървър), преди да приемете, че проблемът е на локалната ви машина.
• Chrome поддържа собствен вътрешен DNS кеш, отделен от кеша на операционната система. Изчистването само на кеша на операционната система чрез `ipconfig /flushdns` е недостатъчно — трябва също да изчистите `chrome://net-internals/#dns`.
• От страна на сървъра, безшумното отхвърляне на пакети от правила на защитната стена е единствената най-честа причина за тази конкретна грешка. Отказана връзка (`RST`) би генерирала различен код за грешка.
• Забавянията при разпространение на DNS след миграции на сървъри често се диагностицират погрешно като грешки при изтичане на времето. Винаги проверявайте с `nslookup` срещу множество резолвери, преди да продължите с разследването.
• За производствени уеб сървъри редовно наблюдавайте изхода на `ss -s`. Нарастващ брой `CLOSE-WAIT` показва грешки при обработката на сокети на ниво приложение, които в крайна сметка ще причинят изтичания на времето за връзка при натоварване.

Често задавани въпроси

Защо ERR_CONNECTION_TIMED_OUT се появява само на един конкретен уебсайт, но не и на други?

Това почти винаги означава, че целевият сървър е недостъпен конкретно от вашата мрежа — или сървърът е изключен, IP адресът му се е променил поради разпространение на DNS, или правило на защитна стена на сървъра блокира вашия IP диапазон. Използвайте външна проверка като check-host.net, за да потвърдите дали сайтът е глобално недостъпен или само недостъпен от вашето местоположение.

Изчистването на DNS кеша поправя ли ERR_CONNECTION_TIMED_OUT?

Може, но само ако причината е остарял DNS запис, сочещ към стар IP на сървъра. Ако DNS записът е правилен и сървърът е наистина недостъпен, изчистването на кеша няма да помогне. Винаги проверявайте към кой IP адрес се резолвира домейнът, като използвате `nslookup` преди и след изчистването.

Може ли VPN да причини ERR_CONNECTION_TIMED_OUT?

Да. VPN маршрутизира трафика ви през собствените си сървъри и DNS резолвери. Ако VPN сървърът е претоварен, географски отдалечен или има проблем с маршрутизирането към целевия сайт, ще виждате грешки при изтичане на времето. Изключете VPN и тествайте директно. Обратно, някои сайтове блокират IP диапазоните на изходните възли на VPN на ниво защитна стена, което също ще генерира тази грешка.

Как да поправя ERR_CONNECTION_TIMED_OUT на сървър, който управлявам?

Проверете в следния ред: (1) потвърдете, че процесът на уеб сървъра работи (`systemctl status nginx` или `apache2`), (2) проверете дали портове 80 и 443 са отворени в защитната стена (`iptables -L` или `ufw status`), (3) проверете използването на ресурсите на сървъра с `top` и `free -h`, (4) прегледайте лога за грешки на уеб сървъра за откази на връзки или съобщения за изчерпване на работниците, (5) потвърдете, че SSL сертификатът ви е валиден и не е изтекъл.

ERR_CONNECTION_TIMED_OUT същото ли е като 504 Gateway Timeout?

Не. 504 Gateway Timeout е HTTP грешка, върната от обратен прокси (като Nginx или CDN), когато не може да получи отговор от upstream изходния сървър в рамките на конфигурираното му времево ограничение. `ERR_CONNECTION_TIMED_OUT` е грешка на ниво браузър, която възниква преди да бъде получен какъвто и да е HTTP отговор — самата TCP връзка никога не се завършва. И двете показват изтичане на времето, но на различни слоеве на мрежовия стек.