Як виправити помилку Cloudflare 520: Повний посібник з діагностики та вирішення

Cloudflare Error 520 — це HTTP-код статусу, який повертається, коли гранична мережа Cloudflare отримує порожню, неочікувану або іншим чином неінтерпретовану відповідь від вашого сервера-джерела. На відміну від 502 або 504, які вказують на тайм-аут шлюзу або несправний шлюз, 520 — це загальний код Cloudflare для відповідей, що виходять за межі будь-якої визнаної специфікації HTTP, тобто сервер-джерело технічно відповів, але те, що він надіслав, було недійсним, усіченим або структурно деформованим.

З практичної точки зору, Error 520 означає, що TCP-з’єднання між Cloudflare та вашим сервером-джерелом було встановлено, але рукостискання на рівні HTTP зазнало збою. Користувач бачить сторінку помилки у стилі Cloudflare з повідомленням "Web server is returning an unknown error" — і ваш сайт фактично недоступний для нього.

Що спричиняє Error 520: пояснення першопричин

Розуміння точного режиму збою є необхідним перед тим, як торкатися будь-якої конфігурації. Error 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 КБ на заголовки відповіді. Будь-який окремий заголовок або сукупний набір заголовків, що перевищує цей ліміт, спричиняє 520. Це поширений граничний випадок із погано написаними PHP-застосунками, які записують великі дані сесій або налагоджувальний вивід у заголовки.

Аварійне завершення процесу сервера-джерела або вбивство OOM (Out-of-Memory). Якщо робочий процес веб-сервера (наприклад, Nginx worker або пул PHP-FPM) вбивається Linux OOM killer під час запиту, з’єднання різко обривається.

Винятки на рівні застосунку до надсилання заголовків. Фатальна помилка PHP, необроблений виняток Python або збій Node.js, що виникають до виклику res.writeHead(), призводять до порожньої відповіді, яку Cloudflare не може розібрати.

Скидання з’єднання джерелом (TCP RST). Сервер-джерело активно скидає TCP-з’єднання, що Cloudflare інтерпретує як невідому відповідь.

Error 520 порівняно з іншими помилками Cloudflare 5xx

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

Якщо ви бачите 521, ваш процес веб-сервера не запущено. Якщо ви бачите 524, ваш застосунок працює, але надто повільно. Якщо ви бачите 520, сервер працює та відповідає — але те, що він надсилає, є пошкодженим.

Покрокове виправлення Error 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 worker)
Фатальні помилки 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-відповіді
Деформовані або надмірно великі заголовки є часто overlooked причиною помилок 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-заголовки (деякі плагіни безпеки або кешування роблять це), можуть перевищити ліміт Cloudflare у 32 КБ. Перевірте активні плагіни та протестуйте в безпечному режимі.

Крок 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) для зменшення навантаження на базу даних
• Увімкніть правило сторінки Cloudflare Cache Everything для розвантаження доставки статичних ресурсів

Для застосунків, що переросли спільну інфраструктуру, міграція на середовище VPS Хостингу надає повний контроль над лімітами робочих процесів, розподілом пам’яті та налаштуванням TCP на рівні ядра — нічого з цього недоступно на спільних планах.

Якщо ваш застосунок обробляє обчислювально інтенсивні навантаження (ML-інференція, обробка відео, операції з великими наборами даних), що спричиняють переривчасті збої worker, GPU Хостинг розвантажує ці завдання від процесів вашого веб-сервера, усуваючи поширене джерело збоїв у середині відповіді.

Крок 9: Перегляньте правила брандмауера та безпеки Cloudflare

Власні функції безпеки Cloudflare іноді можуть заважати легітимній комунікації з джерелом, особливо якщо власні правила брандмауера або WAF налаштовані неправильно.

Перевірте Cloudflare Dashboard > Security > WAF > Custom Rules на наявність правил, які можуть перехоплювати запити до того, як вони досягнуть джерела. Також перегляньте Security > Settings > Browser Integrity Check — у рідкісних випадках це може спричиняти неочікувану поведінку з певними user agent або автоматизованими запитами.

Перегляньте журнал Security > Events, щоб перевірити, чи Cloudflare блокує або оскаржує запити, які мають досягати вашого джерела.

Крок 10: Зверніться до вашого хостинг-провайдера або підтримки Cloudflare

Якщо всі вищезазначені кроки вичерпано без вирішення, ескалюйте з точною інформацією.

При зверненні до вашого хостинг-провайдера надайте:

• Точні часові мітки виникнення 520 (з Cloudflare Analytics)
• Відповідні витяги з журналу помилок вашого веб-сервера
• Вивід curl -v проти IP вашого джерела
• Поточні метрики використання ресурсів (CPU, RAM, кількість з’єднань)

Провайдери, що керують інфраструктурою на Виділених серверах, можуть виконувати діагностику на рівні ядра, захоплення пакетів (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.

Запобігання Error 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

Використовуйте автентифіковані вихідні з’єднання Cloudflare. Ця функція налаштовує ваше джерело приймати лише HTTPS-з’єднання, що надають клієнтський сертифікат Cloudflare, блокуючи будь-які прямі запити до джерела, що обходять проксі. Це також усуває клас помилок 520, спричинених трафіком не від Cloudflare, що потрапляє на ваше джерело та викликає відповіді програмного забезпечення безпеки.

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

Матриця рішень: діагностика вашого конкретного сценарію 520

Технічний контрольний список ключових висновків

Перш ніж ескалювати до підтримки, підтвердіть, що ви виконали кожен із наступних пунктів:

• Перевірено, що процес веб-сервера джерела запущено (systemctl status)
• Протестовано пряме підключення до джерела за допомогою curl -v --resolve в обхід Cloudflare
• Переглянуто журнали помилок джерела для точних часових міток подій 520
• Підтверджено, що діапазони IP Cloudflare внесено до білого списку у всіх активних брандмауерах (UFW, CSF, iptables, ModSecurity)
• Перевірено, що заголовки відповіді не перевищують 32 КБ і не містять деформованих значень
• Підтверджено, що режим SSL/TLS Cloudflare відповідає типу сертифіката джерела
• Перевірено, що DNS A-записи вказують на правильний, поточний IP джерела
• Перевірено системну пам’ять та CPU на наявність вбивств OOM або вичерпання ресурсів
• Захоплено Ray ID зі сторінки помилки 520 для ескалації до підтримки Cloudflare
• Переглянуто журнал подій безпеки Cloudflare на наявність втручання правил WAF

Часті запитання

У чому різниця між Cloudflare Error 520 та Error 521?

Error 521 означає, що Cloudflare успішно досяг IP вашого сервера-джерела, але процес веб-сервера відхилив TCP-з’єднання — зазвичай тому, що Nginx або Apache не запущено. Error 520 означає, що TCP-з’єднання було встановлено, але HTTP-відповідь була порожньою, усіченою або деформованою. Якщо ви бачите 521, запустіть ваш веб-сервер. Якщо ви бачите 520, сервер працює, але надсилає пошкоджені відповіді.

Чи може Error 520 бути спричинений самим Cloudflare, а не сервером-джерелом?

Рідко, але так. Проблеми з граничними вузлами Cloudflare можуть спричиняти помилки 520, які не відтворюються при прямому доступі до джерела. Перевірте cloudflarestatus.com на наявність активних інцидентів. Якщо джерело відповідає коректно через прямий curl і сторінка статусу Cloudflare показує активний інцидент, зачекайте, поки Cloudflare вирішить його, замість того щоб вносити зміни до вашого сервера.

Чому Error 520 виникає лише переривчасто, а не постійно?

Переривчасті помилки 520 майже завжди вказують на вичерпання ресурсів — пули PHP-FPM worker вичерпують доступних дочірніх процесів, Nginx досягає лімітів worker_connections, або Linux OOM killer завершує процеси під тиском пам’яті. Ці умови виникають під час піків навантаження та вирішуються, коли трафік спадає, створюючи переривчастий характер. Постійні помилки 520 вказують на проблему конфігурації.

Чи виправляє Error 520 призупинення Cloudflare?

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

Як знайти Ray ID для повідомлення про помилку 520 до Cloudflare?

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