Waarom een shell-proxycontrole mislukt blijft nadat curl slaagt

Voorkom dat een oude curl-fout in een shell-variabele blijft staan nadat latere proxycontroles slagen.

De proxy faalt één keer. Latere verzoeken slagen, maar de bewaking blijft een nieuwe fout melden. Controleer of het script de exitstatus van gisteren onthield.

Dit patroon werkt de variabele alleen bij wanneer curl faalt:

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

Na het eerste niet-nulresultaat laat een geslaagde iteratie status ongemoeid. Het wordt niet nul alleen omdat curl slaagde.

Vertak in plaats daarvan op de huidige opdracht:

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

Het adres en de tijden zijn ter illustratie. Dit verwijdert de verouderde variabele; het bepaalt niet welke herstelactie passend is.

Houd de waarneming smal. Het verzoek hangt af van de proxy, de verdere route, de bestemming, TLS-verificatie en de HTTP-uitkomst. Een storing bij het doel kan het laten mislukken terwijl de SOCKS-dienst gezond is. Een onverwachte HTTP 200-pagina kan ook een controle op alleen status doorstaan zonder de verwachte inhoud te leveren.

Kies een beheerst responscontract en behoud de faalfase. De proxy herstarten bij elk niet-nul curl-resultaat kan gezonde sessies verstoren terwijl het echte bestemmingsprobleem onaangeroerd blijft.

Gerelateerde artikelen