Երբ curl-ի ստուգումը HTTP կարգավիճակի համար արտածում է 000, այն չի ստացել վերջնական HTTP պատասխանի կոդ, որը կարող էր հաղորդել։ Կայքը չի ուղարկել 000 անվամբ իրական HTTP կարգավիճակ։

Գրանցեք նաև սխալը

POSIX հրամանային միջավայրի այս օրինակը արտածում է վերջնական HTTP դաշտը, CONNECT դաշտը և curl գործընթացի ելքի կոդը․

curl --proxy http://203.0.113.10:8080 --noproxy '' --connect-timeout 5 --max-time 15 --silent --show-error --output /dev/null --write-out 'http=%{http_code} connect=%{http_connect}\n' https://example.com/
result=$?
printf 'curl_exit=%s\n' "$result"

Օրինակի միացման կետը փոխարինեք ձեր HTTP պրոքսիով կամ HTTP պրոքսիների ցանկից որևէ թեկնածուով։ show-error-ը միացված թողեք․ սխալի հաղորդագրությունը հաճախ ամենաօգտակար մասն է։ CONNECT դաշտը կարևոր է թունել օգտագործելիս․ այն կայքի երկրորդ վերջնական կարգավիճակը չէ։

Կարդացեք արժեքները միասին

  • Պրոքսիին միանալու ձախողումը կարող է HTTP դաշտը թողնել 000։
  • Մինչև պատասխան ստանալը սպասման ժամանակի սպառումը կարող է նույն արդյունքն ունենալ։
  • Հաջող CONNECT պատասխանից հետո TLS-ի խափանման դեպքում կարող են երևալ connect=200 և http=000։
  • Կայքի ամբողջական պատասխանը, օրինակ՝ 403-ը, այլ դեպք է․ կա իրական HTTP պատասխան, որը կարելի է ուսումնասիրել։

Ելքի ճշգրիտ կոդն ու հաղորդագրությունը նեղացնում են պատճառների շրջանակը։ Պարզեք՝ խափանումը եղել է պրոքսին գտնելիս, դրա պորտին միանալիս, թունելը համաձայնեցնելիս, թե նպատակակետը ստուգելիս։

Ամեն արդյունք մի սահմանափակեք միայն կարգավիճակի ստուգմամբ

Միայն http_code-ը պահպանող սկրիպտը կորցնում է փոխանցման սխալը։ Պահպանեք նաև գործընթացի արդյունքն ու զգայուն տվյալներից մաքրված սխալի հաղորդագրությունը։ Հակառակը՝ curl-ը կարող է հաջողությամբ ավարտել փոխանցումը, երբ կայքը վերադարձնում է սխալի կարգավիճակ, եթե համապատասխան fail ընտրանք չեք օգտագործում։ HTTP պատասխանը և հաճախորդի կատարման արդյունքը տարբեր հարցերի են պատասխանում։

Մի փորձեք ուղղել 000-ը՝ անջատելով TLS-ի ստուգումը կամ պատահական վերնագիր ավելացնելով։ Նախ պարզեք, թե որ գործողությունը վերջնական պատասխանի չի հասել։

Առնչվող հոդվածներ