Warum eine Proxy-Prüfung in der Shell nach einem erfolgreichen curl als fehlgeschlagen gilt

Vermeiden Sie es, einen alten curl-Fehler in einer Shell-Variable zu behalten, nachdem spätere Proxy-Prüfungen erfolgreich sind.

Der Proxy scheitert einmal. Spätere Anfragen gelingen, doch die Überwachung meldet weiterhin einen weiteren Fehler. Prüfen Sie, ob das Skript den Exit-Status von gestern behalten hat.

Dieses Muster aktualisiert die Variable nur, wenn curl scheitert:

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

Nach dem ersten von null verschiedenen Ergebnis lässt eine erfolgreiche Iteration status unberührt. Sie wird nicht allein deshalb null, weil curl erfolgreich war.

Verzweigen Sie stattdessen auf den aktuellen Befehl:

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

Adresse und Zeitangaben sind beispielhaft. Das entfernt die veraltete Variable; es entscheidet nicht, welche Wiederherstellungsmaßnahme angemessen ist.

Halten Sie die Beobachtung eng. Die Anfrage hängt vom Proxy, der weiteren Route, dem Ziel, der TLS-Prüfung und dem HTTP-Ergebnis ab. Ein Ausfall des Ziels kann sie scheitern lassen, während der SOCKS-Dienst gesund ist. Eine unerwartete HTTP-200-Seite kann eine reine Statusprüfung auch bestehen, ohne den erwarteten Inhalt zu liefern.

Wählen Sie einen kontrollierten Antwortvertrag und behalten Sie die Fehlerstufe bei. Ein Neustart des Proxys bei jedem von null verschiedenen curl-Ergebnis kann gesunde Sitzungen stören, während das eigentliche Zielproblem unberührt bleibt.

Ähnliche Artikel