Error 522: что это за ошибка и как её исправить

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

Обновлено: 2026-09-27 21:15:54 Вадим Дворниковавтор материала

Error 522: что это за ошибка и что она означает

Ошибка 522 на сайте – это таймаут соединения между Cloudflare и сервером сайта. Cloudflare работает посредником. Посетитель обращается к нему, а он – к origin-серверу, где лежит сайт. Если origin не отвечает вовремя, посетитель видит страницу с кодом 522.

В документации Cloudflare ошибка называется «Connection timed out». Cloudflare не смог открыть TCP-соединение с сервером. Либо соединение открылось, но на запрос ресурса не пришло подтверждение.

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

Ошибку 522 нельзя исправить в браузере. Очистка истории, переустановка Chrome и отключение расширений на неё не влияют. Исправляют её владелец сайта или хостинг.

Почему Cloudflare не дозвонился до сервера

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

Схема 1. Успешное рукопожатие: все три шага пройдены, сайт открывается.

Ошибка 522 возникает, когда эта цепочка обрывается. Документация Cloudflare описывает два сценария. В первом обрыв случается на первом шаге, во втором – после установки соединения.

Сценарий 1: сервер не ответил на запрос соединения

Cloudflare отправляет SYN и ждёт SYN+ACK. Если ответа нет в течение 19 секунд, Cloudflare отдаёт ошибку 522. Сервер при этом выключен, недоступен или отбрасывает пакеты.

Схема 2. Сервер молчит: ответ на запрос соединения не пришёл.

Сценарий 2: соединение открылось, но ответа нет

Рукопожатие завершено, Cloudflare отправил запрос ресурса. Сервер не подтвердил получение запроса. Это тоже ошибка 522, хотя соединение уже было.

Схема 3. Соединение установлено, но подтверждение запроса не пришло.

Поэтому первый вопрос диагностики такой: открывается ли TCP-соединение с сервером вообще? Ответ даёт проверка в обход Cloudflare, она описана ниже.

Частые причины ошибки 522

Документация Cloudflare называет пять причин 522. К ним добавляются две типичные ошибки настройки, которые встречаются у владельцев сайтов.

• Cloudflare блокируют на сервере. IP-адреса Cloudflare ограничены или заблокированы в .htaccess, iptables или фаерволе. Сюда входят fail2ban, mod_security и защита хостинга от DDoS. Cloudflare называет это самой частой причиной.
• Сервер выключен или перегружен. Веб-сервер (nginx или Apache) упал либо не справляется с нагрузкой. Кончились память или рабочие процессы, упёрлись в лимит соединений тарифа. Такой сервер отбрасывает входящие запросы.
• На сервере отключён keepalive. Cloudflare называет это отдельной причиной 522.
• В DNS указан неверный IP. Адрес в записи Cloudflare не совпадает с текущим IP сервера. Так бывает после переезда на другой хостинг.
• Пакеты теряются на сервере. Cloudflare отправил запрос, но пакеты не дошли до приложения.
• Закрыты порты 80 и 443. Фаервол сервера или провайдера режет порты, на которых Cloudflare ждёт сайт.
• Сайт слушает нестандартный порт. Cloudflare проксирует только свой список портов: 80, 8080, 8880, 2052, 2082, 2086 и 2095 для HTTP, а также 443, 2053, 2083, 2087, 2096 и 8443 для HTTPS. Сервер на любом другом порту через прокси не откроется.

Причины похожи снаружи, но лечатся по-разному. Порядок проверки в следующих разделах отсекает их от простых к сложным.

Как исправить ошибку 522: проверка сервера и фаервола

Идите по шагам сверху вниз. Сначала идут дешёвые проверки, потом дорогие. Первый шаг делит проблему пополам: он показывает, молчит сервер или дело в стыке с Cloudflare.

Шаг 1. Проверьте, отвечает ли сервер в обход Cloudflare

1. Узнайте IP сервера в панели хостинга или в записи A вашего домена в DNS Cloudflare.
2. Выполните на своём компьютере команду curl -v --resolve example.com:443:203.0.113.10 https://example.com. Вместо example.com подставьте свой домен, вместо 203.0.113.10 – IP сервера.
3. Посмотрите на результат. Пришла страница сайта или ответ веб-сервера – сервер жив. Curl завис на соединении и вышел по таймауту – сервер молчит.

Второй способ – пауза Cloudflare. В панели Cloudflare откройте свой домен, затем «Overview» → «Advanced Actions» → «Pause Cloudflare on Site». Пауза применяется за пять минут или меньше. Когда проверка закончится, включите Cloudflare обратно там же.

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

Серое облако у записи даёт тот же эффект для одной записи. В панели откройте DNS → «Records», нажмите «Edit» у записи A, переключите облако на серое и сохраните кнопкой «Save». Статус «DNS only» отправляет запрос на реальный IP мимо Cloudflare. Проверив сайт, верните облако обратно.

Дальше развилка. Сервер молчит – чините сервер, шаги 2–3. Сервер отвечает – ищите проблему на стыке с Cloudflare, шаги 4–8.

Шаг 2. Убедитесь, что веб-сервер жив

1. Подключитесь к серверу по SSH.
2. Выполните systemctl status nginx. Для Apache подставьте имя службы вашего дистрибутива. В строке «Active» должно стоять «active (running)».
3. Если служба остановлена, запустите её командой systemctl restart nginx.
4. Проверьте память командой free -h. Свободной памяти почти нет – сервер перегружен.
5. Откройте журнал ядра командой dmesg или journalctl -k и найдите записи о нехватке памяти. Ядро могло завершить веб-сервер само (OOM-killer).
6. Прочитайте журнал ошибок веб-сервера. Путь к нему у nginx задаёт директива error_log в файле nginx.conf. У Apache путь ищите в конфигурации или в панели хостинга.

Если сервер запустился после перезапуска, повторите шаг 1. Журнал ошибок часто сразу называет причину падения.

Шаг 3. Проверьте порты 80 и 443

1. На сервере выполните ss -tln. В списке должны быть порты 80 и 443 – значит, веб-сервер их слушает.
2. С другого компьютера выполните nc -zv 203.0.113.10 443. Команда сообщит, открылось ли соединение с портом.
3. Порт слушается, но снаружи закрыт – его режет фаервол сервера или провайдера. Проверьте правила фаервола и раздел безопасности в панели хостинга.

Шаг 4. Разрешите подсети Cloudflare

Cloudflare называет блокировку своих IP самой частой причиной 522. Официальный список подсетей лежит на странице cloudflare.com/ips. Там же есть ссылки на текстовые списки IPv4 и IPv6. Диапазоны меняются нечасто, а при изменении их сначала добавляют в список.

Разрешайте адреса Cloudflare отдельными правилами, а не отключайте фаервол целиком. Иначе сервер останется без защиты от остального интернета.

1. Скачайте оба списка подсетей со страницы cloudflare.com/ips.
2. Для ufw добавьте правило на каждую подсеть: ufw allow proto tcp from <подсеть> to any port 443. Повторите его для порта 80.
3. Для iptables вставьте правило iptables -I INPUT -s <подсеть> -p tcp --dport 443 -j ACCEPT. Ключ -I ставит правило в начало цепочки, перед запрещающими.
4. Проверьте fail2ban. Если он забанил адрес Cloudflare, снимите блок командой fail2ban-client set <jail> unbanip <IP>. Имя jail смотрите в конфигурации fail2ban.
5. Откройте защиту от DDoS и фаервол в панели хостинга. Адреса Cloudflare там должны быть в разрешённых.

После правил повторите проверку из шага 1. Если сайт заработал, причина была в блокировке.

Продолжение диагностики: DNS, нагрузка и таймауты

Шаг 5. Сверьте IP в DNS Cloudflare с реальным IP сервера

Так бывает после переезда: сервер сменил адрес, а запись в Cloudflare осталась старой. Cloudflare называет это отдельной причиной 522.

1. В панели Cloudflare откройте свой домен и раздел DNS → «Records».
2. Найдите запись A вашего домена и посмотрите её значение.
3. Сравните значение с IP сервера из панели хостинга.
4. Адреса разные – нажмите «Edit» у записи, впишите верный IP и сохраните кнопкой «Save».
5. Откройте сайт. Страница должна загрузиться без ошибки 522.

Шаг 6. Проверьте перегрузку и лимиты

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

• nginx. Лимит одновременных соединений на один рабочий процесс задаёт директива worker_connections. По умолчанию она равна 512.
• php-fpm. Параметр pm.max_children ограничивает число дочерних процессов. Если все процессы заняты, сайт не успевает отвечать.
• Тариф хостинга. Сравните нагрузку на процессор, память и число процессов с лимитами тарифа в панели.

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

Шаг 7. Проверьте keepalive и таймауты веб-сервера

Отключённый keepalive Cloudflare называет отдельной причиной 522. В nginx время жизни соединения задаёт директива keepalive_timeout. По умолчанию это 75 секунд, а значение 0 отключает такие соединения.

В Apache постоянные соединения включает директива KeepAlive On. Время ожидания следующего запроса задаёт KeepAliveTimeout. Убедитесь, что keepalive включён, и перезапустите веб-сервер.

Шаг 8. Сверьте предельное время ожидания Cloudflare

Для 522 документация называет 19 секунд: столько Cloudflare ждёт SYN+ACK после отправки SYN. Сервер, который отвечает медленнее, получает ошибку 522. Настройка этого времени в документации по 522 не описана, поэтому чините скорость ответа сервера, а не ждите увеличения таймаута.

Для 524 всё иначе. Время ожидания HTTP-ответа там по умолчанию равно 125 секундам. Тариф Enterprise поднимает его до 6000 секунд.

Как проверить сервер инструментами: MTR, cURL, telnet

Три утилиты закрывают почти все проверки. Curl показывает, доходит ли запрос до веб-сервера. Mtr показывает путь пакетов, а nc проверяет порт за секунду.

cURL: где обрывается запрос

Утилита curl – бесплатный проект с открытым исходным кодом. Запустите её с подробным выводом:

curl -sSv -o /dev/null --connect-timeout 10 https://example.com

Ключ -s убирает индикатор загрузки, а -S оставляет сообщения об ошибках. Ключ -v включает подробный вывод, -o /dev/null отбрасывает тело страницы. Ключ --connect-timeout 10 ограничивает фазу соединения десятью секундами.

Код выхода узнайте командой echo $?. Код 28 значит, что время вышло. Код 7 значит, что curl не смог подключиться. Оба кода говорят об обрыве на этапе соединения.

Время установки соединения покажет команда curl -sS -o /dev/null -w '%{time_connect}\n' https://example.com. Для проверки в обход Cloudflare добавьте --resolve из шага 1.

MTR: где теряются пакеты

Утилиту mtr развивает проект BitWizard, исходный код лежит в репозитории traviscross/mtr. Запустите отчёт командой:

mtr -rw -c 100 203.0.113.10

Ключ -r включает режим отчёта, -w не обрезает имена хостов. Ключ -c 100 задаёт 100 циклов, то есть около 100 секунд. Документация Cloudflare просит показать хостингу MTR или traceroute с сервера до IP Cloudflare. Возьмите любой IP из списка на cloudflare.com/ips.

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

nc и telnet: открыт ли порт

Самая быстрая проверка порта – nc -zv 203.0.113.10 443. Ключ -z только проверяет порт и не отправляет данных, -v включает подробный вывод. Аналог – telnet 203.0.113.10 443.

В Windows telnet-клиент нужно сначала установить. Проще воспользоваться PowerShell: Test-NetConnection 203.0.113.10 -Port 443. Команда проверяет TCP-порт и сообщает результат.

Что делать посетителю, если 522 на чужом сайте

Ошибка 522 при открытии сайта – проблема сайта, а не вашего устройства. Исправить её со своей стороны нельзя. Зато за минуту можно проверить, нет ли проблемы в вашей сети.

1. Откройте сайт с телефона через мобильный интернет. Ошибка осталась – дело точно не в вашей сети.
2. Подождите несколько минут и обновите страницу. Перегрузка на сервере иногда проходит сама.
3. Напишите владельцу сайта: он видит ошибку в своей панели Cloudflare и может её исправить.

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

Чем 522 отличается от 520, 521, 523 и 524

Соседние коды тоже относятся к серверу сайта, но описывают разные обрывы. Таблица помогает быстро найти первое действие.

Сложнее всего различить 521, 522 и 524. При 521 сервер отвечает, но отказом: служба выключена или Cloudflare заблокирован. При 522 сервер молчит: соединение не открылось, а иногда не пришло подтверждение запроса. При 524 сервер принял запрос и не успел ответить.

Error 524 – ошибка другого рода, чем 522: Cloudflare подключился к серверу, но HTTP-ответа не дождался. Про время ожидания для неё сказано в шаге 8. Error 523 встречается реже: тогда у Cloudflare нет маршрута до сервера, и ошибку чинит хостинг или сетевой провайдер.

Что делать, если ошибка вернулась

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

• Журнал сервера. Найдите в журнале ошибок веб-сервера записи за время сбоя. Рядом смотрите журнал ядра: нехватка памяти оставляет там следы.
• Origin Analytics. Документация Cloudflare советует проверять там сбои TCP-соединений с сервером. Это покажет, как часто они случаются.
• Мониторинг. Настройте внешнюю проверку, которая открывает сайт напрямую по IP и через Cloudflare. Сравнив результаты, вы увидите, где обрыв.

Если причину найти не удалось, пишите в поддержку. Хостингу отправьте MTR или traceroute с сервера до IP Cloudflare и журналы веб-сервера. Cloudflare приложите заголовок CF-RAY страницы с ошибкой и traceroute. Укажите точное время сбоев и домен.

Частые вопросы

Ошибка 522 – это у меня или у сайта?

У сайта. Страницу с кодом 522 отдал Cloudflare, а он открылся у вас без проблем. Обрыв произошёл между Cloudflare и сервером сайта. Со своей стороны его исправить нельзя.

Что за ошибка 522?

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

Error 522 – что это: то же самое, что «ошибка 522»?

Да, это одна и та же ошибка. Error 522 – английское написание, «ошибка 522» – русское. На странице Cloudflare она подписана «Connection timed out».

Отключение Cloudflare уберёт 522?

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

Виноват ли хостинг?

Иногда. Хостинг отвечает за сервер, сеть и защиту от DDoS, которая часто блокирует Cloudflare. Но неверный IP в DNS Cloudflare или закрытые порты в вашем фаерволе – зона владельца сайта. Шаги 1 и 5 покажут, чья это проблема.

Почему 522 появляется не у всех посетителей?

Запросы к серверу приходят с разных IP Cloudflare. Фаервол может блокировать только часть диапазонов. Перегруженный сервер отвечает не на все запросы подряд. Поэтому одни посетители видят сайт, а другие – ошибку.

Пройдёт ли она сама?

Зависит от причины. Кратковременная перегрузка проходит сама, и сайт открывается снова. Выключенный сервер, неверный IP в DNS и блокировка Cloudflare сами не исчезнут. Их нужно исправить по шагам из раздела про диагностику.

Держите под рукой IP сервера и список подсетей Cloudflare, тогда первые проверки ошибки 522 займут несколько минут.

Вадим Дворниковавтор-переводчик статьи «How To Fix Error 522: Quick And Easy Methods (Update)»