Hvorfor en shell-proxykontrol bliver ved med at fejle, når curl lykkes

Proxyen fejler én gang. Senere forespørgsler lykkes, men overvågningen fortsætter med at melde endnu en fejl. Kontroller, om scriptet huskede gårsdagens exitstatus.

Dette mønster opdaterer kun variablen, når curl fejler:

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

Efter det første ikke-nul-resultat lader en vellykket iteration status være urørt. Det bliver ikke nul, blot fordi curl lykkedes.

Forgren dig i stedet på den aktuelle kommando:

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 tiderne er illustrative. Dette fjerner den forældede variabel; det afgør ikke, hvilken gendannelseshandling der er passende.

Hold iagttagelsen snæver. Forespørgslen afhænger af proxyen, den videre rute, destinationen, TLS-verifikationen og HTTP-resultatet. Et udfald hos målet kan få den til at fejle, mens SOCKS-tjenesten er sund. En uventet HTTP 200-side kan også bestå en kontrol, der kun ser på status, uden at levere det forventede indhold.

Vælg en kontrolleret svarkontrakt, og bevar fejlstadiet. Genstart af proxyen ved hvert ikke-nul curl-resultat kan forstyrre sunde sessioner, mens det egentlige destinationsproblem forbliver urørt.