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

Что такое ошибка 522 Cloudflare

Ошибка 522 (Connection Timed Out) возникает, когда серверы Cloudflare не могут установить TCP-соединение с вашим исходным веб-сервером. Cloudflare успешно разрешает доменное имя, но при попытке подключиться к IP-адресу сервера тот не отвечает на SYN-пакет в течение 20–30 секунд.

Это проблема на стороне сервера или сети, а не у пользователя. Пользователи видят стандартную страницу Cloudflare с надписью "Error 522: Connection timed out".

Диаграмма TCP-соединения между Cloudflare и сервером, завершающегося ошибкой 522

Основные причины

Ошибка 522 означает, что пакеты от Cloudflare не доходят до сервера или сервер не отвечает на них. Распространённые причины:

1. Сервер выключен или не слушает порты. Веб-сервер (nginx, Apache) не запущен, или служба завершилась аварийно.
2. Брандмауэр блокирует Cloudflare. Правила iptables, ufw, firewalld или облачные Security Groups не разрешают трафик с IP-адресов Cloudflare на порты 80/443.
3. Высокая нагрузка на сервер. CPU или RAM исчерпаны, ядро системы не обрабатывает новые сетевые подключения.
4. Проблемы с сетью или маршрутизацией. Сбои у хостинг-провайдера, неверные маршруты или блокировка на уровне сети.
5. Неправильная конфигурация виртуального хостинга. Ограничения в cPanel/Plesk, блокирующие определённые IP.
6. Агрессивные системы защиты. fail2ban или аналоги могут заблокировать IP Cloudflare, ошибочно приняв его за источник атаки.

Пошаговое решение

Выполняйте шаги последовательно, начиная с самых быстрых проверок.

1. Проверьте, работает ли сервер

Подключитесь к серверу по SSH и выполните:

# Проверьте статус веб-сервера
systemctl status nginx   # Для nginx
systemctl status apache2 # Для Apache на Ubuntu
systemctl status httpd   # Для Apache на CentOS

Если служба не активна (inactive), запустите её:

sudo systemctl start nginx

Убедитесь, что порты 80 и 443 слушаются:

sudo ss -tulpn | grep -E ':(80|443)'

В выводе должен быть процесс (nginx, apache) в состоянии LISTEN. Проверьте локальный доступ:

curl -I http://localhost
curl -I https://localhost

Если команды возвращают заголовки (например, HTTP/1.1 200 OK), сервер работает локально.

2. Настройте брандмауэр для IP Cloudflare

Cloudflare использует фиксированные диапазоны IP-адресов. Их необходимо явно разрешать.

1. Получите актуальные списки IP на официальной странице Cloudflare. Скопируйте IPv4 и IPv6 диапазоны.
2. Для ufw (Ubuntu/Debian):

   # Разрешите все диапазоны Cloudflare на порты 80/443
   sudo ufw allow from 2400:cb00::/32 to any port 443 proto tcp
   sudo ufw allow from 2400:cb00::/32 to any port 80 proto tcp
   # ... добавьте остальные диапазоны IPv4 и IPv6
   sudo ufw reload
   

3. Для firewalld (CentOS/RHEL/Fedora):

   sudo firewall-cmd --permanent --add-source=2400:cb00::/32
   sudo firewall-cmd --permanent --add-service=http
   sudo firewall-cmd --permanent --add-service=https
   sudo firewall-cmd --reload
   

4. Проверьте настройки облачного провайдера. В AWS, Google Cloud, Azure убедитесь, что Security Groups или Firewall Rules разрешают входящий трафик на порты 80/443 и не блокируют источники Cloudflare.

3. Проанализируйте нагрузку на сервер

Перегруженный сервер не отвечает на новые соединения.

1. Установите htop, если её нет:

   sudo apt install htop   # Ubuntu/Debian
   sudo yum install htop   # CentOS/RHEL
   

2. Запустите htop и оцените:
   • CPU%: Постоянная загрузка близка к 100% — сервер не справляется.
   • MEM%: Полное использование RAM и активный SWAP — критично.
   • Tasks: Необычно высокое количество процессов может указывать на атаку.
3. Найдите "тяжёлые" процессы. В htop нажмите F6 и отсортируйте по %CPU или %MEM. Частые виновники: PHP-FPM (для WordPress), MySQL, фоновые скрипты.
4. Временно перезапустите проблемные службы (например, sudo systemctl restart php-fpm). Но это временная мера — ищите источник нагрузки в логах.

4. Отключите Cloudflare для диагностики

Этот шаг определяет, связана ли проблема с Cloudflare.

1. Войдите в панель Cloudflare.
2. Выберите домен и перейдите в раздел DNS.
3. Найдите запись A или AAAA, указывающую на IP вашего сервера.
4. Нажмите на иконку облачка, чтобы оно стало серым (режим "DNS only"). Cloudflare перестаёт проксировать трафик.
5. Через 1–2 минуты попробуйте открыть сайт.
   • Сайт заработал: Проблема в соединении между Cloudflare и сервером (пункты 1–3).
   • Сайт не работает: Проблема на сервере или в сети провайдера. Проверьте логи веб-сервера (/var/log/nginx/error.log, /var/log/apache2/error.log).
6. После теста верните облачко в оранжевый цвет.

5. Проверьте таймауты веб-сервера

Слишком низкие значения таймаутов могут приводить к разрыву соединений.

• Для nginx: в /etc/nginx/nginx.conf или конфиге сайта:

  http {
      keepalive_timeout 65; # Увеличьте при необходимости
  }
  

  
  Проверьте синтаксис (sudo nginx -t) и перезагрузите (sudo systemctl reload nginx).
• Для Apache: в /etc/apache2/apache2.conf или /etc/httpd/httpd.conf:

  KeepAliveTimeout 10
  Timeout 30
  

  
  Увеличьте значения, если они слишком малы.
• Убедитесь, что worker_processes (nginx) или MaxRequestWorkers (Apache) не установлены в крайне низкие значения.

Профилактика ошибки 522

• Мониторьте доступность сервера. Используйте UptimeRobot или StatusCake для проверок с разных локаций.
• Разрешайте IP Cloudflare на всех уровнях. При смене хостинга или настройке нового брандмауэра сразу добавляйте диапазоны с cloudflare.com/ips.
• Оставляйте запас ресурсов. Не загружайте сервер на 100% по CPU и RAM. Запас в 20–30% поможет обрабатывать пики.
• Используйте статический IP-адрес. Динамические IP могут нарушить работу Cloudflare и брандмауэра.
• Синхронизируйте таймауты. Убедитесь, что значения в веб-сервере, PHP (max_execution_time) и приложении согласованы.
• Регулярно проверяйте логи. Просматривайте /var/log/nginx/error.log, /var/log/syslog на предмет сетевых ошибок и блокировок.