Чому перевірка проксі в оболонці залишається невдалою після успіху curl

Уникайте збереження старої помилки curl у змінній оболонки після того, як наступні перевірки проксі успішні.

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

Цей шаблон оновлює змінну лише тоді, коли curl збоїть:

status=0
# Repeated inside a loop:
curl ... || status=$?

Після першого ненульового результату успішна ітерація залишає status без змін. Він не стає нулем лише тому, що curl вдався.

Натомість розгалужуйтеся за поточною командою:

if curl --proxy socks5h://127.0.0.1:1080 --noproxy '' \
    --fail --silent --show-error --connect-timeout 3 --max-time 10 \
    https://health.example/ >/dev/null; then
    echo "check succeeded"
else
    echo "check failed"
fi

Адреса й тайм-аути наведені для прикладу. Це прибирає застарілу змінну; це не вирішує, яка дія відновлення доречна.

Тримайте спостереження вузьким. Запит залежить від проксі, подальшого маршруту, призначення, перевірки TLS і результату HTTP. Збій на боці цілі може провалити його, хоча служба SOCKS здорова. Неочікувана сторінка HTTP 200 також може пройти перевірку лише за статусом, не надавши очікуваний вміст.

Виберіть контрольований контракт відповіді й зберігайте етап збою. Перезапуск проксі після кожного ненульового результату curl може порушити здорові сеанси, а справжня проблема призначення залишиться недоторканою.

Схожі статті