Как да поправите Cloudflare грешка 520: Пълно ръководство за диагностика и отстраняване

Cloudflare грешка 520 е HTTP статус код, върнат когато мрежата на Cloudflare получи празен, неочакван или по друг начин неинтерпретируем отговор от вашия сървър. За разлика от 502 или 504, които указват изтичане на времето на шлюза или лош шлюз, 520 е универсалният код на Cloudflare за отговори, които не попадат в нито една призната HTTP спецификация — което означава, че сървърът технически е отговорил, но изпратеното обратно е невалидно, съкратено или структурно деформирано.

От практическа гледна точка, грешка 520 означава, че TCP връзката между Cloudflare и вашия сървър е установена, но HTTP-слоевото ръкостискане се е провалило. Потребителят вижда страница с грешка с марката на Cloudflare и съобщението "Уеб сървърът връща неизвестна грешка" — и вашият сайт е практически офлайн за тях.

Какво предизвиква грешка 520: Обяснение на основните причини

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

Сървърът връща празно тяло на отговора без HTTP статусен ред. Това е най-честият тригер. Apache или Nginx може да се срине по средата на отговора, оставяйки Cloudflare с отворен TCP сокет без пристигащи данни.

Защитна стена или софтуер за сигурност блокира IP диапазоните на Cloudflare. Инструменти като ModSecurity, Fail2Ban, CSF (ConfigServer Security & Firewall) или плъгини на ниво приложение като Wordfence могат безшумно да отхвърлят пакети от изходните IP адреси на Cloudflare, причинявайки нулиране на връзката без правилен HTTP отговор.

Несъответствие в SSL/TLS ръкостискането между Cloudflare и сървъра. Ако Cloudflare е настроен на режим "Full (Strict)", но вашият сървър има изтекъл, самоподписан или неправилно конфигуриран сертификат, TLS договарянето се проваля преди да бъдат обменени каквито и да е HTTP данни.

Деформирани или прекалено големи HTTP заглавия на отговора. Cloudflare налага твърдо ограничение от 32 KB за заглавията на отговора. Всяко отделно заглавие или комбиниран набор от заглавия, надвишаващ това ограничение, причинява 520. Това е честен граничен случай при лошо написани PHP приложения, които изхвърлят големи данни за сесии или изход за отстраняване на грешки в заглавията.

Срив на процеса на сървъра или OOM (Out-of-Memory) убиване. Ако работният процес на уеб сървъра (напр. работник на Nginx или PHP-FPM пул) бъде убит от Linux OOM killer по средата на заявка, връзката се прекъсва рязко.

Изключения на ниво приложение преди изпращане на заглавията. Фатална PHP грешка, необработено Python изключение или срив на Node.js, настъпил преди извикването на res.writeHead(), води до празен отговор, който Cloudflare не може да анализира.

Нулиране на връзката от сървъра (TCP RST). Сървърът активно нулира TCP връзката, което Cloudflare интерпретира като неизвестен отговор.

Грешка 520 срещу други Cloudflare 5xx грешки

Разграничаването на 520 от подобни грешки на Cloudflare предотвратява загуба на диагностични усилия.

Ако виждате 521, вашият уеб сървърен процес не работи. Ако виждате 524, вашето приложение работи, но е твърде бавно. Ако виждате 520, сървърът работи и отговаря — но изпращаното обратно е повредено.

Стъпка по стъпка поправка на грешка 520

Стъпка 1: Проверете здравето и свързаността на сървъра

Преди да докоснете Cloudflare, потвърдете, че сървърът е жив и демонът на уеб сървъра работи.

Проверете дали процесът на уеб сървъра е активен:

# For Nginx
sudo systemctl status nginx

# For Apache
sudo systemctl status apache2

# For LiteSpeed
sudo systemctl status lsws

Тествайте директна свързаност до IP на сървъра, заобикаляйки прокси на Cloudflare. Извлечете вашия IP на сървъра от DNS таблото на Cloudflare, след което го тествайте директно:

curl -I --resolve yourdomain.com:80:YOUR_ORIGIN_IP http://yourdomain.com/
curl -I --resolve yourdomain.com:443:YOUR_ORIGIN_IP https://yourdomain.com/

Ако curl върне валиден HTTP статус (200, 301 и т.н.), сървърът е функционален и проблемът е в комуникационния слой между Cloudflare и сървъра. Ако curl върне празен отговор или нулиране на връзката, проблемът е от страната на сървъра.

Проверете натиска върху системните ресурси:

# Memory usage
free -h

# CPU load
uptime

# Check for OOM kills in the last boot
dmesg | grep -i "oom|killed process"

# Check for PHP-FPM pool exhaustion
sudo systemctl status php8.1-fpm

Стъпка 2: Прегледайте журналите за грешки на сървъра

Журналите на сървъра са единственият най-ценен диагностичен източник. Не пропускайте тази стъпка.

За Nginx:

sudo tail -n 100 /var/log/nginx/error.log
sudo tail -n 100 /var/log/nginx/access.log

За Apache:

sudo tail -n 100 /var/log/apache2/error.log
sudo tail -n 100 /var/log/apache2/access.log

Търсете специално за:

• Записи на ниво [crit] или [emerg]

upstream prematurely closed connection (Nginx + PHP-FPM)
Premature end of script headers (Apache + CGI/PHP)
worker_connections are not enough (достигнат лимит на работниците на Nginx)
PHP фатални грешки, записани в журнала за грешки на уеб сървъра

Кръстосано препратете времевите марки на журнала с момента на възникване на грешките 520. Таблото на Cloudflare под Analytics > Traffic показва времевите марки на пиковете на 520, които можете да използвате за корелация.
Стъпка 3: Добавете IP диапазоните на Cloudflare в белия списък на вашата защитна стена
Ако защитна стена блокира изходните IP адреси на Cloudflare, връзката ще бъде нулирана безшумно. Cloudflare публикува своите текущи IP диапазони на https://www.cloudflare.com/ips/.
За UFW (Ubuntu/Debian):
# Download Cloudflare IPv4 ranges and whitelist them
for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
  sudo ufw allow from $ip to any port 80,443 proto tcp
done

# Repeat for IPv6
for ip in $(curl -s https://www.cloudflare.com/ips-v6); do
  sudo ufw allow from $ip to any port 80,443 proto tcp
done

sudo ufw reload
За CSF (ConfigServer Firewall):
Добавете IP диапазоните на Cloudflare към /etc/csf/csf.allow, след което рестартирайте CSF:
sudo csf -r
За ModSecurity: Ако подозирате, че ModSecurity е виновникът, проверете неговия одитен журнал:
sudo tail -n 200 /var/log/modsec_audit.log
Търсете съвпадения на правила срещу IP адресите на Cloudflare. Можете да добавите IP адресите на Cloudflare в белия списък в конфигурацията на ModSecurity или да зададете директивата SecRemoteRules за изключването им.
Критична бележка: Никога не деактивирайте постоянно вашата защитна стена или ModSecurity. Добавяйте в белия списък само публикуваните IP диапазони на Cloudflare и незабавно активирайте отново всички контроли за сигурност след тестване.
Стъпка 4: Одитирайте и поправете HTTP заглавията на отговора
Деформираните или прекалено големи заглавия са честопренебрегвана причина за грешки 520. Използвайте curl с подробен изход, за да проверите точно какво изпраща вашият сървър:
curl -v --resolve yourdomain.com:443:YOUR_ORIGIN_IP https://yourdomain.com/ 2>&1 | head -80
Внимавайте за:

Заглавия с не-ASCII символи или управляващи символи
Заглавия Set-Cookie с изключително дълги стойности (честа при неправилни конфигурации на PHP сесии)
Липсващи или деформирани заглавия Content-Type

• Дублирани заглавия Content-Length с конфликтни стойности

Ако използвате PHP приложение, проверете php.ini за настройките output_buffering. Деактивиран изходен буфер в комбинация с фатална грешка по средата на отговора може да причини частично предаване на заглавия.

Специално за WordPress сайтове: Плъгини, които инжектират големи количества данни в HTTP заглавията (някои плъгини за сигурност или кеширане правят това), могат да натиснат размера на заглавията над ограничението от 32 KB на Cloudflare. Одитирайте активните плъгини и тествайте в безопасен режим.

Стъпка 5: Валидирайте конфигурацията на SSL/TLS в Cloudflare

Несъответствие в SSL между Cloudflare и сървъра е честа причина за повреди от клас 520, която се маскира като обща неизвестна грешка.

Навигирайте до Cloudflare Dashboard > SSL/TLS > Overview и проверете режима на криптиране:

Ако вашият сървър използва самоподписан сертификат и Cloudflare е настроен на Full (Strict), TLS ръкостискането ще се провали. Или инсталирайте валиден сертификат на сървъра (безплатен Let's Encrypt сертификат работи) или превключете временно на режим Full, докато поправите сертификата.

Ако имате нужда от правилно доверен сертификат за вашия сървър, SSL сертификати от доверен CA напълно елиминират проблема със самоподписания сертификат и са съвместими с режима Full (Strict) на Cloudflare.

Стъпка 6: Поставете на пауза Cloudflare прокси за целенасочена диагностика

Временното премахване на Cloudflare от пътя на заявката изолира дали проблемът е в конфигурацията на Cloudflare или на сървъра.

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

В DNS таблото на Cloudflare, кликнете върху иконата на оранжевия облак до вашия A или CNAME запис, за да го направите сив. Това заобикаля прокси на Cloudflare, като запазва DNS разрешаването чрез Cloudflare. DNS разпространението отнема до 5 минути.

Метод 2: Поставете Cloudflare на пауза глобално за домейна

Навигирайте до Cloudflare Dashboard > Overview > Advanced Actions > Pause Cloudflare on Site. Това насочва целия трафик директно към вашия сървър.

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

Активирайте отново Cloudflare незабавно след тестване — поставен на пауза Cloudflare означава, че вашият сайт губи DDoS защита, CDN кеширане и WAF покритие.

Стъпка 7: Проверете точността на DNS записите

Неправилно конфигуриран DNS A запис, сочещ към грешен или остарял IP адрес, кара Cloudflare да проксира трафика към грешния сървър, който ще върне неочакван отговор.

В DNS таблото на Cloudflare:

• Проверете, че A записът за вашия основен домейн (@) сочи към текущия IP на вашия сървър
• Проверете, че CNAME за www се разрешава правилно
• Ако наскоро сте мигрирали сървъри, потвърдете, че старият IP вече не е посочен никъде

Потвърдете към кой IP Cloudflare всъщност изпраща трафик:

dig +short yourdomain.com @1.1.1.1

Сравнете това с действителния IP на вашия сървър. Ако се различават, актуализирайте DNS записа в Cloudflare.

Стъпка 8: Мащабирайте ресурсите на сървъра

Ако вашият сървър е постоянно под голямо натоварване, грешките 520 ще се появяват периодично по време на пикове на трафика, тъй като работните процеси се изчерпват и връзките се прекъсват.

Диагностицирайте изчерпването на ресурсите:

# Check Nginx worker connections
sudo nginx -T | grep worker_connections

# Check PHP-FPM pool limits
cat /etc/php/8.1/fpm/pool.d/www.conf | grep -E "pm.|max_children"

# Monitor real-time connections
ss -s

Опции за настройка без хардуерен ъпгрейд:

• Увеличете worker_connections в /etc/nginx/nginx.conf
• Увеличете pm.max_children в конфигурацията на PHP-FPM пула
• Активирайте директивата keepalive на Nginx за upstream връзки
• Внедрете обектно кеширане (Redis или Memcached) за намаляване на натиска върху базата данни
• Активирайте правилото на страницата Cache Everything на Cloudflare за разтоварване на доставката на статични активи

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

Ако вашето приложение обработва изчислително интензивни натоварвания (ML инференция, обработка на видео, операции с големи набори от данни), които причиняват периодични сривове на работниците, GPU хостингът разтоварва тези задачи от процесите на вашия уеб сървър, елиминирайки честа причина за сривове по средата на отговора.

Стъпка 9: Прегледайте правилата на защитната стена и сигурността на Cloudflare

Собствените функции за сигурност на Cloudflare понякога могат да пречат на легитимната комуникация със сървъра, особено ако персонализираните правила на защитната стена или WAF правилата са неправилно конфигурирани.

Проверете Cloudflare Dashboard > Security > WAF > Custom Rules за правила, които могат да прихващат заявки преди да достигнат до сървъра. Прегледайте също Security > Settings > Browser Integrity Check — в редки случаи това може да причини неочаквано поведение с определени потребителски агенти или автоматизирани заявки.

Прегледайте журнала Security > Events, за да видите дали Cloudflare блокира или оспорва заявки, които трябва да достигат до вашия сървър.

Стъпка 10: Ескалирайте към вашия хостинг доставчик или поддръжката на Cloudflare

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

При контакт с вашия хостинг доставчик, предоставете:

• Точните времеви марки на появата на 520 (от Cloudflare Analytics)
• Съответните откъси от журнала за грешки на вашия уеб сървър
• Изхода от curl -v срещу вашия IP на сървъра
• Текущите метрики за използване на ресурсите (CPU, RAM, брой връзки)

Доставчиците, управляващи управлявана инфраструктура на Dedicated сървъри, могат да извършват диагностика на ниво ядро, улавяне на пакети (tcpdump) и инспекция на ниво сокет, които не са налични в споделени среди.

При контакт с поддръжката на Cloudflare, включете:

• Вашия Ray ID от страницата с грешка 520 (видим в HTML на грешката на Cloudflare)
• HAR файл, уловен от Chrome DevTools по време на грешката
• Вашия текущ SSL/TLS режим и всякакви персонализирани правила на защитната стена

Ray ID е критичен — той позволява на инженерите на Cloudflare да извлекат точния запис в журнала на граничния възел за вашата неуспешна заявка.

Разширена диагностика: Улавяне на точната повреда с tcpdump

За постоянни или периодични грешки 520, които устояват на стандартното отстраняване на проблеми, улавянето на пакети на сървъра разкрива точно какво се случва на TCP/HTTP слоя, когато Cloudflare се свързва.

# Capture traffic from Cloudflare IPs on port 443
sudo tcpdump -i eth0 -w /tmp/cloudflare_capture.pcap 'src net 103.21.244.0/22 or src net 103.22.200.0/22 or src net 103.31.4.0/22 or src net 104.16.0.0/13 or src net 104.24.0.0/14' and port 443

Отворете получения файл .pcap в Wireshark и филтрирайте за tcp.flags.reset == 1, за да идентифицирате TCP RST пакети, което указва, че сървърът активно нулира връзките. Филтрирайте за http, за да проверите частичните HTTP отговори, които се изпращат.

Това ниво на анализ окончателно идентифицира дали 520 е причинена от RST на защитна стена, срив на приложение по средата на отговора или TLS повреда.

Предотвратяване на грешка 520: Проактивни мерки

Реактивното отстраняване на проблеми е скъпо. Тези мерки значително намаляват вероятността от появата на 520.

Внедрете проверки за здраве на Cloudflare. Под Traffic > Health Checks, конфигурирайте проверка за здраве срещу вашия сървър. Cloudflare ще ви предупреди, преди потребителите да започнат да виждат грешки 520.

Активирайте функцията Always Online на Cloudflare (под Caching > Configuration). Въпреки че не поправя основния проблем, тя обслужва кешираните версии на вашите страници на потребителите по време на прекъсвания на сървъра, предотвратявайки пълно прекъсване на услугата.

Настройте мониторинг на сървъра с инструменти като UptimeRobot, Pingdom или самостоятелно хоствано решение като Uptime Kuma. Наблюдавайте IP на сървъра директно (не домейна, проксиран от Cloudflare), за да откривате повреди на сървъра независимо от Cloudflare.

Автоматизирайте добавянето в белия списък на IP адресите на Cloudflare. IP диапазоните на Cloudflare се променят понякога. Използвайте cron задача за обновяване на белия списък на вашата защитна стена:

# /etc/cron.weekly/update-cloudflare-ips
#!/bin/bash
CF_IPS=$(curl -s https://www.cloudflare.com/ips-v4)
# Add logic to update UFW/CSF/iptables rules

Използвайте Authenticated Origin Pulls на Cloudflare. Тази функция конфигурира вашия сървър да приема само HTTPS връзки, представящи клиентския сертификат на Cloudflare, блокирайки всякакви директни към сървъра заявки, заобикалящи прокси. Това също елиминира клас грешки 520, причинени от не-Cloudflare трафик, достигащ до вашия сървър и задействащ отговори на софтуера за сигурност.

За екипи, управляващи множество домейни и уеб приложения, VPS с cPanel осигурява централизиран достъп до журнали, управление на защитна стена и управление на SSL сертификати за всички хоствани домейни — значително намалявайки времето за диагностика при събития 520.

Матрица за решения: Диагностициране на вашия конкретен сценарий с 520

Технически контролен списък с ключови изводи

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

• Проверихте, че процесът на уеб сървъра работи (systemctl status)
• Тествахте директна свързаност към сървъра с curl -v --resolve, заобикаляйки Cloudflare
• Прегледахте журналите за грешки на сървъра за точните времеви марки на събитията 520
• Потвърдихте, че IP диапазоните на Cloudflare са в белия списък на всички активни защитни стени (UFW, CSF, iptables, ModSecurity)
• Валидирахте, че заглавията на отговора са под 32 KB и не съдържат деформирани стойности
• Потвърдихте, че SSL/TLS режимът на Cloudflare съответства на типа сертификат на сървъра
• Проверихте, че DNS A записите сочат към правилния, текущ IP на сървъра
• Проверихте системната памет и CPU за OOM убивания или изчерпване на ресурсите
• Уловихте Ray ID от страницата с грешка 520 за ескалация към поддръжката на Cloudflare
• Прегледахте журнала за събития на сигурността на Cloudflare за намеса на WAF правила

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

Каква е разликата между Cloudflare грешка 520 и грешка 521?

Грешка 521 означава, че Cloudflare успешно е достигнал до IP на вашия сървър, но процесът на уеб сървъра е отказал TCP връзката — обикновено защото Nginx или Apache не работи. Грешка 520 означава, че TCP връзката е установена, но HTTP отговорът е бил празен, съкратен или деформиран. Ако виждате 521, стартирайте вашия уеб сървър. Ако виждате 520, сървърът работи, но изпраща повредени отговори.

Може ли грешка 520 да бъде причинена от самия Cloudflare, а не от сървъра?

Рядко, но да. Проблеми с граничния възел на Cloudflare могат да причинят грешки 520, които не се възпроизвеждат при директен достъп до сървъра. Проверете cloudflarestatus.com за активни инциденти. Ако сървърът отговаря правилно чрез директен curl и страницата за статус на Cloudflare показва активен инцидент, изчакайте Cloudflare да го разреши, вместо да правите промени на вашия сървър.

Защо грешка 520 се появява само периодично, а не постоянно?

Периодичните грешки 520 почти винаги указват изчерпване на ресурсите — PHP-FPM работните пулове изчерпват наличните деца, Nginx достига лимитите worker_connections, или Linux OOM killer прекратява процеси под натиск на паметта. Тези условия се появяват при пикове на натоварването и се разрешават, когато трафикът намалее, създавайки периодичния модел. Постоянните грешки 520 сочат към проблем с конфигурацията.

Поставянето на Cloudflare на пауза поправя ли грешка 520?

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

Как да намеря Ray ID, за да докладвам грешка 520 на Cloudflare?

Ray ID се показва в долната част на страницата с грешка 520 на Cloudflare, показана на потребителите. Изглежда като 16-символен шестнадесетичен низ (напр. 7a3f2b9c1d4e8f0a). Можете също да го намерите в заглавието на отговора CF-Ray, видимо в Chrome DevTools под раздела Network. Винаги включвайте този ID при отваряне на тикет за поддръжка на Cloudflare — той позволява на инженерите на Cloudflare да извлекат точния запис в граничния журнал за вашата неуспешна заявка.