Varför en shell-proxykontroll förblir misslyckad när curl lyckas

Undvik att behålla ett gammalt curl-fel i en shellvariabel efter att senare proxykontroller lyckas.

Proxyn misslyckas en gång. Senare förfrågningar lyckas, men övervakningen fortsätter att meddela ännu ett fel. Kontrollera om skriptet kom ihåg gårdagens utstatus.

Det här mönstret uppdaterar bara variabeln när curl misslyckas:

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

Efter det första icke-nollresultatet lämnar en lyckad iteration status orört. Det blir inte noll bara för att curl lyckades.

Förgrena dig i stället på det aktuella kommandot:

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 och tiderna är illustrativa. Detta tar bort den inaktuella variabeln; det avgör inte vilken återställningsåtgärd som är lämplig.

Håll observationen snäv. Förfrågan beror på proxyn, den vidare vägen, målet, TLS-verifieringen och HTTP-resultatet. Ett avbrott hos målet kan få den att misslyckas medan SOCKS-tjänsten är frisk. En oväntad HTTP 200-sida kan också klara en kontroll som bara ser till status utan att leverera det förväntade innehållet.

Välj ett kontrollerat svarskontrakt och behåll felsteget. Att starta om proxyn vid varje icke-nollresultat från curl kan störa friska sessioner medan det egentliga målproblemet förblir orört.

Relaterade artiklar