რატომ ვერ იხსნება ზოგიერთი საიტი მხოლოდ VPN-ის ჩართვისას?

ის, რომ ერთი საიტი ფუჭდება, სანამ ყველაფერი დანარჩენი იტვირთება, ადასტურებს, რომ გვირაბი ტრაფიკს გადააქვს, და ეს პრობლემას უფრო მეტად ავიწროებს, ვიდრე უმეტესობა ელოდება. სამი დაკვირვება აწესრიგებს დანარჩენს: მიიღეთ თუ არა საერთოდ HTTP პასუხი, გადაიქცა თუ არა ჰოსტის სახელი მისამართად და გადის თუ არა პატარა მოთხოვნები, სანამ დიდები იჭედება. VPN-ზე გამოცნობა ამ პასუხების მიღებამდე ჩვეულებრივ ხარვეზს გადაადგილებს და არა აქრობს.

დაკვირვებები რიგრიგობით დაამუშავეთ, რადგან საიტი, რომელმაც უპასუხა, ერთდროულად ვერ ჩავარდებოდა გარჩევაში. თუ საერთოდ არაფერი იტვირთება, თქვენ არასწორ ტოტში ხართ და მოქმედებს დაკავშირებული, მაგრამ ინტერნეტის გარეშე შემოწმებები.

შეცდომის შეტყობინებამ აირჩიოს ტოტი

უარი, ანტიბოტ გამოწვევა ან შეცდომის გვერდი ნიშნავს, რომ სერვისმა უპასუხა, ანუ პაკეტებმა აპლიკაციას მიაღწიეს და დაბრუნდნენ. ეს კითხვას საიტის წვდომის პოლიტიკაზე გადააქვს, რომელმაც შეიძლება გაითვალისწინოს გასვლის მისამართი, ანგარიში ან გამოუქვეყნებელი მოთხოვნის ნიმუშები. სახელების გარჩევის ხარვეზი საიტამდე საერთოდ არ მივიდა, და მისამართი პირველია, რაც უნდა შემოწმდეს. დროის ამოწურვა ორივეს შორისაა: რაღაც გაიგზავნა და ვერაფერმა დაადასტურა.

სერტიფიკატის გაფრთხილებები მეოთხე ტოტს ეკუთვნის. ისინი ნიშნავს, რომ კავშირს უპასუხა რაღაცამ, რომლის იდენტობასაც ბრაუზერი ვერ გადაამოწმებდა: ან თქვენს მხარეს პროქსი, ან რეალური შეუსაბამობა, რომელზეც არ უნდა დააჭიროთ. მოეპყარით ამას ნდობის საკითხად და არა მარშრუტიზაციის.

პასუხის მომცემმა საიტმა გატეხილი გვირაბი არ დაამტკიცა

როცა პასუხი დაბლოკვის გვერდია, შეადარეთ იგივე გვერდი მეორე გასასვლელით, ბრაუზერისა და მანქანის შეუცვლელად. თუ შედეგი გასვლის მისამართს მიჰყვება, საიტი ამ მისამართს სხვანაირად ეპყრობა და არცერთი კლიენტის კონფიგურაცია ამას არ შეცვლის. თუ ბლოკირება თქვენს ბრაუზერს მიჰყვება, მიზეზი გაფართოებაში, შენახულ პროქსიში ან გადამწყვეტის პარამეტრშია. ორი გაშვება იაფად ყოფს ამ ახსნებს.

მხოლოდ ბრაუზერში წარმოქმნილი ხარვეზები საკმარისად ხშირია, რომ ადრეულად შემოწმდეს. გვერდი, რომელიც ერთ მხარდაჭერილ ბრაუზერში იტვირთება და მეორეში ფუჭდება, მიუთითებს პროფილის მდგომარეობაზე, კონტენტის ბლოკერზე ან ბრაუზერის შიგნით კონფიგურირებულ დაშიფრულ DNS-ზე. Chrome-ის მითითებები უსაფრთხო DNS-ის შესახებ აჩვენებს, სად არის ეს პარამეტრი, და მისი შეცვლა მხარდაჭერილი კონტროლით სჯობს მოწყობილობის გადაყენებას.

როცა მხოლოდ დიდი გადაცემები იჭედება, შეხედეთ პაკეტის ზომას

გვერდი, რომელიც სათაურს ხატავს და შემდეგ იჭედება, სხვა ხელმოწერა აქვს, ვიდრე გვერდს, რომელიც არასდროს იწყება. პატარა პასუხები შეიძლება გაიაროს, სანამ სრული ზომის დატვირთვა სადღაც იყრება, რაც ვერ ახერხებს გამომგზავნისთვის სიგნალიზაციას, და ასე გამოიყურება ბილიკის MTU ხარვეზი ბრაუზერიდან. შეადარეთ პაწია მოთხოვნა და დიდი იმავე ჰოსტთან, სანამ ფილტრაციაზე თეორიზებას დაიწყებთ. ბილიკის MTU აღმოჩენამ უნდა ისწავლოს ბილიკზე ყველაზე პატარა რგოლის ზომა, და ის დამოკიდებულია ICMP პასუხებზე, რომლებსაც გაფილტრული ქსელები ჩვეულებრივ ყრიან.

შეამოწმეთ ეს ჰიპოთეზა ზომების გადარჩევით და არა ერთი ping-ით. ხარვეზი, რომელიც იწყება მუდმივ დატვირთვის ზომაზე, ძლიერი მტკიცებულებაა, ხოლო მოძრავი ხარვეზი არა.

დაადასტურეთ გასწორება მოთხოვნაზე, რომელიც ჩავარდა

ხელახლა შეამოწმეთ თავდაპირველი ოპერაცია და არა მთავარი გვერდი, რადგან ქეშირებული ჭურვი შეიძლება დაიხატოს, სანამ შესვლის უკან API გამოძახება ჯერ კიდევ ფუჭდება. ქვემოთ მოცემული ბრძანებები ჰყოფს სახელების გარჩევას, პატარა მოთხოვნას და დიდს იმავე ჰოსტთან. ჩაანაცვლეთ ჰოსტის სახელი და ბილიკი იმ მოთხოვნის მიხედვით, რომელიც ნამდვილად გატყდა.

dig +short www.example.com
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://www.example.com/
curl -sS -o /dev/null -w '%{http_code} %{size_download}\n' https://www.example.com/assets/app.js
ping -M do -s 1400 -c 3 203.0.113.20

თუ dig პასუხი განსხვავდება ბრაუზერისგან, ცვლადი გადამწყვეტია, და ბრაუზერის საკუთარი DNS პარამეტრია ადგილი, სადაც უნდა შეხედოთ. თუ პატარა მოთხოვნა სტატუსს აბრუნებს, სანამ დიდი იჭედება, დაამუშავეთ პაკეტის ზომის ტოტი. თუ ორივე დროში იწურება, გასვლის ბილიკი და საიტის დამოკიდებულება ამ მისამართის მიმართ ისევ მაგიდაზეა.

შეინარჩუნეთ ცვლილება, რომლის წყალობითაც თავდაპირველი მოთხოვნა შესრულდა, და დანარჩენი გააუქმეთ. ბრაუზერში, გადამწყვეტსა და კლიენტში ერთდროული ცვლილებების გროვა გიშლით ხელს თქვათ, რომელი იყო მნიშვნელოვანი.