Ինչու shell-ի proxy ստուգումը մնում է ձախողված, երբ 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 արդյունքի դեպքում պրոքսին վերագործարկելը կարող է խաթարել առողջ նստաշրջանները, մինչ իրական նպատակակետի խնդիրը մնում է անփոփոխ։