Կարելի՞ է պրոքսին ստուգել ping-ով
Ping-ի պատասխանը ստուգում է ICMP հասանելիությունը, ոչ թե պրոքսիի պորտի HTTP կամ SOCKS ծառայությունը։
ping-ը ցույց է տալիս՝ ICMP արձագանքի հարցումը պատասխան ստացել է, թե ոչ։ Այն չի բացում պրոքսիների ցանկում նշված HTTP կամ SOCKS պորտը և պրոքսիից չի խնդրում հասնել կայք։
Տարբերությունը կարևոր է, երբ գրառումը պատասխանում է ping-ին, բայց մերժում է պրոքսի կապը։ ICMP-ն և պրոքսիի TCP ծառայությունը տարբեր ուղիներ են անցնում հոսթի ծրագրերում և մուտքի կանոններում։ Հասանելի հասցեն կարող է չունենալ ձեր ընտրած պորտը լսող պրոքսի։
Երեք արդյունք, որոնք հեշտ է սխալ հասկանալ
- Ping-ը պատասխանում է, պրոքսին ձախողվում է. քննեք ծառայության պորտը, արձանագրությունը, նույնականացումն ու պրոքսիի պատասխանը։ Արձագանքի պատասխանը դրանք չի ստուգել։
- Ping-ը ձախողվում է, պրոքսին աշխատում է. ցանցը կամ հոսթը կարող են զտել ICMP-ն՝ թույլատրելով պրոքսի կապը։ Մի մերժեք ծրագրի հաջող ստուգումը անպատասխան արձագանքի հարցման պատճառով։
- Ping-ն արագ է, հարցումները՝ դանդաղ. արձագանքի երկկողմ ուղին չի ներառում պրոքսիի համաձայնեցումը, պրոքսիից նպատակակետ ուղին, TLS-ը և նպատակակետի պատասխանի ժամանակը։
Օգտագործեք հաճախորդի իրական գործողությունը
HTTP վերջնակետի համար դրա միջոցով կատարեք սահմանափակված HTTP հարցում։ Եթե HTTPS է պետք, հաստատեք նաև թունելի ստեղծումն ու նպատակակետի TLS պատասխանը։ SOCKS-ի համար օգտագործեք ծրագրի աջակցած SOCKS ռեժիմը։ TCP պորտի ստուգումը օգտակար միջանկյալ դիտարկում է, բայց կանգ է առնում արձանագրության այդ քայլերից առաջ։
Հայտնի երթուղու խնդիրները քննելիս ping-ը պահեք որպես լրացուցիչ ցանցային տեղեկություն։ Դրա արդյունքը ներկայացրեք ծրագրի արդյունքից առանձին։ «IP-ն պատասխանում է արձագանքի հարցումներին» և «պրոքսին ավարտեց այս HTTPS հարցումը» տարբեր պնդումներ են. միայն երկրորդն է ստուգում նախատեսված գործողությունը։