Kāpēc čaulas starpniekservera pārbaude paliek neveiksmīga pēc tam, kad curl izdodas

Starpniekserveris neizdodas vienreiz. Vēlākie pieprasījumi izdodas, taču uzraugs turpina paziņot par vēl vienu kļūmi. Pārbaudiet, vai skripts atcerējās vakarējo iziešanas statusu.

Šis modelis mainīgo atjaunina tikai tad, kad curl neizdodas:

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

Pēc pirmā rezultāta, kas nav nulle, veiksmīga iterācija atstāj status neskartu. Tas nekļūst par nulli tikai tāpēc, ka curl izdevās.

Tā vietā sazarojiet pēc pašreizējās komandas:

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

Adrese un laiki ir ilustratīvi. Tas noņem novecojušo mainīgo; tas neizlemj, kura atkopšanas darbība ir piemērota.

Turiet novērojumu šauru. Pieprasījums ir atkarīgs no starpniekservera, tālākā maršruta, galamērķa, TLS pārbaudes un HTTP rezultāta. Mērķa pārtraukums var to izgāzt, kamēr SOCKS pakalpojums ir vesels. Neierasta HTTP 200 lapa arī var iziet tikai statusa pārbaudi, nesniedzot gaidīto saturu.

Izvēlieties kontrolētu atbildes līgumu un saglabājiet kļūmes posmu. Starpniekservera restartēšana pie katra curl rezultāta, kas nav nulle, var traucēt veselām sesijām, kamēr īstā galamērķa problēma paliek neskarta.