Ошибка 520 Cloudflare выглядит пугающе: сайт вроде бы подключен к CDN, домен открывается, но вместо страницы посетитель видит сообщение о неизвестной ошибке веб-сервера. Для владельца это неприятная ситуация, потому что причина не всегда лежит на поверхности. Сервер может быть жив, DNS может отвечать правильно, а отдельные страницы или запросы все равно будут отдавать 520.
Разберем, что означает эта ошибка, чем она отличается от похожих 5xx-ошибок, какие проверки стоит сделать в первую очередь и как настроить мониторинг, чтобы узнать о проблеме раньше клиентов.
Что означает ошибка 520 Cloudflare
Ошибка 520 появляется, когда Cloudflare обращается к исходному серверу сайта, но получает от него пустой, неизвестный или некорректный ответ. Это не обычный код HTTP, который приложение осознанно вернуло пользователю, а сигнал от прокси: между посетителем и сайтом есть Cloudflare, и на участке до origin-сервера что-то пошло не так.
Важный практический вывод: 520 не всегда означает, что сервер полностью выключен. Сервер может принимать соединения, но обрывать их, падать на конкретном скрипте, отдавать неполные заголовки, конфликтовать с настройками HTTP/2 или блокировать часть запросов от Cloudflare. Поэтому простой ответ «сайт упал» здесь слишком грубый.
Чем 520 отличается от 502, 521 и 522
Похожие ошибки часто путают, но для диагностики разница важна:
- 502 обычно говорит о проблеме шлюза или некорректном ответе от вышестоящего сервера;
- 521 чаще связан с отказом origin-сервера принимать соединение от Cloudflare;
- 522 указывает на таймаут соединения между Cloudflare и origin;
- 520 означает неизвестный или неожиданный ответ, который Cloudflare не смог нормально обработать.
Если на сайте уже используются CDN, прокси, балансировщик или отдельный сервер приложений, ошибка может возникать на любом звене этой цепочки. Поэтому проверять нужно не только CMS, но и веб-сервер, PHP-FPM или другой runtime, firewall, прокси и правила безопасности.
Частые причины ошибки 520
Приложение падает до нормального ответа
Типичный пример: после обновления модуля в CMS часть страниц начинает вызывать фатальную ошибку. Браузер пользователя не видит текст ошибки, потому что Cloudflare получает обрыв или пустой ответ и показывает 520. На главной странице все может работать, а карточка товара, корзина или форма заказа ломаются.
Что проверить:
- логи приложения в момент ошибки;
- error log веб-сервера;
- логи PHP-FPM, Node.js, Python, Ruby или другого runtime;
- последние изменения в плагинах, шаблоне, интеграциях и правилах кеширования.
Firewall или модуль безопасности блокирует Cloudflare
Если сервер или хостинг принимает Cloudflare за подозрительный источник, он может закрывать соединение или отдавать некорректный ответ. Такое бывает после установки защитного плагина, изменения правил WAF, включения фильтрации по IP или слишком жестких лимитов на частые запросы.
Практический признак: у части пользователей сайт открывается, а у части появляется 520; ошибка может усиливаться на популярных страницах или при активной рекламной кампании. Нужно убедиться, что Cloudflare не блокируется на уровне firewall, панели хостинга, .htaccess, nginx, fail2ban или стороннего WAF.
Слишком большие или некорректные заголовки
Некоторые сайты накапливают много cookie, служебных заголовков, debug-данных или параметров A/B-тестов. В обычном браузере проблема может проявляться не сразу, но прокси получает ответ, который не укладывается в ожидаемый формат. В результате пользователь видит 520 вместо страницы.
Проверьте, не раздувает ли сайт Set-Cookie, нет ли в ответе лишних отладочных заголовков, не дублируются ли cookies после редиректов и авторизации. Особенно внимательно стоит смотреть личные кабинеты, корзины, страницы оплаты и формы, где заголовков обычно больше.
Неверная настройка HTTP/2 или прокси
Если Cloudflare соединяется с origin по протоколу, который сервер объявляет, но фактически поддерживает неправильно, соединение может завершаться нестабильно. Снаружи это выглядит как случайная ошибка: то страница открывается, то возвращается 520.
Здесь важно не менять все настройки подряд. Лучше безопасно сравнить поведение через Cloudflare и напрямую к origin и проверить конфигурацию nginx или Apache. Не отключайте защиту и не исключайте прокси-слой в рабочей схеме без согласованного плана проверки и отката.
Как проверить ошибку 520 вручную
Начните с фиксации фактов. Нужны не общие слова «сайт не работает», а конкретика: URL, время, часовой пояс, скриншот ошибки, Ray ID на странице Cloudflare, действия пользователя перед ошибкой и список затронутых страниц.
Шаг 1. Проверьте разные URL
Откройте главную страницу, карточку товара, страницу авторизации, корзину, форму заявки и несколько статических файлов. Если 520 появляется только на одном типе страниц, проблема чаще связана с приложением или конкретным обработчиком. Если ошибка возникает на всем сайте, вероятнее общая проблема origin-сервера, firewall или прокси.
Шаг 2. Сравните ответ через Cloudflare и напрямую
Если вы администрируете origin и прямой доступ разрешён вашей схемой, сравните один безопасный публичный GET-адрес по HTTPS с сохранением hostname и SNI:
curl --proto "=https" --connect-timeout 5 --max-time 20 --resolve example.com:443:203.0.113.10 -sS -o /dev/null -w "HTTP=%{http_code} total=%{time_total}\n" https://example.com/Домен и IP — примеры: подставьте свой hostname и известный вам адрес origin, не публикуйте его. Команда не следует редиректам и не отключает проверку сертификата. Она не создаёт заказов и не передаёт Cookie или Authorization; перед запуском подтвердите, что выбранный GET не меняет данные. Для сравнения через CDN выполните тот же запрос без --resolve.
Отказ прямого подключения не доказывает поломку origin: доступ может быть разрешён только Cloudflare, а сертификат origin — доверен CDN, но не обычному curl. Не используйте -k и не ослабляйте firewall ради теста; при таком ограничении сопоставляйте логи и диагностику провайдера. Успешный прямой ответ тоже не исключает ошибок на маршруте Cloudflare—origin или при другом методе, сессии и нагрузке.
Шаг 3. Посмотрите логи за точное время ошибки
Ищите записи не за весь день, а рядом с конкретным временем сбоя. Полезны такие признаки:
- аварийное завершение процесса;
- пустой ответ от backend;
- ошибки upstream;
- превышение лимитов памяти или времени выполнения;
- блокировка IP или User-Agent;
- ошибки TLS или HTTP/2 на origin.
Если логов нет, это тоже диагностический сигнал. Возможно, запрос не доходит до приложения и обрывается раньше: на firewall, балансировщике, reverse proxy или уровне хостинга.
Что делать владельцу сайта
Сначала уберите риск для пользователей. Если ошибка затрагивает форму заказа, оплату, регистрацию или заявку, временно остановите рекламу на проблемные страницы и покажите альтернативный способ связи. Затем переходите к технической диагностике.
Практический порядок действий:
- Сохраните URL, время, Ray ID и скриншот ошибки.
- Проверьте, массовая проблема или ломается один раздел.
- Посмотрите логи приложения и веб-сервера за точное время.
- Проверьте firewall, WAF, правила безопасности и блокировки Cloudflare.
- Оцените размер и корректность HTTP-заголовков.
- Проверьте настройки HTTP/2, reverse proxy и балансировщика.
- После исправления проверьте не только главную страницу, но и ключевые пользовательские сценарии.
Если нужна не только фиксация ошибки, но и разбор причины, можно оставить заявку на профессиональную поддержку через форму Web-Puls или воспользоваться контактной информацией. Это уместно, когда ошибка связана с сервером, CDN, firewall, хостингом или нестабильной работой приложения.
Почему одной ручной проверки недостаточно
Ошибка 520 может быть кратковременной. Владелец откроет сайт через час и увидит нормальную страницу, хотя часть клиентов уже успела столкнуться с проблемой. Еще сложнее, если ошибка появляется только на отдельных URL, только под нагрузкой или только из некоторых сетей.
Ручная проверка помогает разобраться после жалобы, но плохо подходит для раннего обнаружения. Для сайта важнее знать момент начала сбоя, частоту повторений, затронутые страницы и статус ответа. Это дает основу для разговора с хостингом, разработчиком или администратором сервера.
Web-Puls помогает регулярно проверять доступность сайта и быстрее узнавать, если он перестал открываться или начал отдавать ошибку вместо рабочей страницы. Для первичной проверки можно использовать проверку сайта онлайн, а для постоянного контроля лучше настроить автоматический мониторинг важных URL.
Что мониторить, если сайт работает через Cloudflare
Не ограничивайтесь главной страницей. Она может быть закеширована и открываться, пока динамические разделы уже сломаны. Для сайта на CDN полезно проверять несколько точек:
- главную страницу;
- страницу каталога или услуги;
- карточку товара или важную посадочную страницу;
- форму заявки;
- страницу авторизации;
- простой статический файл;
- страницу, которая не должна отдаваться из кеша.
Для каждой точки важен не только факт открытия, но и код ответа. При 520, 502, 503 или таймауте регулярная проверка может дать сигнал после подтверждения сбоя; время обнаружения зависит от интервала и правил уведомления.
Пример для интернет-магазина
Главная страница магазина открывается, потому что она лежит в кеше Cloudflare. Посетитель переходит в корзину, а корзина обращается к backend и получает 520. Владелец проверяет сайт с телефона, видит главную страницу и считает, что все в порядке. На деле заказы не проходят.
Чтобы заметить отказ отдельных страниц, мониторьте не только домен, но и безопасные публичные URL каталога, карточки, пустой корзины, формы либо специально подготовленного health endpoint. Их успешный ответ не подтверждает оформление заказа: полный путь требует отдельного безопасного функционального теста.
Пример для сайта услуг
После обновления формы обратной связи PHP-процесс падает только при отправке определенного набора полей. Ни проверка главной, ни GET страницы формы не обязаны обнаружить такой сбой. Нужны логи обработчика и отдельный тест отправки в изолированном контуре, без реальных заявок и писем клиентам. Мониторинг URL здесь подтверждает только доступность страницы формы.
Вывод
Ошибка 520 Cloudflare означает, что проблема не сводится к простому «сервер выключен». Cloudflare смог обратиться к origin, но получил ответ, который не получилось нормально обработать. Поэтому проверять нужно цепочку целиком: приложение, веб-сервер, firewall, заголовки, HTTP/2, прокси и логи за точное время ошибки.
Для владельца сайта главное — быстро понять масштаб: сломана одна страница или весь сайт, видят ли ошибку клиенты, повторяется ли она после исправления. Ручная диагностика помогает найти причину, а автоматический мониторинг снижает шанс узнать о 520 только из жалоб пользователей.