Apache Error: AH00959: ap_proxy_connect_backend disabling worker for (127.0.0.1) Linux / DevOps

Apache Error AH00959: disabling worker for backend — Решение

Обновлено: 18.08.2026 · Официальная база знаний

После единичного сбоя upstream-сервера Apache полностью прекращает отправку любых клиентских запросов на этот бэкенд в течение 60 секунд. В системном журнале error.log фиксируется блокировка ноды: [proxy:error] [pid 1234:tid 5678] AH00959: ap_proxy_connect_backend disabling worker for (127.0.0.1) for 60s или AH01114: HTTP: failed to make connection to backend: 127.0.0.1.

Параметр mod_proxy	Значение по умолчанию	Следствие для трафика
`retry`	`60 seconds`	Нода изолируется от трафика на 1 минуту после 1 сбоя
`status` воркера	`Dis (Disabled)`	Клиенты получают мгновенный 503 без попытки подключения к бэкенду
Одиночный бэкенд	Единственная точка входа	Полная недоступность сайта даже после быстрого рестарта бэкенда

Все последующие запросы к сайту моментально возвращают 503 Service Unavailable, даже если бэкенд уже успешно запустился.
Администратору приходится вручную перезапускать Apache, чтобы сбросить счетчик блокировки.

Откройте конфигурационный файл с настройками проксирования виртуального хоста.

Добавьте параметр retry=0 в директиву ProxyPass для целевого бэкенда или каждого участника балансировочного пула:

# Для прямого проксирования (отключаем 60-секундный бан ноды):
ProxyPass / http://127.0.0.1:8080/ retry=0 timeout=30
ProxyPassReverse / http://127.0.0.1:8080/

Если используется кластер balancer://, настройте параметры восстановления воркеров:

<Proxy balancer://mycluster>
    BalancerMember http://10.0.1.10:8080 retry=5 status=+H
    BalancerMember http://10.0.1.11:8080 retry=5
    ProxySet lbmethod=byrequests
</Proxy>

Устраните первопричину сбоя соединения (ошибку AH00957 или AH00898), из-за которой сработал защитный механизм.
Проверьте валидность файла конфигурации: sudo apache2ctl configtest # или httpd -t.
Примените настройки без прерывания соединений: sudo systemctl reload apache2 # или httpd.

Архитектурный смысл retry: Механизм временного отключения воркера (disabling worker) был разработан для балансировщиков из нескольких серверов, чтобы не тратить время клиентов на опрос заведомо мертвой ноды. Однако для схем с одним бэкендом параметр по умолчанию retry=60 является деструктивным.

Практический опыт инженера: Всегда прописывайте `retry=0` при локальном проксировании на `127.0.0.1` (PHP-FPM socket, Gunicorn, Puma), иначе короткий перезапуск бэкенда в 0.1 секунды оставит сайт лежащим на целую минуту.

Частые вопросы (FAQ)

Что делает параметр retry=0 в ProxyPass?

retry=0 указывает Apache не банить упавший бэкенд на 60 секунд, а совершать новую попытку подключения при каждом следующем входящем HTTP-запросе.

Как сбросить состояние отключенного воркера без перезапуска Apache?

Если включен интерфейс mod_proxy_balancer (balancer-manager), администратор может зайти в веб-интерфейс управления и вручную переключить статус воркера из 'Dis' в 'Init/Ok'.

Какое оптимальное значение retry для отказоустойчивых кластеров?

Для пулов балансировки рекомендуется выставлять retry=5 или retry=10, чтобы бэкенд возвращался в ротацию через 5-10 секунд после восстановления.

Считаются ли HTTP ответы 500 поводом для отключения воркера?

По умолчанию нет. Воркер отключается только при сетевых сбоях TCP уровня (Connection refused, Connection timed out) и фатальных ошибках HTTP заголовков.