Ошибка 522 Cloudflare: как проверить связь CDN с сервером сайта

Ошибка 522 Cloudflare означает, что Cloudflare не смог вовремя завершить необходимый обмен с исходным сервером сайта. Посетитель получает страницу «Connection timed out», хотя сам Cloudflare отвечает. Владельцу нужно проверить участок между CDN и сервером, на котором работает приложение: адрес назначения, доступность, сетевые ограничения и состояние обработки соединений.

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

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

В обычной схеме с проксированием браузер обращается к Cloudflare, а Cloudflare при необходимости получает данные с исходного сервера — origin. Это два разных участка связи. Сообщение Error 522: Connection timed out указывает на тайм-аут при обращении Cloudflare к origin; значение объясняет официальная справка об ошибке 522.

При диагностике различают установление TCP-соединения и подтверждение переданных данных после его установки. Отсутствие ожидаемого SYN+ACK на первом этапе и отсутствие ACK запроса на следующем — разные условия. ACK здесь является подтверждением на транспортном уровне, а не готовой HTML-страницей или сообщением об успешном заказе.

Не считайте эти два описания исчерпывающим объяснением любого случая. В справочнике ограничений соединений Cloudflare отдельно уточняет особенности TCP и TLS: тайм-аут возможен и при ещё не завершённом защищённом соединении. По продолжительности ожидания в браузере нельзя надёжно определить точный этап отказа.

522 также не равен 524. При ошибке 524 Cloudflare уже установил соединение, но не дождался предусмотренного завершения обмена, например своевременного HTTP-ответа. Увеличение времени выполнения PHP не является универсальным исправлением 522: сначала найдите, где именно прерывается связь.

Что делать посетителю сайта при Cloudflare 522

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

1. Сохраните введённый текст. Если форма ещё доступна, скопируйте важные данные перед закрытием вкладки.
2. Проверьте результат операции. После заказа, оплаты или заявки посмотрите её состояние либо уточните у поддержки, прежде чем отправлять повторно.
3. Сделайте одну проверку после паузы. Откройте нужный раздел обычным способом и запишите, остался ли отказ.
4. Сохраните детали. Нужны адрес, время с часовым поясом и Ray ID, если он показан на странице.
5. Сообщите владельцу. Уточните, не работает весь сайт или конкретное действие, и приложите снимок без личных данных.

Очистка всех cookies и смена DNS на устройстве не меняют адрес origin, настроенный владельцем, или правила его межсетевого экрана. Сравнение с другой обычной сетью иногда помогает описать условия, но не доказывает причину и не заменяет серверную диагностику.

Если сервис сообщил о технических работах, следите за официальными обновлениями. Единого времени восстановления для ошибки 522 нет. Для срочного обращения используйте предусмотренный компанией альтернативный канал, если он существует.

Как владельцу начать диагностику ошибки 522

Сначала зафиксируйте один конкретный неуспешный запрос. В браузере найдите его в Network («Сеть»), проверьте фактический статус, URL и метод. Установите, отказал основной документ, фоновое обращение или сторонний ресурс. Сохраните время, сведения о последнем изменении и результат следующей допустимой проверки. Порядок сбора сетевых данных приведён в руководстве Cloudflare по диагностике.

Ray ID помогает сопоставлять события Cloudflare, но используйте его вместе со временем и адресом. Документация Ray ID не гарантирует уникальность каждого такого идентификатора. Не делайте вывод «запроса не было» только потому, что запись не нашлась в одном разделе с выборочными данными.

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

При наличии соответствующих данных используйте Origin Analytics: там можно сравнивать ошибки соединений, маршруты и ответ origin с кодом, отправленным посетителю. Эти значения способны различаться. Не воспринимайте отсутствие HTTP-статуса от origin как доказательство одной конкретной причины без остальных наблюдений.

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

Основные причины 522 и что проверять

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

Наблюдение	Направление проверки	Что сопоставить
522 появился после переноса	Адрес исходного сервера	Настройки DNS и адрес, выданный хостингом
Сбой начался после изменения защиты	Блокировку соединений Cloudflare	Журнал правила, источник и нужный порт
Отказы совпадают с нагрузкой	Состояние службы и ресурсов	Соединения, очереди и системные события
Не работает отдельный путь	Его фактическое назначение	Origin Rules, балансировщик и выбранный сервер
Проблема появляется нерегулярно	Различия маршрутов и узлов	Успешные и неуспешные обращения за один период

В Cloudflare указан устаревший адрес origin

Сравните записи проблемного имени с текущими данными хостинга. A соответствует IPv4, AAAA — IPv6; их назначение описано в справочнике типов DNS-записей. Проверьте все используемые адреса, а при CNAME — конечное назначение. Исправляйте подтверждённое несоответствие, не удаляя записи только потому, что они незнакомы.

При проксировании публичный DNS обычно показывает адреса Cloudflare. Это ожидаемое поведение, а не обязательно ошибка. Реальный адрес назначения смотрите в настройках своей зоны и используемых правил. Публичная проверка домена не заменяет такое сравнение; различие поясняет документация статуса проксирования.

Отдельно различайте IPv6 на участке «посетитель — Cloudflare» и адрес, используемый для обращения к origin. Cloudflare может формировать публичные AAAA-записи для подключения посетителей; это описано в документации IPv6 compatibility. Поэтому наличие IPv6 в публичном ответе DNS само по себе не доказывает, что CDN подключается к вашему серверу именно по IPv6. Для расследования сравнивайте фактические адреса назначения в своей конфигурации и наблюдения хостинга. Отключение IPv6 на компьютере посетителя не проверяет этот серверный участок; удаление AAAA из зоны без понимания её назначения тоже не является обоснованным исправлением.

Не забудьте отдельные имена: основной домен, www, API и другие поддомены могут иметь разные настройки. После переезда одного сайта легко проверить главную и пропустить старый адрес у обработчика интеграции. Зафиксируйте, какое именно имя участвовало в неуспешном запросе.

Хостинг ограничивает обращения с адресов Cloudflare

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

Сопоставьте время отказа с записью блокировки: какой адрес, порт и правило участвовали? Для разрешений используйте официальный актуальный список диапазонов Cloudflare. Один найденный в журнале IP не представляет всю сеть; список из случайной старой инструкции тоже может быть неполным.

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

Origin недоступен или не справляется с соединениями

Проверьте, работает ли нужная служба и принимает ли она обращения на ожидаемом адресе и порту. Запущенный процесс ещё не доказывает готовность обслуживать сайт: он мог использовать другой конфиг, завершать запуск или ожидать зависимый компонент.

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

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

Сбой маршрута, потеря пакетов или настройки соединений

Когда адреса и правила выглядят правильными, попросите администратора исследовать сетевой обмен между инфраструктурой хостинга и Cloudflare. Важны направление проверки и время: трассировка с ноутбука посетителя исследует другой участок и не подтверждает исправность связи CDN с origin.

Справка Cloudflare по 522 предлагает при необходимости подготовить MTR или traceroute от origin к адресу Cloudflare, который подключался к серверу. Такой адрес выбирают по реальным наблюдениям. Отдельная звёздочка в трассировке сама по себе не доказывает поломку: результат должен оценить специалист вместе с остальными данными.

Также проверьте настройки повторного использования соединений, если журналы указывают на эту область. В справочнике Connection limits описана роль keep-alive. Любое изменение привязывайте к конкретной конфигурации сервера; универсальная правка времени ожидания не решает неверный адрес или отбрасывание пакетов.

Запрос направляется не туда из-за дополнительных правил

Если используется переопределение origin, проверьте его условия. Origin Rules могут менять назначение и порт для выбранных запросов. Поэтому правильная запись основного домена ещё не подтверждает маршрут отдельного API. Сравните имя назначения, порт, Host и условия HTTPS с проектной схемой.

Для Cloudflare Pages и Workers нужна проверка их собственной привязки домена и маршрутизации. Официальная справка 522 рассматривает и такие случаи, включая проблемные обращения Worker к собственному имени. Не применяйте инструкцию для обычного VPS, пока не установили, какой компонент фактически обслуживает домен.

Пример: ошибка 522 появилась после переноса сайта

Рассмотрим условную ситуацию. Команда перенесла сайт на новый сервер, но в Cloudflare осталось прежнее назначение для одного поддомена. Главная открывается, а обращение к этому поддомену возвращает 522. Это учебный пример, а не результат проверки конкретного проекта.

Сначала фиксируют адрес неуспешного запроса и время. Затем сравнивают записи зоны с данными нового хостинга и проверяют, какой сервер должен принимать запрос. Не ограничиваются фразой «DNS уже поменяли»: изменение могло затронуть только основной домен.

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

Другой возможный результат проверки: адрес уже правильный, но хостинг фиксирует блокировки входящих соединений Cloudflare. Тогда повторная правка DNS не поможет. Исправлять нужно подтверждённое правило доступа. Один и тот же код приводит к разным действиям в зависимости от собранных фактов.

Как применить исправление и не потерять причину

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

Переключение оранжевого облака в DNS-only меняет путь трафика и набор функций Cloudflare. Оно не восстанавливает прежнюю связь CDN с origin, поэтому не является универсальным лечением 522. Проверку исходного сервера напрямую выполняет администратор по согласованной процедуре, с правильным именем хоста и условиями TLS.

Успех такого отдельного теста тоже имеет границы: доступность origin из административной сети не доказывает доступность со стороны Cloudflare. Для завершения расследования нужно подтвердить нормальную работу обычного пользовательского пути и сопоставить её с журналами.

Как проверить, что 522 устранён

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

• Запрос через Cloudflare получает предусмотренный ответ вместо 522.
• Его обслуживает ожидаемый origin или предусмотренный маршрут.
• В журналах больше не повторяется установленная причина отказа.
• Работает исходный сценарий, а не только главная страница.
• При нескольких серверах проверены участвующие адреса и настройки.
• Результат сохраняется в условиях, при которых возникал сбой.

Успешный статический файл может прийти из кэша и не проверить обращение к приложению. Правила кэширования Cloudflare зависят от содержимого и конфигурации. Выберите предусмотренную проверку нужного обработчика; массовая очистка кэша для этого не обязательна.

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

Как замечать повторные ошибки раньше жалоб клиентов

История ответов публичного адреса помогает сопоставить повторный 522 с переносом сайта, изменениями хостинга или запуском задач. При выборе мониторинга уточните, какие данные об отказах сохраняются и как получает уведомление ответственный. Чтобы обсудить задачу на SiteGuard, подготовьте URL, время ошибки, Ray ID при наличии и подтверждённые наблюдения о связи Cloudflare с origin.

Одна внешняя проверка URL не показывает настройки Cloudflare и журналы origin: для установления причины их изучают отдельно. Проверка адреса также не воспроизводит все формы и пользовательские сессии. Соединяйте внешнее наблюдение с проверкой важных действий и данными компонентов, которые их обслуживают.

Что передать хостингу или поддержке Cloudflare

Подготовьте URL, метод, время с часовым поясом, Ray ID при наличии, частоту отказов и затронутые функции. Добавьте сведения о переносе и других изменениях, подтверждённое назначение origin и короткие относящиеся к событию записи. Секреты доступа, cookies и содержимое клиентских документов для первого обращения не нужны.

Условный шаблон: «Поддомен возвращает HTTP 522 после переноса. В Cloudflare указан согласованный адрес нового сервера. Проверка выполнена в 12:10 UTC, Ray ID сохранён. Просим проверить входящие соединения Cloudflare, правила доступа и состояние службы в этот период». Используйте только собственные наблюдения.

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

Частые вопросы об ошибке 522 Cloudflare

522 означает, что Cloudflare полностью не работает?

Нет. Код указывает на проблему обмена с origin для конкретного обращения. Масштаб и источник уточняют по данным сервиса, хостинга и запросов. Сам факт появления страницы Cloudflare не назначает виновный компонент.

Почему часть сайта открывается?

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

Нужно ли ждать обновления DNS?

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

Поможет ли более дорогой тариф?

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

Можно ли считать проблему решённой после одного ответа 200?

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