Ошибки Cloudflare 520–524: что значат и как исправить

Коды 520, 521, 522, 523 и 524 не найти в стандарте HTTP — их придумал Cloudflare для одной ситуации: «мы работаем, а ваш сервер — нет». Разбираем, что означает каждый код, где именно рвётся цепочка и почему эти ошибки — почти всегда зона ответственности владельца сайта, а не Cloudflare.

Ошибки 520–524 — нестандартные коды Cloudflare, которые означают проблему соединения между Cloudflare и исходным (origin) сервером сайта. Когда сайт работает через Cloudflare, посетитель общается не с вашим сервером, а с ближайшим узлом Cloudflare, который затем ходит к вашему серверу за содержимым. Если на этом втором плече что-то ломается, Cloudflare не может использовать стандартные коды — их мог бы прислать и сам сайт, — поэтому ввёл собственную серию 52x. Читается она просто: «до вашего сервера мы не достучались, и вот как именно».

Карта кодов: где именно рвётся

Если наложить это на путь запроса, получится лесенка: 523 — «не знаем, куда идти», 522 — «идём, но не доходим», 521 — «дошли, но нас не пустили», 520 — «пустили, но ответили ерундой», 524 — «пустили, но ответ так и не доделали». По сути это детализированные родственники стандартных 502 и 504 — только с указанием, на каком шаге всё сломалось.

Диагностика: три вопроса по порядку

Вопрос 1: жив ли origin-сервер? Зайдите на сервер по SSH или через панель хостинга и проверьте, работает ли веб-сервер. Если есть возможность — запросите сайт напрямую по IP origin-сервера, минуя Cloudflare. Отвечает напрямую, но не через Cloudflare — проблема в связке; не отвечает вовсе — чините сервер, Cloudflare ни при чём.

Вопрос 2: не блокирует ли файрвол адреса Cloudflare? Классика 521-й и 522-й: панель управления сервером или защитный модуль хостинга посчитали множество запросов с одних и тех же подсетей атакой и забанили их. А это были узлы Cloudflare — через них ходят все ваши посетители. Список официальных подсетей Cloudflare публикует, их нужно внести в исключения. Похожий механизм — когда защита сервера банит и точки мониторинга; мы разбирали это в статье про WAF и мониторинг.

Вопрос 3 (для 524): что тормозит? Здесь сервер жив и соединяется, но не укладывается в лимит ожидания ответа. Ищите долгие операции: выгрузки, отчёты, кривые SQL-запросы, внешние API, которые не отвечают. Быстрое обходное решение — вынести тяжёлые операции в фон; правильное — оптимизировать сам запрос.

Скорая помощь: как быстро вернуть сайт посетителям

Пока идёт разбирательство, у Cloudflare есть два аварийных рычага, о которых часто забывают.

Пауза Cloudflare (Pause Cloudflare on Site) — трафик пойдёт напрямую на origin-сервер, минуя прокси. Если сервер жив, а сломана именно связка, сайт немедленно оживёт — правда, без защиты и кэша Cloudflare. Заодно это отличный диагностический тест: ожил на паузе — причина точно в настройках связки, не в сервере.

Режим «серого облака» для отдельной DNS-записи — то же самое, но точечно: конкретный поддомен выводится из-под прокси, остальные продолжают работать через Cloudflare. Удобно, когда 52x сыпется только на одном сервисе — например, на API-поддомене с нестандартными таймаутами.

Почему 52x может видеть только часть посетителей

Cloudflare — это сотни точек присутствия, и ваш origin-сервер общается не с одной из них, а со многими: посетитель из Новосибирска приходит через один узел, из Москвы — через другой. Поэтому 52x-ошибки бывают «пятнистыми»: если файрвол забанил только часть подсетей Cloudflare или маршрут до сервера рвётся из одного региона, ошибку увидят посетители одних городов, а других — нет.

Для российских сайтов добавляется своя специфика: часть трафика к зарубежным узлам Cloudflare ходит нестабильно, и симптомы «то работает, то 522» могут вообще не зависеть от вашего сервера. Этот пласт проблем — вместе с вопросом, стоит ли российскому сайту сидеть за Cloudflare, — мы разобрали в отдельной статье. Практический вывод один: диагностировать 52x по жалобе одного пользователя нельзя — нужно видеть картину из нескольких регионов сразу.

Почему это сложно заметить со стороны владельца

Коварство 52x-ошибок в том, что Cloudflare продолжает исправно работать: DNS отвечает, статика из кэша может отдаваться, панель показывает зелёное. Сайт при этом для посетителей мёртв или полумёртв. Если ваш мониторинг проверяет только «отвечает ли домен» — он может пройти мимо: узел Cloudflare ответит быстро, честно отдав 521 вместо страницы.

Поэтому проверка должна смотреть на код ответа, а не на факт ответа. Проверка доступности (GET) загружает страницу как посетитель и фиксирует несовпадение с ожидаемым кодом — 520-я серия открывает инцидент так же, как обычная 500-я. А проверка порта, направленная напрямую на origin-сервер, помогает мгновенно отличить «лежит сам сервер» от «сломалась связка с Cloudflare» — два инцидента вместо одного сразу подсказывают, где копать.