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

У Squid є параметр із назвою retry_on_error, але назва ширша за корисне тлумачення. Він не означає, що кожен невдалий запит повторюватиметься безкінечно, доки сторінка не запрацює.

У випусках, які підтримують цю директиву, вона вимкнена за замовчуванням. Задокументований список повторів — 403, 500, 501, 502, 503 і 504, і запит пробується через інше робоче призначення. Це особливо важливо в ієрархії з альтернативними шляхами пересилання. Це не просто повторна спроба того самого сокета до того самого сервера за таймером.

Спочатку назвіть збій

Відмова під час підключення до проксі, збій автентифікації проксі, помилка HTTP від джерела та відповідь, обірвана після початку доставки, не дають однакової можливості повтору. Не очікуйте, що одне налаштування обробить усі чотири однаково.

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

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

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

Досліджуючи періодичні збої, записуйте стан, вибраного батька або призначення та послідовність спроб. Інакше повтори можуть зробити повторювану проблему маршрутизації схожою на загалом повільний сайт, приховуючи шлях, який насправді не вдався.