Cloudflare выдаёт ошибку 522 после переноса сайта на VPS

Что означает ошибка Cloudflare 522 после переноса сайта на VPS

Cloudflare 522 означает timeout на участке Cloudflare → origin-сервер. Cloudflare не удаётся вовремя завершить соединение с VPS: проблема может возникать уже при установлении TCP-соединения или после его установления, когда origin не продолжает обмен данными так, как ожидается.

При включённом проксировании браузер посетителя соединяется не напрямую с вашим VPS. Сначала запрос принимает edge-сервер Cloudflare, а затем Cloudflare открывает отдельное соединение с origin. Если новый VPS не отвечает на попытку подключения, firewall молча отбрасывает пакеты или сервер под нагрузкой перестал нормально принимать новые соединения, посетитель видит 522.

Обычно здесь и возникает путаница: SSH работает, панель VPS открывается, systemctl status nginx показывает active (running), а сайт через Cloudflare всё равно недоступен. Все эти факты могут быть правдой одновременно. Nginx способен слушать только localhost, 443 может фильтроваться внешним firewall, а Cloudflare вообще может обращаться к старому origin.

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

На какой IP Cloudflare сейчас отправляет запросы сайта

Сайт уже перенесли, в панели нового VPS всё выглядит нормально, но 522 появился сразу после переключения DNS. Первым делом откройте Cloudflare → DNS → Records и проверьте содержимое A и AAAA именно там.

Для записи со статусом Proxied публичный DNS-ответ не показывает реальный origin IP. Клиент получает адреса Cloudflare. Поэтому результат обычного dig example.com A нельзя сравнивать с IP VPS и делать вывод, что Cloudflare обращается именно туда.

Публичные DNS-запросы всё равно полезны:

dig example.com A
dig example.com AAAA
dig www.example.com A
dig www.example.com AAAA

Они показывают, как домен видит обычный DNS-клиент, позволяют проверить наличие IPv4/IPv6 на публичной стороне Cloudflare и обнаружить неожиданные записи для www. Но origin для проксируемой записи смотрите в панели Cloudflare.

В Windows вместо dig можно использовать:

nslookup example.com
nslookup www.example.com

Отдельно стоит проверить, кто вообще обслуживает DNS-зону:

dig +short NS example.com

Если домен делегирован на nameserver Cloudflare, изменение A-записи в старой DNS-панели регистратора ничего не даст. Рабочая зона находится в Cloudflare.

Здесь нужен конкретный результат: вы знаете реальный IPv4 и, если используется, IPv6 origin для каждого проксируемого hostname. Не адреса Cloudflare из публичного dig, а именно адрес сервера, к которому Cloudflare должен подключаться.

Почему старая AAAA-запись может давать 522, даже если A-запись правильная

При миграции нужно отдельно проверить IPv6 origin. Корректный A-record не исправит ситуацию, если в Cloudflare осталась AAAA-запись со старым или недоступным IPv6.

Есть три разных IPv6-участка, которые легко перепутать:

• IPv6 между компьютером посетителя и Cloudflare;
• IPv6-адреса edge-инфраструктуры Cloudflare, которые видны в публичном DNS;
• IPv6 вашего origin VPS, сохранённый в DNS-записи Cloudflare.

Для Proxied-записи команда:

curl -6 -I https://example.com/

проверяет соединение вашего компьютера с Cloudflare по IPv6. Она не доказывает, что Cloudflare может подключиться по IPv6 к новому VPS. Аналогично публичный dig example.com AAAA при включённом proxy показывает Cloudflare, а не скрытый origin.

Сначала посмотрите значение AAAA в Cloudflare → DNS → Records. Затем на VPS убедитесь, что такой IPv6 действительно назначен:

ip -6 addr
ip -6 route

Если origin должен обслуживать IPv6, проверьте его напрямую с машины, у которой есть рабочий IPv6-доступ. Для HTTPS можно сохранить hostname и SNI через --resolve:

curl -6 --resolve example.com:443:[ORIGIN_IPV6] https://example.com/ -I

Где ORIGIN_IPV6 — реальный IPv6 нового VPS из Cloudflare DNS dashboard, например:

curl -6 --resolve example.com:443:[2001:db8::10] https://example.com/ -I

Дополнительно проверьте, слушает ли веб-сервер IPv6:

ss -lntp | grep -E ':80|:443'

В Nginx при реальной необходимости IPv6 обычно присутствуют соответствующие IPv6-listen директивы. Но не меняйте конфигурацию вслепую: в некоторых архитектурах IPv6 вообще не используется для origin, и это нормально.

Ситуация должна свестись к одному из двух вариантов: AAAA в Cloudflare указывает на проверенный IPv6 нового VPS либо AAAA отсутствует, потому что origin работает только по IPv4.

Как за две минуты проверить новый VPS без Cloudflare

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

Обычный запрос по IP даёт только базовую информацию:

curl -I http://SERVER_IP

Если сервер отвечает, это лучше, чем timeout, но тест неполный. На одном IP может находиться несколько сайтов, а Nginx и Apache выбирают virtual host по имени домена. Запрос к голому IP способен открыть заглушку, default site или другой проект.

Проверка origin через curl с Host

Заголовок Host позволяет обратиться по IP нового VPS, но попросить веб-сервер обслужить конкретный домен.

curl -I -H "Host: example.com" http://SERVER_IP

Нормальный результат — HTTP-ответ от нужного virtual host. Это может быть 200, 301 или 302. Сам код зависит от конфигурации сайта. Главное, чтобы соединение не зависало и ответ приходил именно от нового сервера.

Если вместо сайта появляется стандартная страница Nginx или заглушка панели, сеть уже работает, но virtual host настроен неправильно. Это хороший симптом: искать нужно выше TCP-уровня.

Проверка HTTPS через curl --resolve

Для HTTPS удобнее использовать curl --resolve: команда подменяет IP только для конкретного запроса, сохраняя hostname для TLS и virtual host.

curl --resolve example.com:443:SERVER_IP https://example.com/ -I

Так можно проверить новый сервер ещё до изменения публичного DNS. Если команда получает нормальный ответ, новый origin умеет обслуживать HTTPS для указанного домена. Если соединение зависает или отклоняется, причина находится на VPS, в сети или firewall.

Для более подробного вывода:

curl -v --resolve example.com:443:SERVER_IP https://example.com/

Ещё один вариант — временная запись в локальном файле hosts:

SERVER_IP example.com
SERVER_IP www.example.com

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

Открыты ли на новом VPS порты 80 и 443

SSH есть. Nginx active. В браузере всё равно 522. В такой ситуации смотрим, кто на самом деле слушает 80 и 443 и можно ли подключиться к этим портам из Интернета.

На самом VPS проверьте LISTEN:

ss -lntp | grep -E ':80|:443'

Пример:

LISTEN 0 511 0.0.0.0:80   0.0.0.0:*
LISTEN 0 511 0.0.0.0:443  0.0.0.0:*

Сервис слушает IPv4-интерфейсы. А строка:

LISTEN 0 511 127.0.0.1:443  0.0.0.0:*

означает, что этот конкретный сокет доступен только локально. Cloudflare напрямую к 127.0.0.1 подключиться не сможет.

LISTEN есть, но доступен ли порт извне

Проверку внешней доступности нельзя делать только с самого VPS. Локальный curl подтверждает работу сервиса внутри машины, но не проверяет firewall провайдера, security group и внешний маршрут.

Запустите тест с рабочего компьютера, другого VPS или любой машины вне проверяемого сервера:

nc -vz SERVER_IP 80
nc -vz SERVER_IP 443

Либо сразу HTTP/HTTPS-тест:

curl -I -H "Host: example.com" http://SERVER_IP
curl --resolve example.com:443:SERVER_IP https://example.com/ -I

Если ss показывает LISTEN, локальный запрос с VPS работает, а внешний nc или curl получает timeout, конфигурацию PHP пока можно не трогать. Ищите фильтрацию между Интернетом и сокетом веб-сервера.

Внутри Linux проверьте используемый firewall.

UFW:

ufw status

firewalld:

firewall-cmd --list-all

nftables:

nft list ruleset

iptables:

iptables -L -n -v

И не забудьте о внешнем firewall в панели VPS-провайдера. Такая схема встречается регулярно: Nginx слушает 0.0.0.0:443, UFW разрешает HTTPS, локальный curl проходит, а внешний security group всё ещё разрешает только SSH.

LISTEN есть. Внешнего доступа всё ещё может не быть. Для уверенного диагноза нужны оба подтверждения.

Не блокирует ли firewall IP-адреса Cloudflare

Если origin стабильно работает напрямую, а после включения Cloudflare Proxy снова появляется 522, проверяйте фильтрацию трафика от Cloudflare. Обычный клиент до VPS доходит, а edge Cloudflare — нет.

Причиной может быть не только UFW или nftables. После миграции встречаются старые правила iptables, Fail2ban, CSF/LFD, ACL, rate limiting в Nginx, защита панели и внешний firewall провайдера.

Проверьте Fail2ban:

fail2ban-client status

Для конкретного jail:

fail2ban-client status JAIL_NAME

Для nftables:

nft list ruleset

Для iptables особенно полезны счётчики:

iptables -L -n -v

Воспроизведите 522 и сразу снова посмотрите правила. Если счётчик DROP растёт в момент запроса, дальше гадать уже незачем: найден реальный участок фильтрации.

Особенно внимательно проверьте правила, перенесённые со старого сервера. Например, 443 мог быть разрешён только старому reverse proxy или нескольким административным IP. С вашего компьютера direct-origin тест пройдёт, если ваш IP разрешён, а Cloudflare продолжит получать timeout.

Удобно выполнить три действия одновременно:

1. Открыть сайт с включённым Cloudflare proxy и воспроизвести 522.
2. Проверить тот же origin через curl --resolve.
3. Смотреть счётчики firewall, access.log и сетевые пакеты.

Direct origin работает, а Cloudflare не появляется даже на сетевом уровне — ищем ACL, firewall или маршрут. Запросы Cloudflare доходят до Nginx — поднимаемся выше по стеку.

Слушает ли Nginx или Apache правильный IP и виртуальный хост

Открытого TCP-порта недостаточно: Nginx или Apache должен принять запрос именно для нужного hostname. После миграции virtual host может быть не активирован, server_name указан неверно или HTTPS-конфигурация не загружена.

Для Nginx начните с:

nginx -t

Если синтаксис корректен, посмотрите фактически загруженную конфигурацию:

nginx -T

В блоке нужного сайта проверьте:

• server_name example.com www.example.com;
• listen 80;, если используется HTTP;
• listen 443 ssl; для HTTPS;
• путь к сертификату;
• upstream или FastCGI-настройки, если запрос передаётся дальше.

Для Apache:

apachectl configtest

Состояние сервисов:

systemctl status nginx
systemctl status apache2
systemctl status httpd

Название Apache-службы зависит от дистрибутива, поэтому одна из последних двух команд может отсутствовать.

Характерный сценарий после переноса: по IP открывается стандартная страница Nginx или заглушка панели. TCP уже работает. HTTP тоже. Но конкретный сайт ещё не попадает в свой virtual host.

Проверка:

curl -I -H "Host: example.com" http://SERVER_IP

Если приходит другой сайт, ищите конфликт server_name, default server или неправильную привязку домена в панели.

В связке Nginx + Apache нужно учитывать архитектуру. Nginx может слушать внешние 80/443, а Apache — только 127.0.0.1:8080. Это нормально: внешний запрос принимает Nginx и уже локально передаёт его Apache.

После изменения конфигурации снова выполните nginx -t или apachectl configtest, перечитайте конфигурацию штатным способом и повторите curl --resolve. Получили нужный virtual host — идём дальше.

Как по логам понять, доходит ли запрос Cloudflare до VPS

Access/error logs и tcpdump позволяют отделить сетевой 522 от проблемы внутри веб-стека. Смысл проверки простой: до какого именно слоя дошёл запрос.

Для Nginx откройте access.log и error.log:

tail -f /var/log/nginx/access.log

tail -f /var/log/nginx/error.log

Затем воспроизведите 522. Пути к логам зависят от дистрибутива, панели и конфигурации virtual host. В ISPmanager, FASTPANEL, cPanel или ручной конфигурации логи сайта могут находиться в другом каталоге.

Если access.log остаётся пустым

Пустой access.log означает, что полноценный HTTP-запрос до этого Nginx не дошёл. Это ещё не доказывает вину firewall, но WordPress и PHP здесь почти наверняка рано проверять. Запрос до них ещё не дошёл.

Посмотрите системный журнал:

journalctl -u nginx --since "10 minutes ago"

Для Apache:

journalctl -u apache2 --since "10 minutes ago"
journalctl -u httpd --since "10 minutes ago"

Теперь опустимся на уровень TCP:

tcpdump -nn 'tcp port 80 or tcp port 443'

Одного факта «пакеты есть» мало. Смотрите последовательность.

• SYN приходит на VPS, SYN-ACK уходит обратно. Сервер хотя бы отвечает на попытку установить TCP-соединение.
• SYN приходит много раз, но SYN-ACK от сервера не видно. Проверяйте локальный firewall, перегрузку сетевого стека и способность сервера принимать новые соединения.
• SYN-ACK уходит, но подтверждения от клиента нет, видны повторные передачи. Возможна проблема обратного маршрута или фильтрация где-то между сторонами.
• TCP handshake проходит, затем соединение зависает. Сетевой вход уже работает, нужно смотреть TLS, веб-сервер и дальнейшую обработку.

Это уже не «Cloudflare где-то не отвечает», а конкретная стадия соединения.

Если запрос появляется в access.log

Строка в access.log означает, что HTTP-запрос дошёл до веб-сервера. Теперь ищите проблему в Nginx/Apache, upstream, PHP-FPM, приложении или ресурсах VPS.

Смотрите HTTP-код, время ответа, upstream и error.log. Если Nginx регулярно перезапускается:

systemctl status nginx
journalctl -u nginx

Если подозрение остаётся на сети, можно дополнительно проверить маршрут с внешней машины:

mtr -rwzc 20 SERVER_IP

или:

traceroute SERVER_IP

Такой тест не доказывает, каким именно маршрутом Cloudflare идёт к origin, и ICMP может фильтроваться. Но устойчивые потери или обрыв маршрута помогают понять, что проблема не обязательно находится внутри Nginx.

Может ли перегруженный VPS вызывать Cloudflare 522

Да. Origin может быть технически включён, но принимать новые соединения настолько медленно или нестабильно, что Cloudflare получает 522. Особенно характерен плавающий сценарий: несколько минут сайт работает, затем начинаются timeout, после чего всё восстанавливается без изменения DNS.

Постоянный и периодический 522 — разные сценарии

Если 522 появился сразу после миграции и воспроизводится постоянно, сначала проверяйте IP, AAAA, 80/443, firewall и веб-сервер. Если ошибка приходит волнами, ресурсы и лимиты становятся намного интереснее.

Базовая проверка:

uptime
top
free -m
vmstat 1
df -h

uptime покажет load average, top — процессы и CPU, free -m — память и swap. В vmstat 1 смотрите несколько строк подряд: так легче заметить стабильный I/O wait или активную работу swap.

Проверьте OOM:

dmesg | grep -i -E 'oom|killed process'

Если ядро убивало Nginx, Apache, PHP-FPM или другой процесс рядом со временем возникновения 522, это уже серьёзная зацепка.

Состояние сервисов:

systemctl status nginx
systemctl status php-fpm

У PHP-FPM unit часто содержит версию, например php8.2-fpm, поэтому точное имя нужно смотреть в конкретной системе.

Когда CPU и RAM в норме, но новые соединения всё равно не принимаются

Бывает другой сценарий: CPU свободен, RAM хватает, диск не захлёбывается, но новые TCP-соединения всё равно начинают теряться. Тогда проблема может быть не в «мощности VPS», а в лимитах соединений.

Начните с общей статистики сокетов:

ss -s

Посмотрите, сколько соединений застряло в SYN-RECV:

ss -ant state syn-recv

Несколько таких соединений сами по себе ничего не доказывают. Но если во время 522 список резко растёт и новые подключения перестают проходить, стоит проверить backlog, защиту от SYN flood и общую способность сервера принимать соединения.

Текущий предел backlog:

sysctl net.core.somaxconn

Если используется conntrack, можно сравнить текущее число отслеживаемых соединений с лимитом:

sysctl net.netfilter.nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max

На системах без соответствующего netfilter-модуля этих параметров может не быть. Это нормально.

Для Nginx полезно проверить лимит соединений worker:

nginx -T 2>&1 | grep -n worker_connections

И лимит открытых файлов для systemd-сервиса:

systemctl show nginx -p LimitNOFILE

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

Не делайте вывод по одной цифре. Высокий load average не всегда означает упор в CPU, десяток SYN-RECV не означает переполненный backlog, а большой conntrack не проблема, пока он не приблизился к реальному лимиту. Нужны совпадающие симптомы и время появления 522.

Почему смена SSL-режима Cloudflare обычно не исправляет 522

Переключение Flexible, Full и Full (strict) не исправит ситуацию, в которой Cloudflare не может нормально установить соединение с origin. Сначала должен работать сетевой путь до 443, затем Nginx и только после этого имеет смысл разбирать TLS.

После миграции владелец сайта видит 522 и начинает переключать SSL/TLS Mode. В итоге меняется поведение редиректов и HTTPS, но закрытый 443 или firewall остаётся на месте.

Проверьте HTTPS напрямую:

curl -vk --resolve example.com:443:SERVER_IP https://example.com/

-v показывает этапы соединения, а -k временно отключает проверку доверия к сертификату для диагностики. Это не способ исправить SSL.

Отдельный TLS-тест:

openssl s_client -connect SERVER_IP:443 -servername example.com

TCP к 443 вообще не устанавливается? Сертификат пока ни при чём. Возвращаемся к LISTEN, firewall и сети.

TCP устанавливается, но приходит неправильный сертификат или другой virtual host — теперь смотрим SNI, HTTPS-конфигурацию и сертификат origin.

Лучше добиться корректного HTTPS непосредственно на новом VPS и только потом возвращать Cloudflare в цепочку.

Как временно отключить Cloudflare proxy и не спутать диагностику с решением

DNS only полезен как диагностический режим, но сам по себе не исправляет 522. Серое облако убирает reverse proxy Cloudflare из пути и отправляет клиента напрямую к origin.

Если Proxy ON даёт 522, а DNS only начинает работать, круг поиска резко сузился. Origin способен принимать прямые подключения, но что-то ломается именно в проксированной цепочке.

Это ещё не означает, что неисправен Cloudflare. Возможны:

• блокировка сетей Cloudflare на VPS;
• Fail2ban или CSF;
• ACL у провайдера;
• rate limiting;
• внешняя защита;
• ошибка в настройках origin.

Если не хочется менять публичный Proxy status, curl --resolve часто даёт достаточно информации и не затрагивает остальных посетителей.

DNS only заработал — это диагностический результат. Оставлять серое облако навсегда только потому, что «так открывается», не стоит: первопричина останется.

В каком порядке проверять Cloudflare 522 после миграции, чтобы не менять настройки наугад

При 522 после миграции идите от DNS к сети, затем к веб-серверу и только потом к приложению. Если одновременно поменять firewall, SSL Mode, Nginx и DNS, сайт может заработать, но причина останется неизвестной.

1. Зафиксируйте реальный IP нового VPS. IPv4 и, если используется, IPv6 origin.
2. Проверьте A/AAAA в Cloudflare DNS dashboard. Для Proxied-записей не путайте публичные адреса Cloudflare с origin.
3. Проверьте origin через curl --resolve. Если он напрямую не отвечает, Cloudflare пока исключаем из поиска.
4. Посмотрите LISTEN на 80/443. Команда ss -lntp должна показать фронтовый веб-сервис.
5. Проверьте порт извне. Локальный curl на VPS не заменяет внешний тест.
6. Проверьте системный и внешний firewall. UFW, firewalld, nftables, iptables, security group.
7. Сравните DNS only и Proxy ON. Если напрямую работает, а через Cloudflare нет, ищите фильтрацию Cloudflare → origin.
8. Откройте access/error logs. Нужно понять, дошёл ли запрос до Nginx/Apache.
9. При необходимости включите tcpdump. Смотрите не только наличие пакетов, но SYN, SYN-ACK и повторные передачи.
10. При плавающем 522 проверьте ресурсы и TCP-лимиты. CPU, RAM, I/O, OOM, connections, backlog, conntrack, workers.
11. Если остаётся подозрение на сеть, сравните внешний маршрут. mtr/traceroute — вспомогательный сигнал, а не доказательство пути Cloudflare.
12. Только после подтверждения TCP-пути разбирайте TLS. SSL Mode не должен быть первой настройкой при timeout.

curl --resolve не проходит — остаёмся на VPS. Проходит, но Proxy ON даёт 522 — проверяем доступ Cloudflare. SYN приходит, SYN-ACK не уходит — смотрим сервер и firewall. HTTP уже появился в access.log — сетевой этап пройден, можно идти к веб-стеку.

Что проверить перед повторным включением Cloudflare

Возвращать Proxy лучше после того, как новый origin стабильно проходит прямые проверки по HTTP и HTTPS. Иначе Cloudflare снова добавит промежуточный слой в ещё не исправленную схему.

Перед включением проверьте:

• A-запись в Cloudflare содержит IPv4 нового VPS.
• www ведёт на правильный сервер или корректный CNAME.
• AAAA содержит проверенный IPv6 origin либо отсутствует, если origin работает только по IPv4.
• Вы не принимаете публичные A/AAAA Proxied-записи за адрес origin.
• curl --resolve получает ответ от нового VPS.
• 80 доступен извне, если используется HTTP.
• 443 доступен извне для HTTPS.
• Nginx или Apache принимает соединения на правильном интерфейсе.
• nginx -t или apachectl configtest проходит без ошибок.
• Системный и внешний firewall не режут нужный трафик.
• Fail2ban, CSF и ACL не блокируют сети Cloudflare.
• При тесте в tcpdump видно нормальное установление TCP-соединения.
• VPS не упирается в CPU, RAM, I/O, backlog, conntrack или лимиты workers.
• HTTPS для нужного hostname корректно работает непосредственно на origin.

Включите Proxy и снова откройте основной домен, www, HTTPS и хотя бы один внутренний URL. Одновременно посмотрите access.log и error.log. Если запросы через Cloudflare приходят на новый VPS и сервер отвечает стабильно, основная цепочка восстановлена.

Если 522 вернётся позже, используйте уже известные контрольные точки. Прямой origin по-прежнему отвечает, но пакеты Cloudflare не появляются на сервере — смотрим сеть и фильтрацию. SYN приходит, а сервер перестал отвечать — проверяем firewall и TCP-лимиты. Запрос есть в access.log — идём к Nginx, upstream и ресурсам.

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