Squid retry_on_error: коды состояния и альтернативные маршруты

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

В выпусках, поддерживающих эту директиву, она по умолчанию отключена. Документированный список повторов — 403, 500, 501, 502, 503 и 504, и запрос пробуется через другое работающее назначение. Это особенно важно в иерархии с альтернативными путями пересылки. Это не просто повторная попытка того же сокета к тому же серверу по таймеру.

Сначала назовите сбой

Отказ при подключении к прокси, сбой аутентификации прокси, ошибка HTTP от источника и ответ, оборванный после начала доставки, не дают одинаковой возможности повтора. Не ждите, что одна настройка обработает все четыре одинаково.

Для частного выхода также решите, приемлем ли альтернативный путь. У другого родителя может быть другой публичный адрес источника, политика аутентификации или сетевое расположение. Успех через эту альтернативу может нарушить причину, по которой был выбран первый родитель.

Операции приложения добавляют ещё одну заботу: повтор запроса может повторить его эффект. Клиенту и серверу нужна надлежащая семантика повторов, особенно для операций, создающих или изменяющих данные. Настройка прокси не заменяет обработку неопределённых результатов на уровне приложения.

Прочитайте директиву для вашего точного выпуска; справочник перечисляет доступность и поведение по умолчанию. Учитывайте также сроки запросов и общее видимое пользователю ожидание. Дополнительная попытка пересылки может израсходовать оставшееся время, не дав лучшего результата.

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