Hvorfor en shell-proxykontroll blir stående som mislykket etter at curl lykkes

Proxyen feiler én gang. Senere forespørsler lykkes, men overvåkingen fortsetter å melde om enda en feil. Sjekk om skriptet husket gårsdagens exit-status.

Dette mønsteret oppdaterer bare variabelen når curl feiler:

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

Etter det første ikke-null-resultatet lar en vellykket iterasjon status stå urørt. Det blir ikke null bare fordi curl lyktes.

Forgren deg i stedet på den gjeldende kommandoen:

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

Adressen og tidsangivelsene er illustrative. Dette fjerner den utdaterte variabelen; det avgjør ikke hvilken gjenopprettingshandling som er riktig.

Hold observasjonen smal. Forespørselen avhenger av proxyen, den videre ruten, målet, TLS-verifiseringen og HTTP-resultatet. Et avbrudd hos målet kan få den til å feile mens SOCKS-tjenesten er frisk. En uventet HTTP 200-side kan også bestå en kontroll som bare ser på status, uten å levere det forventede innholdet.

Velg en kontrollert svarkontrakt og behold feilsteget. Å starte proxyen på nytt ved hvert ikke-null curl-resultat kan forstyrre friske økter, mens det egentlige målproblemet forblir urørt.