Dlaczego kontrola proxy w powłoce pozostaje nieudana, gdy curl się udaje

Unikaj pozostawiania starego błędu curl w zmiennej powłoki po tym, jak późniejsze kontrole proxy się udadzą.

Proxy zawodzi raz. Późniejsze żądania się udają, ale nadzorca wciąż ogłasza kolejną awarię. Sprawdź, czy skrypt zapamiętał wczorajszy kod wyjścia.

Ten wzorzec aktualizuje zmienną tylko wtedy, gdy curl zawiedzie:

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

Po pierwszym niezerowym wyniku udana iteracja pozostawia status bez zmian. Nie staje się zerem tylko dlatego, że curl się udał.

Zamiast tego rozgałęź się na bieżącym poleceniu:

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

Adres i czasy są przykładowe. To usuwa nieaktualną zmienną; nie rozstrzyga, jakie działanie naprawcze jest właściwe.

Utrzymuj obserwację wąską. Żądanie zależy od proxy, dalszej trasy, miejsca docelowego, weryfikacji TLS i wyniku HTTP. Awaria celu może je zablokować, gdy usługa SOCKS jest zdrowa. Nieoczekiwana strona HTTP 200 również może przejść kontrolę opartą tylko na statusie, nie dostarczając oczekiwanej treści.

Wybierz kontrolowany kontrakt odpowiedzi i zachowaj etap awarii. Restartowanie proxy przy każdym niezerowym wyniku curl może zakłócać zdrowe sesje, podczas gdy rzeczywisty problem celu pozostaje nietknięty.

Powiązane artykuły