Грешка 522: Connection Timed Out – какво означава и как да я поправите

Вашият сайт е работил нормално преди час. Нищо не е променяно. Изведнъж започват да пристигат клиентски заявки: посетителите виждат страницата на Cloudflare с „Грешка 522: Време за изчакване на връзката“, а и вашият браузър показва същото.

Ето полезната част.

Грешка 522 ограничава проблема до една част от пътя на заявката: връзката между Cloudflare и вашия origin сървър. Посетителят е достигнал Cloudflare без проблем. Cloudflare просто не е получил очаквания отговор от вашата страна.

Това все още оставя няколко възможни причини – сървърът, firewall, остарял DNS запис или мрежата между тях – но изключва много други, а проверките по-долу минават през останалите в логичен ред.

Краткият отговор: Грешка 522 означава, че Cloudflare не е получил необходимата TCP отговор от origin сървъра навреме – или няма SYN+ACK в рамките на 19 секунди, или няма потвърждение на заявката в рамките на 90 секунди след отваряне на връзката. 

Най-често срещани причини са блокирани IP диапазони на Cloudflare, претоварен или спрян origin, грешка в origin DNS записа, изключени keepalives и загуба на пакети между Cloudflare и origin.

Какво е грешка 522?

Грешка 522 е специфичен статус код на Cloudflare, който означава, че Cloudflare не е успял да завърши връзката с вашия origin сървър в рамките на таймаута. Не е проблем на браузъра на посетителя и не е проблем с неговата мрежа – посетителят е достигнал Cloudflare. Проблемът е в пътя до origin сървъра.

Официалната документация на Cloudflare за грешка 522 определя два различни таймаута, и двата водят до една и съща страница:

• Преди отваряне на връзката: origin не връща SYN+ACK в рамките на 19 секунди след като Cloudflare изпрати SYN.
• След отваряне на връзката: origin не потвърждава заявката на Cloudflare в рамките на 90 секунди.

Първият е провал на ниво handshake – сървърът така и не е „вдигнал телефона“. Вторият е неизпълнена заявка – вдигнал е, но после е замълчал. И двата показват една и съща грешка, затова error 522 сама по себе си не казва кой от двата е проблемът.

Грешката показва три панела – браузър, Cloudflare, хост – и при 522 първите два са маркирани като работещи, а третият е с проблем. Това сочи към пътя до origin сървъра, където вероятно се корени проблемът.

Какво причинява грешка 522?

Грешка 522 има една основна причина – origin не е отговорил навреме – но към нея водят няколко пътя. Ето най-важните, подредени приблизително по честота, с която се оказват виновни.

• Правила на firewall, блокиращи IP диапазоните на Cloudflare

Това е най-честата причина, а и самата документация на Cloudflare я посочва като такава. След като сайтът работи зад Cloudflare, всяка заявка, която origin вижда, идва от IP адрес на Cloudflare, а не от отделните посетители. За инструмент за сигурност, който следи обема на връзките, това изглежда като шепа адреси, които удрят сървъра хиляди пъти в минута.

Затова firewall прави точно това, за което е конфигуриран – започва да отхвърля трафика.

Разликата между „drop“ и „reject“ е важна тук.

Firewall, който reject-ва връзката, води до 521. Такъв, който silently drop-ва пакетите, обикновено води до 522, защото Cloudflare не получава никакъв отговор. Това трябва да се приема като нормално поведение, а не като гаранция. Също така е полезно да знаете на кое ниво работите: firewalls, rate limiters, fail2ban и cloud security groups действат на самата връзка, докато .htaccess правила и security plugins reject-ват заявката след като уеб сървърът вече я е приел.

• Претоварен origin сървър или недостатъчно ресурси

Машина, която е изчерпала CPU, памет или налични слотове за връзки, не може да завърши handshake, дори ако web сървърът технически работи. Трафик spike, runaway cron job, плъгин, който е зациклил, или заявка към датабазата, която сканира голяма таблица без индекс – всичко това може да доведе до грешка 522.

На shared hosting проблемът се усилва – surge от трафик на съсед може да остави вашия сайт без необходимите връзки. Ако реалният проблем е приложение, което се забавя под натоварване, оптимизацията на WordPress ще ви помогне повече от всякаква промяна на firewall.

• Спрян web сървър или offline машина

Apache, Nginx или LiteSpeed, които са “забили” или не са се стартирали след промяна на конфигурация е вероятната версия на проблема. Същото важи за failed reboot или instance, който е спрян и не е рестартиран.

• Остарял origin IP в DNS на Cloudflare

Ако сървърът е мигриран или е получил нов адрес, а A или AAAA записът в Cloudflare все още сочи към стария, Cloudflare продължава да набира номер, на който никой не отговаря. Това е особено дразнещо, защото на сървъра всичко изглежда наред и всички локални тестове минават безпроблемно.

• Изключени keepalives

Cloudflare използва persistent TCP връзки вместо да отваря нова за всяка заявка. Ако keepalives са изключени, всяка заявка принуждава нов handshake – умножава overhead и увеличава шанса една от тях да timeout-не под натоварване.

• Загуба на пакети между Cloudflare и вашия origin

Понякога вината наистина е в мрежовия път – например лош router, натоварен uplink или null route между edge-а на Cloudflare и вашия дата център. MTR от origin към Cloudflare IP е начинът да го докажете, и това е доказателството, което техническия съпорт ще поиска.

Грешка 522 vs. 521 vs. 524 – как да различаваме origin грешките на Cloudflare

5xx семейството на Cloudflare изглежда взаимозаменяемо от външна гледна точка, но всяко число описва различен проблем в различен момент. Правилното четене на числото ви спестява проверка на грешния слой.

Грешка	Какво се е случило	Къде се проваля	Най-вероятна причина	Проверка първо
521 – Web Server Is Down	Origin активно отказва връзката (TCP reset)	Handshake	Web сървър процесът е спрян или firewall reject-ва Cloudflare	Apache/Nginx/LiteSpeed работи ли?
522 – Connection Timed Out	Необходимият TCP отговор или потвърждение не е дошло навреме	Handshake или early request	Firewall silently drop-ва Cloudflare IPs; претоварен origin	Cloudflare IP allowlist, здраве на сървъра, DNS, мрежов път
523 – Origin Is Unreachable	Cloudflare не може да route-не към origin	Routing	Грешен origin IP в DNS; origin е премахнат от мрежата	A / AAAA записът в Cloudflare DNS
524 – A Timeout Occurred	Origin приема връзката, но не връща HTTP отговор преди read timeout	Application	Бавна query, long-running script, heavy export/import	Производителност на application и database

Двойката 522/524 причинява най-много объркване. Грешка 522 означава, че Cloudflare не е получил TCP отговора или потвърждението, от което се нуждае в рамките на документирания прозорец. Грешка 524 се случва по-късно: origin е приел връзката и е потвърдил заявката, след което не е върнал HTTP отговор преди Proxy Read Timeout на Cloudflare (по подразбиране 120 секунди).

Тази разлика определя къде да погледнете първо.

522 ви насочва към firewall, наличност на сървъра, DNS и мрежовия път. 524 ви насочва към бавна заявка, long-running script или heavy import/export.

Грешка 522 от ваша страна ли е? Какво трябва да направят посетителите

Кратък отговор – Не.

Ако сте посетител, а не собственик на сайта, грешка 522 почти никога не е проблем от ваша страна. Вашият браузър е достигнал Cloudflare успешно – провалът е между Cloudflare и сървъра на сайта, инфраструктура, до която нямате достъп. Изчистване на cookies, смяна на браузър или рестартиране на рутера няма да промени нищо.

Все пак може да направите три бързи проверки:

1. Hard refresh на страницата. Ctrl+F5 на Windows, Cmd+Shift+R на Mac. Рядко решава 522, но не струва нищо и изключва stale page.
2. Опитайте друга мрежа. Заредете сайта през мобилни данни вместо Wi-Fi. Ако работи там, проблемът може да е локален DNS или routing quirk, а не 522.
3. Потвърдете, че е down за всички. Third-party uptime checker ще ви каже за секунди дали outage-ът е глобален.

След това чакането е единствената реална опция, защото поправката трябва да стане на инфраструктура, която не контролирате. Съобщаването на outage през друг канал обикновено стига по-бързо до собственика на сайта, отколкото тихо чакане.

Какво няма да оправи грешка 522

Защото error 522 се чупи в пътя към origin сървъра, цяла категория познати troubleshooting стъпки нямат ефект. Пропускането им спестява време по време на outage:

• Изчистване на cookies, смяна на браузъри или многократно рефрешване
• Преинсталиране на плъгини или редактиране на application код преди да потвърдите origin connectivity
• Оставяне на proxy-то на Cloudflare изключено за постоянно – полезно като temporary isolation test, но излага origin директно и премахва защитата, заради която сте включили proxy-то
• Редактиране на firewall правила без console access и тестван начин за връщане назад

Как да поправите грешка 522 като собственик на сайт

Минавайте през тези стъпки по ред. Последователността върви от най-лесната проверка към по-сложните, и всяка стъпка изключва цяла категория причини.

1. Потвърдете, че outage-ът е реален и глобален. Тествайте от външен uptime инструмент, а не само от вашия браузър. Запишете Cloudflare Ray ID от error страницата и точния час с часова зона – и двете са трудни за възстановяване по-късно и са първото, което един технически сътрудник ще поиска.
2. Изключете Cloudflare самия. Проверете Cloudflare system status страницата. Ако има активен проблем, който засяга вашия регион, няма какво да поправяте от ваша страна.
3. Проверете дали origin е up и serving. Потвърдете, че уеб сървър процесът работи, след което заявете сайта през loopback. Успехът през loopback доказва само, че локалният процес отговаря локално, затова последвайте с заявка към public IP на origin от външна машина, с правилен Host header. Това всъщност ви казва дали origin приема external трафик.
4. Проверете firewall за блокирани Cloudflare ranges. Тук завършват повечето 522 разследвания. Вижте секцията за allowlisting по-долу.
5. Погледнете resource usage. Средно натоварване, свободна памет, брой отворени връзки и disk I/O wait. Сървър, който е pinned на 100%, няма да завършва handshakes надеждно.
6. Сравнете DNS записа на Cloudflare с реалния origin IP. Трябва да съвпадат точно, включително IPv6 записа ако имате такъв.
7. Потвърдете, че keepalives са включени в конфигурацията на web сървъра, с разумна timeout стойност.
8. Направете MTR от origin към Cloudflare IP, който се появява в access logs – диагностиката, която и Cloudflare, и хостингът ще поискат.

Whitelisting на IP диапазоните на Cloudflare в firewall-а на сървъра

За proxied записи, origin сървъра вижда заявките, идващи от мрежовите диапазони на Cloudflare, а не от отделните посетители. Затова firewall-ът и rate-limiting инструментите трябва да позволяват текущите IPv4 и IPv6 диапазони на Cloudflare на web портовете, които използвате. Cloudflare казва, че тези диапазони не се променят често и добавките се публикуват преди да влязат в production – но винаги работете с официалния списък, а не с такъв копиран от статия.

Ако сте на NS1 managed VPS, говорете с техническия екип преди да редактирате production firewall правила сами. Нашият екип може да инспектира CSF, web сървъра и origin-side connectivity директно. Това елиминира двата чести начина, по които това може да се обърка на live сървър: да се заключите извън SSH или да отворите повече услуги от планираното.

Ако администрирате сървъра сами, формата на правилото е една и съща навсякъде: позволяване на Cloudflare range, на уеб порта, за двете адресни фамилии. Примерът по-долу следва iptables подхода от документацията на Cloudflare, плюс UFW еквивалента. Нужни предпоставки: root или sudo access и SSH сесия, която държите отворена през цялото време.

⚠️ Предупреждение: Презареждането на firewall прилага правилата веднага. Ако правило е malformed или подредено неправилно, можете да се заключите от SSH. Дръжте съществуващата сесия отворена и проверете достъпа от втора терминал преди да я затворите. Имайте console или rescue-mode access на провайдъра като fallback.

Bash

Три неща, които snippet-ът не обработва сам:

• IPv6. Ако публикувате AAAA запис през proxy, Cloudflare ще достига origin през IPv6 и тези заявки ще се провалят, освен ако v6 диапазоните не са allowed.
• Port 80. Добавете съответните правила за port 80 ако работите с plain HTTP, включително redirects.
• Application-level blocks. Firewall правила не override-ват deny директивите в .htaccess, blocklist на security plugin или fail2ban jail. Те работят над firewall-а и трябва да се проверяват отделно.

Кога да се обърнете към вашия хост (NS1)

Ако origin сървърът работи, ресурсите изглеждат здрави, Cloudflare диапазоните са allowed и DNS записът съвпада, причината вероятно е на слой, който не виждате – network-level packet loss, upstream routing или hypervisor resource contention.

Който поеме тикета ще поиска едни и същи доказателства всеки път. Събирането им предварително превръща двудневен back-and-forth в един отговор:

Доказателство	Какво установява
Cloudflare Ray ID	Идентифицира точната failed заявка в логовете на Cloudflare
Timestamp с часова зона	Корелира failure-а със server, firewall и network logs
Direct-origin test result	Показва дали origin отговаря извън Cloudflare
Current A / AAAA records	Открива stale или грешен origin IP
CPU, memory, I/O, connection counts	Открива overload или resource exhaustion
MTR или traceroute	Показва packet loss или routing проблеми в пътя
Web сървър и firewall logs	Показва refused, dropped или rate-limited заявки

Изпратете това заедно с това, което вече сте изключили от собствените си тестове. Говорете с техническия екип на NS1 – нашият съпорт обработва origin-side diagnostics директно, вместо да ви насочва към knowledgebase статия.

Как да диагностицирате грешка 522 на NS1 managed VPS

Слоевете, които трябва да проверите при NS1, са същите като на всеки managed VPS. 

Започнете с това, което можете да потвърдите без да пипате сървъра: proxied A и AAAA записите все още съвпадат с origin IP и timeout-ът съвпада с resource spike или спряна услуга. Уебсайт мониторингът на SPanel проверява URL на всеки 1, 5, 10 или 15 минути и записва HTTP status и response time, така че 522 прозорецът обикновено има видима форма в историята.

Струва си да знаете преди да започнете да рестартирате неща: всеки SPanel сървър има five-minute service watchdog, който проверява уеб сървъра, MariaDB, Exim, Dovecot, Pure-FTPd, BIND и всяка инсталирана PHP-FPM версия и стартира всичко, което намери спряно. Web сървър, който е crashed в 3 сутринта, обикновено се връща в рамките на пет минути без клиента дори да разбере. Това също означава, че persistent 522 е малко вероятно да е просто спряна услуга – гледайте към overload, DNS, firewall или мрежовия път. Watchdog проверява дали процесът работи, не дали отговаря, така че hung процес е случай, който не хваща.

Едно предупреждение, което си струва да планирате: monitoring, който работи на сървъра, който наблюдава, пада с този сървър. Ако имате повече от един NS1 сървър, конфигурирането всеки да мониторира другите елиминира този проблем без допълнителни разходи.

Ако origin изглежда здрав и Cloudflare все още връща 522, това е моментът да отворите тикет вместо да продължавате да променяте конфигурацията си.

Как да спрете грешка 522 да се връща

Поправянето на грешка 522 веднъж е troubleshooting. Да се уверите, че не се връща, е инфраструктурно решение – и се свежда до три неща: headroom, visibility и redundancy.

Headroom е това, което хората подценяват.

Сървър, оразмерен точно за среден трафик, няма нищо останало когато кампанията приключи или бот обходи сайта, и connection timeouts са първият симптом на това стискане. 

Управляемият VPS хостинг ви изолира от съседи на споделен хостинг и ви позволява да скалирате ресурси без миграция. Бъдете точни за това какво купувате – акаунтите и сайтовете в един VPS все още споделят алокираното CPU, оперативна памет и disk throughput, така че “избягал” процес от ваша страна все още може да изразходи ресурсите на машината.

Visibility превръща дълъг outage в кратък.

SPanel покрива част от това чрез уебсайт мониторингът описан по-горе; свържете го със ресурсната видимост на сървъра, защото двата отговарят на различни въпроси. 522 обикновено се анонсира в response times преди да се появи проблем.

Redundancy има значение когато един origin не стига.

Ако бизнесът ви не може да абсорбира downtime – една машина винаги е single point of failure, което никакви настройки не могат да премахнат.

Може да опитате и друг хостинг подход.

Управляемият Cluster Hosting разпределя трафика през nodes, така че когато health checks маркират един от тях като проблемен, новите заявки отиват към другите, работещи nodes. Важно е да се каже, че това намалява рисковете от единичен сървър, а не елиминира downtime.

ВАЖНО: Ако имате нужда от повече информация за управляемият cluster hosting – свържете се с нас и с радост ще разгледаме вашият специфичен случай.

Три навика предотвратяват повечето повтарями инциденти: проверявайте Cloudflare allowlist срещу официалния списък когато променяте firewall или security tooling, оставете алармите на origin response time вместо само на uptime и одитирайте плъгините за сигурност за правила, които блокират трафика, от който зависи CDN-ът ви.

Заключение

Грешка 522 означава, че Cloudflare не е получил отговора, от който се нуждае от вашия origin път навреме. Работете по причините, които са едновременно чести и бързи за потвърждаване: проверете дали origin IP в DNS е актуален, дали уеб сървърът отговаря, дали публикуваните IPv4 и IPv6 диапазони на Cloudflare са позволени и дали load и connection капацитетите са в нормални граници.

Ако всичко това минава безпроблемно, спрете да променяте конфигурацията и започнете да събирате доказателства. Failure timestamp, Ray ID, direct-origin test и route data позволяват на вашия хост да отдели firewall проблем от overload, лош DNS или upstream routing много по-бързо от това да проверява произволни предположения.

Ако сайтът ви timeout-ва защото един сървър работи по-близо до лимитите си, отколкото трябва, това е capacity проблем, а не configuration – вижте какво биха променили dedicated, scalable ресурси за вашия setup.

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

В: Какво причинява грешка 522?

О: Грешка 522 се случва когато Cloudflare не получи необходимата TCP отговор от origin сървъра в рамките на таймаут прозореца – 19 секунди за initial handshake или 90 секунди за заявката. Документацията на Cloudflare посочва блокирани или rate-limited Cloudflare IP адреси като най-честа причина. Претоварени сървъри, спрени уеб сървър процеси, stale origin IP адреси в DNS, изключени keepalives и packet loss обясняват останалото.

В: Грешка 522 от моя страна ли е?

О: Ако посещавате сайта – не. Проблемът е между Cloudflare и сървъра, на който се хоства уебсайта. Ако притежавате сайта, ваш е за разследване, макар сървърът да не е непременно виновен: firewall, DNS записът или мрежовият път между Cloudflare и дата центъра ви са всички кандидати.

В: Как да поправя грешка 522 на NS1?

О: Потвърдете, че proxied A и AAAA записите все още съвпадат с origin IP, след което проверете дали таймаутът съвпада с ресурсно потребление или спряна услуга – SPanel website monitoring history е най-бързото място да видите това. Тъй като watchdog рестартира спрени услуги на всеки пет минути, persistent 522 е по-вероятно поради overload, DNS, firewall или мрежовия път. Отворете съпорт тикет с URL, timestamp и часова зона, Cloudflare Ray ID и тестовете, които сте направили. Екипът на NS1 може да инспектира origin firewall и logs без вие да правите рисковани промени на лайв сървър.

В: Колко време трае грешка 522?

О: Толкова, колкото причинатата за нея продължава. 522 не е състояние, което Cloudflare налага и после вдига – тя се изчиства в момента, в който origin отговаря в рамките на timeout прозореца. 522, предизвикана от traffic spike, може да се реши когато load спадне. Firewall-driven 522 продължава докато правилото не се промени. Повтаряема грешка 522 заслужава разследване, а не търпение.

В: Грешка 522 засяга ли SEO?

О: Продължителни 522 грешки носят реален SEO риск. Google документира, че 5xx responses карат обхождането на сайта да се забавя, индексираните URL адреси се задържат отначало, а тези, които fail-ват за продължителен период от време, накрая се изключват от index-а. Кратките инциденти обикновено се абсорбират; сайт, който връща 522 регулярно, губи crawl rate, а с времето, и засегнатите URLs.