Чаму праверка проксі ў абалонцы застаецца няўдалай пасля поспеху curl

Пазбягайце захавання старой памылкі curl у зменнай абалонкі пасля таго, як наступныя праверкі проксі ўдалыя.

Проксі збайваецца адзін раз. Наступныя запыты ўдалыя, але вартаўнік працягвае паведамляць пра чарговую няўдачу. Праверце, ці сцэнар запомніў учорашні код выхаду.

Гэты шаблон абнаўляе зменную толькі тады, калі curl збайваецца:

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

Пасля першага ненулявога выніку ўдалая ітэрацыя пакідае status без змен. Ён не становіцца нулём толькі таму, што curl атрымаўся.

Замест гэтага разгаліноўвайцеся па бягучай камандзе:

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

Адрас і тэрміны — прыклад. Гэта выдаляе састарэлую зменную; але не вырашае, якое аднаўленне мэтазгоднае.

Трымайце назіранне вузкім. Запыт залежыць ад проксі, далейшага маршруту, пункту прызначэння, праверкі TLS і выніку HTTP. Перапынак на баку мэты можа праваліць яго, пакуль служба SOCKS здаровая. Нечаканая старонка HTTP 200 таксама можа прайсці праверку толькі па статусе, не прадставіўшы чаканы змест.

Выберыце кантраляваны кантракт адказу і захоўвайце этап збою. Перазапуск проксі пры кожным ненулявым выніку curl можа парушыць здаровыя сеансы, пакідаючы сапраўдную праблему прызначэння нявырашанай.

Падобныя артыкулы