Wêrom't in shell-proxykontrôle mislearre bliuwt nei't curl slagget

Foarkom dat in âlde curl-flater yn in shell-fariabele bliuwt neidat lettere proxykontrôles slagje.

De proxy mislearret ien kear. Lettere oanfragen slagje, mar de wachter bliuwt in nije flater oankundigjen. Kontrolearje oft it skript de útgongsstatus fan juster ûnthâlden hat.

Dit patroan wurket de fariabele allinnich by as curl mislearret:

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

Nei it earste net-nul resultaat lit in slagge iteratie status ûnoantaast. It wurdt net nul allinnich om't curl slagge.

Fertakke ynstee op it hjoeddeiske 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

It adres en de tiden binne yllustratyf. Dit ferwideret de ferâldere fariabele; it beslút net hokker herstelaksje passend is.

Hâld de waarnimming smel. De oanfraach hinget ôf fan de proxy, de fierdere rûte, de bestimming, TLS-ferifikaasje en de HTTP-útkomst. In steuring by it doel kin it mislearje litte wylst de SOCKS-tsjinst sûn is. In ûnferwachte HTTP 200-side kin ek in kontrôle op basis fan status allinnich helje sûnder de ferwachte ynhâld te leverjen.

Kies in behearst antwurdkontrakt en behâld de flaterfase. De proxy opnij starte by elk net-nul curl-resultaat kin sûne sesjes fersteure, wylst it echte bestimmingsprobleem ûnoantaast bliuwt.

Relatearre artikelen