Как исправить ошибку 503 Backend Fetch Failed (Varnish)

Что означает ошибка 503 Backend Fetch Failed

Ошибка 503 Backend Fetch Failed от Varnish означает, что промежуточный кеш-сервер Varnish не смог корректно получить ответ от «бэкенда» — веб-сервера или приложения. Причины могут быть со стороны клиента (локальная сеть, браузер) или на стороне сервера (перегрузка, неверная конфигурация, сбой приложения).

Кратко о типичных причинах:

• Сервер находится на техническом обслуживании или отвечает с ошибкой.
• Локальный Adblocker или другое ПО блокирует ресурсы сайта.
• Недостаток памяти или ресурсов у бэкенда.
• Неверные настройки health check в Varnish или сопутствующих конфигурациях NGINX/NGINX-подобных.

Быстрая проверка перед исправлением

Перед выполнением более сложных действий выполните быстрые проверки:

• Откройте сайт в другом браузере или в режимe инкогнито. Иногда проблема локальна для конкретного профиля браузера.
• Нажмите F5 или Ctrl+F5, чтобы обновить страницу и пропустить кеш.
• Закройте лишние вкладки и перезапустите компьютер.

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

Шаги по устранению проблемы для пользователей и администраторов

Ниже — шаги, упорядоченные по простоте и по тому, кто обычно их выполняет (пользователь — frontend, администратор — backend).

1. Перезапустите маршрутизатор (для пользователей и администраторов)

1. Отключите модем и маршрутизатор от питания.
2. Подождите 15–30 секунд, затем включите модем.
3. Через 1–2 минуты включите маршрутизатор.
4. Дождитесь стабильного состояния индикаторов и повторно проверьте доступ к сайту.

Перезагрузка помогает очистить локальные сетевые проблемы и обновить DNS-кеш у оборудования.

2. Проверьте сетевое соединение через ping

1. Нажмите клавишу Windows, наберите cmd и выберите “Запуск от имени администратора”.

2. Выполните команду для проверки доступности публичного DNS Google:

ping 8.8.8.8

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

3. Очистите кеш браузера

1. Откройте настройки браузера (в примере — Google Chrome).

2. Перейдите в “Конфиденциальность и безопасность” → “Очистить данные просмотра”.

3. В диапазоне времени выберите “За всё время” и отметьте Cookies и Кэшированные изображения и файлы.

4. Нажмите “Очистить данные”.

Очистка кеша помогает, если браузер хранит повреждённые или устаревшие ресурсы, из-за которых страница не загружается корректно.

4. Сбросьте настройки браузера

1. Откройте настройки браузера.

2. Перейдите в раздел “Сброс настроек”.

3. Нажмите “Восстановить настройки по умолчанию” и подтвердите.

Этот шаг полезен, когда сайт работает в другом браузере, но не в вашем.

5. Переактивируйте плагин Varnish в панели управления (для администраторов)

1. Войдите в панель управления сайта.
2. Перейдите в “Web Accelerator” → “Manage Varnish”.
3. Нажмите “Disable Varnish” и подтвердите, затем снова “Enable Varnish”.

Иногда простое отключение и повторное включение Varnish решает проблемы, связанные с внутренними ошибками плагина.

6. Проверьте и измените конфигурации Varnish и NGINX (для администраторов)

1. Откройте файл Varnish: /etc/varnish/default.vcl с правами администратора.
2. Найдите probe, который проверяет health check. Если он указывает на “/pub/health_check.php”, попробуйте удалить “/pub” или, наоборот, добавить его, в зависимости от структуры сайта.

Пример изменения:

.probe = {
  .url = "/health_check.php";
}

3. В файле конфигурации NGINX (например, nginx.conf.sample в корне Magento 2) найдите правило location для PHP и добавьте health_check в список:

location ~ (index|get|static|report|404|503|health_check)\.php$ {
  # существующие директивы
}

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

sudo systemctl restart nginx
sudo systemctl restart varnish

Изменение путей health check полезно, если бэкенд возвращает 404/503 на ожидаемый URL проверки.

7. Измените лимиты буферов и заголовков Varnish (для администраторов)

1. Откройте конфигурационный файл сервиса Varnish: /etc/default/varnish
2. Если присутствует параметр http_resp_hdr_len, установите значение 70000. Если его нет, добавьте строку с флагами запуска:

-p http_resp_hdr_len=70000 \
-p http_resp_size=100000 \

3. Сохраните файл и перезапустите Varnish.

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

Дополнительная методология для администраторов: пошаговый SOP

1. Проверка уровня сервиса: убедитесь, что веб-сервер (PHP-FPM, Apache, NGINX) ответил на локальные запросы на хосте. Используйте curl.

curl -I http://127.0.0.1/health_check.php

2. Логи: проверьте логи NGINX, Varnish и приложения (error.log, varnishlog, syslog).
3. Ресурсы: проверьте нагрузку CPU, свободную память и дескрипторы:

top
free -h
ss -s

4. Конфигурации: сверяйтесь с актуальными health check URL, таймаутами и размерами буферов.
5. Тестирование: после правок сначала применяйте их в тестовом окружении.
6. Откат: сохраняйте резервные копии конфигурационных файлов перед изменениями.

Чек-лист: что сделать сначала (быстрый список)

Для пользователей:

• Перезагрузить маршрутизатор.
• Попробовать другой браузер или режим инкогнито.
• Очистить кеш и cookies.
• Сбросить настройки браузера.

Для администраторов:

• Проверить доступность бэкенда локально.
• Просмотреть логи Varnish и NGINX.
• Подтвердить корректность health check URL.
• Увеличить http_resp_hdr_len и http_resp_size при необходимости.
• Перезапустить Varnish и NGINX после изменений.

Когда эти шаги не помогут

• Если сайт недоступен у многих пользователей и вы видите ошибки 5xx в логах — вероятно, проблема в приложении или инфраструктуре (перегрузка, падение сервиса баз данных). В этом случае нужно вовлекать команду бэкенда или хостинг-провайдера.
• Если ошибка появляется по таймеру (например, в пиковые часы) — это может быть нехватка ресурсов (CPU, память) или атакa (DDoS). Решения: масштабирование, rate limiting, WAF.
• Если вы не администратор сайта — обратитесь к администратору и при необходимости предоставьте результаты проверок (логи, время и пример URL).

Риски и меры предосторожности

• Всегда делайте бэкап конфигурационных файлов перед изменением.
• Тестируйте изменения сначала в staging-среде.
• Изменение параметров памяти и размеров заголовков может скрыть корневую проблему (не устраняет утечки памяти или баги приложения).

Короткий глоссарий

• Varnish — обратный прокси-кеш, ускоряет отдачу контента.
• Бэкенд — сервер приложения или веб-сервер, который обрабатывает запросы.
• Health check — проверка доступности бэкенда для балансировщика или кеша.

Критерии приёмки

• Страница загружается у клиента без ошибки 503 при повторных проверках.
• Логи Varnish и NGINX не содержат ошибок, связанных с таймаутами или ошибками соединения.
• Изменения проверены в тестовой среде и задокументированы.

Заключение

Ошибка 503 Backend Fetch Failed — распространённая проблема, которую можно диагностировать на двух уровнях: клиентском и серверном. Для пользователей достаточно базовых шагов (перезагрузка, очистка кеша, смена браузера). Для администраторов нужны проверки бэкенда, логов и конфигураций Varnish/NGINX, а также корректная настройка health check и параметров памяти. Если простые методы не помогают, соберите логи и обратитесь к хостинг-провайдеру или к разработчикам приложения.

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

Если у вас остались вопросы или вы хотите, чтобы мы посмотрели пример конфигурации — опубликуйте релевантные фрагменты логов и конфигурации в комментариях.