Perché un controllo proxy nella shell resta fallito dopo che curl riesce

Evitate di conservare un vecchio errore di curl in una variabile della shell dopo che i controlli proxy successivi riescono.

Il proxy fallisce una volta. Le richieste successive riescono, ma il watchdog continua ad annunciare un altro errore. Verificate se lo script ha ricordato lo stato di uscita di ieri.

Questo schema aggiorna la variabile solo quando curl fallisce:

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

Dopo il primo risultato diverso da zero, un'iterazione riuscita lascia status intatto. Non diventa zero solo perché curl è riuscito.

Ramificate invece sul comando corrente:

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

L'indirizzo e i tempi sono esemplificativi. Questo rimuove la variabile obsoleta; non decide quale azione di ripristino sia appropriata.

Mantenete l'osservazione stretta. La richiesta dipende dal proxy, dal percorso successivo, dalla destinazione, dalla verifica TLS e dall'esito HTTP. Un'interruzione del bersaglio può farla fallire mentre il servizio SOCKS è sano. Anche una pagina HTTP 200 inattesa può superare un controllo basato solo sullo stato senza fornire il contenuto atteso.

Scegliete un contratto di risposta controllato e conservate la fase di errore. Riavviare il proxy a ogni risultato curl diverso da zero può disturbare sessioni sane mentre il vero problema di destinazione resta intatto.

Articoli correlati