De ce o verificare proxy din shell rămâne eșuată după ce curl reușește

Evitați să păstrați un eșec curl vechi într-o variabilă shell după ce verificările proxy ulterioare reușesc.

Proxy-ul eșuează o dată. Cererile ulterioare reușesc, dar monitorizarea continuă să anunțe încă un eșec. Verificați dacă scriptul a reținut starea de ieșire de ieri.

Acest tipar actualizează variabila doar când curl eșuează:

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

După primul rezultat diferit de zero, o iterație reușită lasă status neatins. Nu devine zero doar pentru că curl a reușit.

Ramificați în schimb pe comanda curentă:

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

Adresa și duratele sunt ilustrative. Aceasta elimină variabila învechită; nu decide ce acțiune de recuperare este potrivită.

Păstrați observația îngustă. Cererea depinde de proxy, de ruta ulterioară, de destinație, de verificarea TLS și de rezultatul HTTP. O cădere a țintei o poate face să eșueze în timp ce serviciul SOCKS este sănătos. O pagină HTTP 200 neașteptată poate trece și ea o verificare doar pe stare fără a furniza conținutul așteptat.

Alegeți un contract de răspuns controlat și păstrați etapa eșecului. Repornirea proxy-ului la fiecare rezultat curl diferit de zero poate perturba sesiuni sănătoase, în timp ce problema reală a destinației rămâne neatinsă.

Articole similare