Встреча с сообщением «Error 520: Web server is returning an unknown error» (Веб-сервер возвращает неизвестную ошибку) — это одна из самых неприятных ситуаций для владельцев сайтов, разработчиков и обычных пользователей. В отличие от стандартных кодов состояния HTTP (например, 404 или 500), код 520 является проприетарным кодом компании Cloudflare. Он сигнализирует о том, что промежуточный слой (Cloudflare) успешно соединился с вашим исходным сервером (origin server), но получил от него ответ, который невозможно интерпретировать.

В этой статье мы подробно разберем, что означает эта ошибка, почему она возникает, как ее исправить владельцу сайта и что может сделать обычный посетитель.

Содержание

1. Что такое ошибка 520 и как работает Cloudflare
2. Различие между ошибками 5xx семейства Cloudflare
3. Основные причины возникновения Error 520
4. Пошаговое устранение для владельцев сайтов и разработчиков
5. Что может сделать посетитель сайта
6. Влияние на SEO и сканеров
7. Профилактика: как предотвратить повторное появление

Что такое ошибка 520 и как работает Cloudflare

Чтобы понять суть ошибки, нужно представить путь запроса:

1. Пользователь вводит URL в браузере.
2. Запрос попадает в сеть Cloudflare (CDN/WAF).
3. Cloudflare проксирует запрос на исходный сервер (ваш хостинг, VPS, сервер приложений).
4. Исходный сервер обрабатывает запрос и отправляет ответ обратно в Cloudflare.
5. Cloudflare передает ответ пользователю.

Ошибка 520 возникает на этапе 4–5. Исходный сервер получил запрос и попытался ответить, но формат этого ответа нарушает протокол HTTP настолько сильно, что Cloudflare не может его распарсить. Это может быть:

• Пустой ответ (отсутствие заголовков и тела).
• Обрезанные заголовки (соединение разорвано до отправки ).
• Невалидные заголовки (отсутствует Content-Type, некорректный Content-Length, наличие недопустимых символов).
• Ответ, не соответствующий запросу (например, сервер прислал бинарные данные вместо HTTP-заголовков).

Главный вывод: Сервер доступен, сеть работает, DNS настроен верно. Проблема — в логике приложения или конфигурации веб-сервера, которые портят HTTP-ответ.

Различие между ошибками 5xx семейства Cloudflare

Cloudflare использует собственные коды 5xx для обозначения проблем на стороне происхождения. Путаница между ними стоит времени при отладке.

Наличие именно 520 сужает круг поиска: исключаем DNS, сетевую маршрутизацию и полные отключения. Фокусируемся на уровне приложения (PHP, Python, Node.js, Java, Nginx/Apache config).

Основные причины возникновения Error 520

Нет единственной причины, это симптом. Вот рейтинг самых частых виновников:

Критические ошибки приложения (Crashes / Uncaught Exceptions) — Причина №1

Скрипт (PHP-FPM, Node.js process, Python worker) начинает генерировать ответ, отправляет заголовки, а затем падает с фатальной ошибкой (Segmentation Fault, Out Of Memory, Uncaught Exception). Веб-сервер (Nginx/Apache) не успевает отправить завершающие символы ответа или отправляет обрезанный поток.

Превышение лимитов размера заголовков

• Cloudflare лимит: ~16 КБ на сумму всех заголовков ответа.
• Nginx/Apache лимиты: large_client_header_buffers (Nginx), LimitRequestFieldSize (Apache).
• Если ваше приложение устанавливает кучу куков (Set-Cookie) или огромные кастомные заголовки, ответ будет отброшен.

Конфликт WAF / ModSecurity / Fail2Ban на исходном сервере

Если на вашем сервере стоит собственный WAF (ModSecurity, Naxsi) или системный файрвол (iptables/ufw с правилами DDoS), он может резать ответ «на лету», обнаружив в теле ответа подозрительные паттерны (SQL-инъекции, XSS-векторы), даже если это легальный контент. Результат — обрезанный невалидный HTTP-пакет.

Невалидный формат ответа (Header Injection / Binary Output)

• BOM (Byte Order Mark) в начале PHP-файлов.

Проблемы с проксированием и Upstream (Nginx -> PHP-FPM / Node.js)

Если Nginx работает как реверс-прокси к бэкенду (FastCGI, uWSGI, proxy_pass):

• Бэкенд упадет после отправки заголовков.
• Неверная настройка fastcgi_buffering / proxy_buffering.
• Бэкенд вернул HTTP/1.0 без Content-Length и не закрыл соединение (chunked encoding не поддерживается).

IPv6 конфликты

Cloudflare подключается к вашему серверу по IPv6 (если есть AAAA-запись), но ваш веб-сервер слушает только IPv4 или IPv6-файрвол режет трафик. Соединение устанавливается, но данные не проходят корректно.

Пошаговое устранение для владельцев сайтов и разработчиков

Шаг 1: Включите «Development Mode» и «Pause Cloudflare»

В панели Cloudflare (Overview -> Advanced Actions) нажмите Pause Cloudflare (оранжевое облачко становится серым) или включите Development Mode. Это заставит запросы идти напрямую на ваш сервер, минуя Cloudflare.

• Ошибка воспроизводится напрямую? Проблема 100% на вашем сервере (логи PHP, Nginx, приложения).
• Ошибки нет напрямую, но есть через Cloudflare? Проблема в взаимодействии Cloudflare <-> Origin (заголовки, IPv6, WAF Cloudflare, MTU).

Шаг 2: Анализ логов исходного сервера (Самое важное)

Смотрите не только access.log, но и error.log.

• Nginx/Apache error.log: ищите upstream prematurely closed connection, segfault, OOM killer, permission denied.
• PHP-FPM / PHP error_log: Fatal error, Allowed memory size exhausted, Maximum execution time exceeded.
• Application logs (Laravel, Symfony, Django, Express): стек-трейсы (stack traces) в storage/logs, var/log.

Шаг 3: Проверка заголовков ответа (cURL)

Выполните запрос напрямую к IP сервера (обходите DNS), передав Host-

curl -v -H "Host: yourdomain.com" http://YOUR_SERVER_IP/

Смотрите на вывод < HTTP/1.1 ... и заголовки. Если соединение разрывается посередине заголовков — это 520.

Шаг 4: Проверка лимитов заголовков

Nginx: Увеличьте буферы в блоке http или server:

large_client_header_buffers 8 16k; # или 32k

Cloudflare: Лимит 16КБ жесткий. Если у вас много куков — оптимизируйте их (domain, path, secure, httponly), перенесите данные в сессию/БД.

Шаг 5: Отключение серверного WAF / ModSecurity (тестово)

Если стоит ModSecurity — поставьте SecRuleEngine DetectionOnly или полностью отключите на время теста. Часто правила OWASP CRS блокируют легальные ответы админок или API.

Шаг 6: Проверка IPv6

Если у домена есть AAAA-запись, но сервер не слушает IPv6 порт 80/443 — Cloudflare будет получать 520/522. Решения:

1. Настроить Nginx/Apache на listen [::]:443 ssl;.
2. Или удалить AAAA-запись из DNS Cloudflare (оставить только A).

Шаг 7: Проверка на «тихие» ошибки PHP (Whitespace / BOM)

Откройте index.php и ключевые файлы входа. Убедитесь, что:

• Нет пробелов/переводов строк перед <?php.
• Нет закрывающего тега ?> в конце файлов (best practice).
• Кодировка файлов, UTF-8 без BOM.

Что может сделать посетитель сайта

Если вы не владелец сайта, а просто пользователь:

1. Обновите страницу (F5 / Ctrl+R). Часто это единичный сбой (race condition);
2. Очистите кэш браузера и куки для этого домена. Старые куки могут раздуть запроса выше лимита Cloudflare.
3. Попробуйте другой браузер / режим инкогнито / другое устройство. Исключает локальные расширения (адблокеры, VPN, антивирусы), ломающие заголовки.
4. Подождите 5–15 минут. Админы, скорее всего, уже получили алерт и чинят.
5. Напишите в поддержку сайта (через соцсети, email), указав время, часовой пояс и Ray ID (на странице ошибки Cloudflare внизу написано: Ray ID: 8a1b2c3d4e5f6789). Это ускорит поиск в логах.

Влияние на SEO и сканеров

Ошибка 520 критична для SEO по нескольким причинам:

• Googlebot / Yandex Bot получают 5xx. Если ошибка системная и длительная, страницы выпадают из индекса или снижаются в ранжировании (сигнал «сайт сломан»).
• Crawl Budget тратится впустую. Робот тратит лимит сканирования на получение ошибок вместо контента.
• Скреперы и мониторинги (UptimeRobot, Pingdom) часто получают 520 чаще людей, так как делают запросы без куков/JS, что может триггерить другие ветки кода на сервере.

Рекомендация: Настройте алертинг (Telegram, Email, PagerDuty) на код 520 в логах Nginx/Cloudflare Logpush, чтобы узнавать о проблеме за минуты, а не за дни из Search Console.

Профилактика: как предотвратить повторное появление

1. Мониторинг здоровья приложения (Health Checks). Настройте эндпоинт /health, который проверяет БД, Redis, диск, внешние API. Cloudflare Load Balancer или внешний мониторинг (Better Uptime, Uptime Kuma) будут снимать трафик с ноды до восстановления.
2. Graceful Shutdown / Reload. Настройте PHP-FPM (process_control_timeout), Nginx (worker_shutdown_timeout), Node.js (сигналы SIGTERM) на корректное завершение текущих запросов при деплое.
3. Лимиты ресурсов. Жестко лимить memory_limit в PHP, --max-old-space-size в Node.js. Настройте OOM Score Adj, чтобы ядро убивало воркеры аккуратно, а не весь мастер-процесс.
4. Логирование в структурированном формате (JSON). Парсьте логи ELK / Loki / ClickHouse. Настройте алерт на паттерн upstream prematurely closed connection в логах Nginx.
5. Тестирование деплоя в Staging с нагрузочным тестом (k6, Locust). Ловите утечки памяти и краши под нагрузкой до продакшена.
6. Whitelist IP Cloudflare на файрволе сервера. Обязательно разрешите все подсети Cloudflare (https://www.cloudflare.com/ips/) на портах 80/443. Иначе получите 521/522, но иногда файрвол режет не SYN, а данные — получается 520.

Краткая шпаргалка (Cheatsheet)

• 520 = «Сервер ответил мусором».
• Сначала: Pause Cloudflare -> проверить прямо на сервере.
• Логи: error.log бэкенда (PHP/Node/Python) — главный источник правды.
• Частые виновники: OOM, Segfault, большие заголовки (Set-Cookie), ModSecurity, BOM/пробелы в PHP.
• Проверь IPv6 (AAAA запись vs listen [::]).
• Настрой алерты на 5xx в реальном времени.

Ошибка 520 пугает своей неопределенностью («Unknown Error»), но на практике она всегда указывает на конкретный сбой в коде приложения или конфигурации веб-сервера. Системный подход к логированию и мониторингу позволяет находить и устранять причину за минуты.