Por que unha comprobación de proxy na shell segue fallando despois de que curl funcione

Evite conservar un fallo antigo de curl nunha variable da shell despois de que as comprobacións de proxy posteriores funcionen.

O proxy falla unha vez. As peticións posteriores funcionan, pero o vixiante segue anunciando outro fallo. Comprobe se o script recordaba o estado de saída de onte.

Este patrón só actualiza a variable cando curl falla:

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

Tras o primeiro resultado distinto de cero, unha iteración correcta deixa status intacto. Non pasa a cero só porque curl funcionase.

No canto diso, ramifique segundo a orde actual:

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

O enderezo e os tempos son ilustrativos. Isto elimina a variable obsoleta; non decide que acción de recuperación é axeitada.

Manteña a observación estreita. A petición depende do proxy, da ruta posterior, do destino, da verificación TLS e do resultado HTTP. Unha caída do obxectivo pode facela fallar mentres o servizo SOCKS está san. Unha páxina HTTP 200 inesperada tamén pode superar unha comprobación só de estado sen ofrecer o contido agardado.

Escolla un contrato de resposta controlado e conserve a etapa do fallo. Reiniciar o proxy ante cada resultado de curl distinto de cero pode alterar sesións sanas mentres o problema real do destino queda intacto.

Artigos relacionados