Ошибка Cloudflare 522: истекло время соединения - причины и решения

2026-09-16 Обновлено: 2026-09-19

Ошибка Cloudflare 522 означает, что Cloudflare попытался открыть TCP-соединение с вашим origin-сервером и не получил ответа в пределах своего таймаута, около 15 секунд. В отличие от отказа в соединении, здесь никто не сказал "нет" - origin просто не ответил вовремя.

Что означает ошибка 522

Каждый проксируемый запрос начинается с того, что Cloudflare открывает TCP-соединение с вашим origin, прежде чем отправить сам HTTP-запрос. Ошибка 522 срабатывает, когда это рукопожатие - TCP SYN и ожидаемый в ответ SYN-ACK - не завершается в пределах окна таймаута Cloudflare. Origin может быть слишком перегружен, чтобы принимать новые соединения, файрвол может молча отбрасывать пакеты вместо того, чтобы их отклонять, либо сетевой путь между Cloudflare и origin может быть перегружен.

Это отличается от ошибки 521, где origin активно отказывает в соединении, и от ошибки 524, где TCP-соединение устанавливается успешно, но сам HTTP-ответ так и не приходит вовремя. Ошибка 522 - это именно сбой на этапе рукопожатия, еще до того, как вообще отправлен какой-либо HTTP-запрос.

Как проявляется ошибка 522

Посетители видят страницу Cloudflare: "Error 522: connection timed out" вместе с Ray ID. Запрос curl к домену покажет тот же статус примерно через время таймаута Cloudflare:

curl -I https://example.com
HTTP/2 522

Поскольку TCP-рукопожатие так и не завершилось, до вашего приложения не дошло ни одного запроса, поэтому логи приложения за период сбоя обычно пусты. Вместо этого смотрите на метрики уровня соединений: нагрузку сервера и CPU в момент ошибок, число установленных и ожидающих соединений (ss -s или netstat -an | grep SYN_RECV), а также логи файрвола или балансировщика нагрузки на предмет отброшенных или отфильтрованных пакетов на нужном порту.

Что вызывает ошибку 522

Origin-сервер перегружен и не успевает принимать новые соединения. Высокая нагрузка на CPU, переполненная очередь ожидающих соединений или исчерпанный пул воркеров - все это приводит к такому результату.
Файрвол или security group молча отбрасывает SYN-пакеты Cloudflare вместо того, чтобы отправлять сброс TCP. Отбрасывание со стороны Cloudflare выглядит абсолютно так же, как медленный или неработающий сервер, тогда как сброс вместо этого дал бы ошибку 521.
На origin отключен TCP keepalive, что увеличивает текучесть соединений и вероятность того, что новое рукопожатие придется на момент, когда сервер слишком занят, чтобы его принять.
IP-адрес origin неправильно внесен в список разрешенных там, где сеть требует явного allowlist, а не простого правила файрвола, так что запросы Cloudflare отфильтровываются еще до того, как доходят до слушающего сокета.
Перегруженность сети или потеря пакетов между Cloudflare и origin, что чаще встречается у origin на хостинге потребительского уровня или сильно перепроданных ресурсах.

522 против 524

Оба кода - это таймауты, но они происходят на разных этапах запроса. Ошибка 522 происходит еще до отправки какого-либо HTTP-запроса: само TCP-рукопожатие так и не завершается. Ошибка 524 происходит уже после: TCP-соединение устанавливается успешно, и Cloudflare отправляет HTTP-запрос, но origin не присылает полный ответ в течение 100 секунд. 524 обычно указывает на медленное приложение - например, на эндпоинт генерации отчета, долгий запрос к базе данных или запрос по cron, который законно занимает минуты. Решение для 524 почти всегда состоит в том, чтобы ускорить эндпоинт либо вынести медленную работу из цикла запрос-ответ в фоновую задачу, результат которой клиент опрашивает; тарифы Cloudflare Enterprise также позволяют повысить лимит в 100 секунд для отдельных маршрутов, но это лечит симптом, а не сам медленный эндпоинт.

Как понять, кто виноват

522 почти всегда возникает на стороне origin или рядом с ним, поскольку сама сеть Cloudflare крайне отказоустойчива и редко становится источником таймаута рукопожатия. Полезный вопрос - лежит ли origin полностью или просто задыхается под нагрузкой из определенных регионов. Быстрее всего это проверить, запустив HTTP-проверку из нескольких мест одновременно: HTTP-проверка HostTracker опрашивает домен из контрольных точек в нескольких странах и сообщает результат каждой отдельно, так что картина, где одни точки получают таймаут, а другие успешны, указывает на перегруженный сервер, справляющийся с частью запросов, но не со всеми, тогда как равномерный таймаут повсюду указывает на полностью упавший origin либо на файрвол, отбрасывающий каждое соединение.

Как исправить ошибку 522

Если вы посетитель

Перезагрузите страницу после недолгого ожидания. Кратковременный всплеск нагрузки или мимолетный сбой сети часто проходит сам собой.
Проверьте статус-страницу сайта, если она есть, - на предмет известного инцидента.
На своей стороне исправлять нечего. Таймаут происходит между Cloudflare и собственным сервером сайта, а не в вашем браузере или в вашем соединении с Cloudflare.

Если вы администрируете сайт

Проверьте нагрузку сервера и доступную емкость соединений в момент сбоев: CPU, память и настроенные лимиты соединений или воркеров веб-сервера (например, worker_connections у nginx).
Убедитесь, что ваш файрвол или security group разрешает актуальные опубликованные диапазоны IP Cloudflare на нужном порту, и что он отвечает сбросом, а не молча отбрасывает пакеты, - это как минимум превращает 522 в более легко диагностируемую 521.
Включите TCP keepalive на веб-сервере origin и на любом балансировщике нагрузки перед ним, и проверьте, что настройки keepalive на уровне ОС не оставлены по умолчанию гораздо длиннее, чем реально нужно соединению.
Если ваш хостинг или облачная сеть требует отдельного явного allowlist IP помимо файрвола, убедитесь, что IP-адрес origin в нем есть.
Замерьте время самого рукопожатия напрямую с origin, минуя Cloudflare, чтобы увидеть, есть ли задержка вообще при обращении к вашему серверу:
```
curl -v -H "Host: example.com" --connect-timeout 5 https://ORIGIN_IP/
```
Соединение, зависающее здесь, подтверждает, что сам origin медленно принимает соединения, а не что дело в чем-то специфичном для Cloudflare.
Для медленных отдельных эндпоинтов, а не сервера, перегруженного в целом, вынесите долгую работу (отчеты, экспорт, пакетные задачи) из пути запроса в фоновую задачу, которую клиент опрашивает или о которой получает уведомление, и рассматривайте повышение таймаута в Cloudflare Enterprise лишь как временную меру для маршрутов, которые нельзя ускорить быстро.

Как это предотвратить

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

Часто задаваемые вопросы

Сколько ждет Cloudflare, прежде чем показать ошибку 522?

Около 15 секунд на TCP-рукопожатие. Если к этому моменту origin не принял соединение, Cloudflare сдается и возвращает посетителю 522.

Означает ли 522 то же самое, что мой сервер упал?

Не всегда. Это также может означать, что сервер работает, но слишком занят, чтобы вовремя принять новое соединение, либо что файрвол отбрасывает попытку соединения, не отправляя сброс.

Почему файрвол отбрасывает соединение, а не отклоняет его?

Некоторые конфигурации файрвола или security group по умолчанию молча отбрасывают пакеты, не совпавшие с разрешающим правилом, вместо того чтобы отправлять сброс TCP. Именно это молчаливое отбрасывание превращает то, что могло бы быть быстрой и понятной 521, в более медленную и неоднозначную 522.

Означает ли 522, что мне нужно апгрейдить сервер?

Не обязательно. Прежде чем масштабироваться, проверьте, не отключен ли keepalive, не отбрасывает ли файрвол молча диапазоны Cloudflare, и не выставлены ли лимиты соединений в настройках веб-сервера ниже, чем реально требует трафик.

В чем разница между 522 и 524?

522 - это сбой на этапе, когда не удалось даже завершить TCP-рукопожатие. 524 - это уже установленное соединение, где сам HTTP-ответ занимает слишком много времени, обычно из-за медленной логики приложения, а не сетевой проблемы или проблемы с емкостью.

Может ли один медленный запрос к базе данных вызвать 522?

Не напрямую, поскольку 522 происходит еще до отправки какого-либо запроса. Медленный запрос скорее приведет к 524, где соединение установилось успешно, но ответ пришел слишком долго.