Por qué una comprobación de proxy en el shell sigue fallando después de que curl funciona

El proxy falla una vez. Las peticiones posteriores funcionan, pero el vigilante sigue anunciando otro fallo. Compruebe si el script recordaba el estado de salida de ayer.

Este patrón solo actualiza la variable cuando curl falla:

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

Tras el primer resultado distinto de cero, una iteración correcta deja status intacto. No pasa a cero solo porque curl haya funcionado.

En su lugar, ramifique según el comando 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

La dirección y los tiempos son ilustrativos. Esto elimina la variable obsoleta; no decide qué acción de recuperación es adecuada.

Mantenga la observación estrecha. La petición depende del proxy, de la ruta posterior, del destino, de la verificación TLS y del resultado HTTP. Una caída del objetivo puede hacerla fallar mientras el servicio SOCKS está sano. Una página HTTP 200 inesperada también puede superar una comprobación solo de estado sin ofrecer el contenido esperado.

Elija un contrato de respuesta controlado y conserve la etapa del fallo. Reiniciar el proxy ante cada resultado de curl distinto de cero puede alterar sesiones sanas mientras el problema real del destino queda intacto.