Zakaj preverjanje proxyja v lupini ostane neuspešno, ko curl uspe

Izogibajte se ohranjanju stare napake curl v spremenljivki lupine, potem ko naslednja preverjanja proxyja uspejo.

Proxy enkrat odpove. Kasnejše zahteve uspejo, a nadzornik še naprej sporoča novo napako. Preverite, ali si je skript zapomnil včerajšnji izhodni status.

Ta vzorec posodobi spremenljivko le, kadar curl odpove:

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

Po prvem rezultatu, ki ni nič, uspešna ponovitev pusti status nedotaknjeno. Ne postane nič samo zato, ker je curl uspel.

Namesto tega se razvejite glede na trenutni ukaz:

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

Naslov in časi so ponazoritveni. To odstrani zastarelo spremenljivko; ne odloči, kateri ukrep obnovitve je primeren.

Naj bo opazovanje ozko. Zahteva je odvisna od proxyja, nadaljnje poti, cilja, preverjanja TLS in izida HTTP. Izpad cilja jo lahko spodnese, medtem ko je storitev SOCKS zdrava. Nepričakovana stran HTTP 200 lahko prav tako prestane preverjanje le na podlagi stanja, ne da bi zagotovila pričakovano vsebino.

Izberite nadzorovano pogodbo odziva in ohranite stopnjo napake. Ponovni zagon proxyja ob vsakem rezultatu curl, ki ni nič, lahko moti zdrave seje, medtem ko resnična težava cilja ostane nedotaknjena.

Sorodni članki