Cloudflare 524: сервер принял запрос, но слишком долго отвечает

Соединение установлено, запрос принят, сервер приступил к работе, но ответ не пришёл за отведённое время. Именно так выглядит 524. Сеть Cloudflare ждёт ответа источника определённый период, и если он истёк, показывает эту ошибку. Значение зависит от плана обслуживания и настроек, поэтому не стоит рассчитывать на конкретное число секунд: лучше исходить из того, что длительные операции на обычных запросах небезопасны.

В отличие от 522, сервер жив и отзывчив. Проблема в том, что конкретная операция слишком тяжёлая или зависла.

Чаще всего это медленные запросы к базе данных, тяжёлые отчёты, экспорт больших объёмов данных, обработка загруженных файлов и другие длинные вычисления, выполняемые прямо во время запроса. Вторая причина — зависание на внешнем вызове: приложение ждёт ответа сторонней службы, а та не отвечает.

Третья — перегрузка сервера: очередь запросов растёт, каждый следующий ждёт дольше. Четвёртая — взаимные ожидания в базе, при которых запросы стоят друг за другом. Пятая — ошибка в коде, например бесконечный цикл, который никогда не возвращает результат.

Страница какое-то время грузится, затем появляется сообщение с кодом. Если вы отправляли форму или запускали операцию, вполне вероятно, что она продолжает выполняться на сервере, хотя вы получили ошибку. Поэтому не нажимайте повторно кнопку заказа, экспорта или отправки, не убедившись в результате, иначе получите дубликаты.

Проверьте историю операций в личном кабинете, подождите несколько минут и убедитесь, была ли выполнена операция. Если нет, повторите с меньшим объёмом данных, например за более короткий период.

Включите журнал медленных запросов и посмотрите, какие обработчики выполняются дольше всех. Проверьте использование процессора и памяти в момент сбоя, состояние базы данных, наличие блокировок и число активных соединений. Сравните время ответа при обращении напрямую к серверу и через сеть доставки.

Если причина в конкретном обработчике, изучите его запросы: нет ли отсутствующих индексов, выборок без ограничений, повторных запросов в цикле. Иногда достаточно добавить индекс или ограничить объём выборки.

С точки зрения человека 524 особенно неприятна тем, что результат неясен. Если вы запускали отчёт, выгрузку или обработку файла, не торопитесь повторять действие. Сервер мог довести работу до конца, и повторный запуск создаст вторую копию, удвоит списание средств или загрузит нагрузку ещё сильнее.

Подождите пару минут и проверьте раздел с историей операций, уведомления или электронную почту. Если результата нет, повторите запуск с меньшими параметрами: более коротким периодом дат, меньшим числом строк, без лишних столбцов. Если ошибка стабильно возникает на одной и той же операции, сохраните время и описание шагов и передайте в поддержку. Такая информация значительно ускоряет поиск проблемного обработчика и позволяет разработчикам воспроизвести ситуацию на своём стенде без догадок.

Вынесите долгие операции в фоновые задачи: сервер быстро отвечает, что работа поставлена в очередь, а клиент опрашивает статус или получает уведомление по завершении. Разбивайте экспорт на части, применяйте постраничную выдачу, кешируйте результаты тяжёлых вычислений. Для обмена с внешними службами задавайте свои тайм-ауты короче, чем у сети доставки, чтобы приложение само корректно обрабатывало сбой и выдавало понятное сообщение вместо общей ошибки.

Полезно также заранее показывать пользователю ход выполнения: индикатор, статус задачи, уведомление на почту. Когда человек видит, что операция принята и выполняется, он не станет нажимать кнопку повторно. На стороне сервера ведите учёт идентификаторов задач, чтобы повторный запуск с теми же параметрами не создавал дубликатов, а возвращал уже идущую работу. Стоит также предусмотреть отмену запущенных задач и разумные лимиты на объём данных в одном запросе, чтобы одна тяжёлая операция не занимала ресурсы надолго.