client → local forward proxy → HTTP parent → website

დაიწყეთ იმ სახელით, რომელიც ვერ იხსნება, და არა იმ მტკიცებით, რომ მთელი DNS „პროქსის“ ეკუთვნის:

საჭირო სახელინაბიჯი, რომელმაც უნდა მიაღწიოს
ლოკალური პროქსის საბოლოო წერტილიკლიენტი
HTTP parent-ის საბოლოო წერტილილოკალური გადამისამართების პროქსი
ვებსაიტის საბოლოო წერტილიparent, როცა საბოლოო კავშირს ხსნის

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

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

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

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

დაკავშირებული სტატიები