Как исправить ошибку 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 или пул 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)
Фатальные ошибки 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-заголовки (некоторые плагины безопасности или кэширования делают это), могут превысить лимит Cloudflare в 32 КБ. Проверьте активные плагины и протестируйте в безопасном режиме.

Шаг 5: Проверка конфигурации SSL/TLS в Cloudflare

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

Перейдите в Cloudflare Dashboard > SSL/TLS > Overview и проверьте режим шифрования:

Если ваш исходный сервер использует самоподписанный сертификат, а Cloudflare настроен на режим Full (Strict), TLS-рукопожатие завершится неудачей. Либо установите действительный сертификат на исходном сервере (подойдёт бесплатный сертификат Let’s Encrypt), либо временно переключитесь в режим Full, пока вы исправляете сертификат.

Если вам нужен надлежащим образом доверенный сертификат для вашего исходного сервера, SSL-сертификаты от доверенного центра сертификации полностью устраняют проблему самоподписанных сертификатов и совместимы с режимом 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 для соединений с вышестоящим сервером
• Реализуйте кэширование объектов (Redis или Memcached) для снижения нагрузки на базу данных
• Включите правило страницы Cloudflare Cache Everything для разгрузки доставки статических ресурсов

Для приложений, переросших общую инфраструктуру, переход на 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, количество соединений)

Провайдеры, работающие на управляемой инфраструктуре на выделенных серверах, могут выполнять диагностику на уровне ядра, захват пакетов (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 сбросом соединения брандмауэром, аварийным завершением приложения в середине ответа или сбоем 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 (Authenticated Origin Pulls). Эта функция настраивает ваш исходный сервер на приём только 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?

Ошибка 521 означает, что Cloudflare успешно достиг IP-адреса вашего исходного сервера, но процесс веб-сервера отклонил TCP-соединение — как правило, потому что Nginx или Apache не запущен. Ошибка 520 означает, что TCP-соединение было установлено, но HTTP-ответ был пустым, усечённым или некорректным. Если вы видите ошибку 521, запустите ваш веб-сервер. Если вы видите ошибку 520, сервер работает, но отправляет некорректные ответы.

Может ли Error 520 быть вызвана самим Cloudflare, а не исходным сервером?

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

Почему Error 520 возникает только периодически, а не постоянно?

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

Устраняет ли приостановка Cloudflare Error 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 получить точную запись журнала граничного узла для вашего неудавшегося запроса.