Pourquoi un contrôle de proxy en shell reste en échec après la réussite de curl

Évitez de conserver un ancien échec curl dans une variable shell alors que les contrôles de proxy suivants réussissent.

Le proxy échoue une fois. Les requêtes suivantes réussissent, mais la surveillance continue d'annoncer un nouvel échec. Vérifiez si le script a retenu le code de sortie d'hier.

Ce schéma ne met la variable à jour que lorsque curl échoue :

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

Après le premier résultat non nul, une itération réussie laisse status intact. Il ne devient pas nul simplement parce que curl a réussi.

Branchez plutôt sur la commande en cours :

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

L'adresse et les durées sont illustratives. Cela supprime la variable obsolète ; cela ne décide pas quelle action de reprise est appropriée.

Gardez l'observation étroite. La requête dépend du proxy, de la route en aval, de la destination, de la vérification TLS et du résultat HTTP. Une panne de la cible peut la faire échouer alors que le service SOCKS est sain. Une page HTTP 200 inattendue peut aussi passer un contrôle fondé sur le seul statut sans fournir le contenu attendu.

Choisissez un contrat de réponse maîtrisé et conservez l'étape d'échec. Redémarrer le proxy à chaque résultat curl non nul peut perturber des sessions saines tout en laissant le vrai problème de destination intact.

Articles similaires