როცა Squid ჰოსტის სახელს ვერ ხსნის

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

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

getent ahosts target.example

გამოიყენეთ რეალური სამიზნე. getent ჰოსტის ძიების მექანიზმს იყენებს; Squid-ის შიდა რეზოლვერი ან ქეში შეიძლება განსხვავდებოდეს. სანამ მათ თანხვედრას ივარაუდებთ, შეამოწმეთ აშკარად მითითებული dns_nameservers და hosts_file შემავალი მონაცემები.

Squid 6.13-ში აშკარად მითითებული სახელების სერვერების სია IP მისამართებს შეიცავს:

dns_nameservers 192.0.2.53

დოკუმენტაციის ეს მისამართი შეცვალეთ დამტკიცებული რეზოლვერით, რომელიც Squid სერვერიდან ხელმისაწვდომია. კერძო სახელებს შეიძლება ორგანიზაციის რეზოლვერი დასჭირდეს; დაუკავშირებელ საჯარო რეზოლვერს ისინი საკუთარ DNS ხედში შეიძლება არ უჩანდეს.

ლეპტოპის hosts ფაილის ფსევდონიმი პროქსით გაგზავნილ ჰოსტის სახელის მოთხოვნას არ მიჰყვება. ძიების შემსრულებელ მანქანაზე შეამოწმეთ დაყენებული Squid ვერსიის hosts_file პარამეტრი და საჭიროებისას ზედა პროქსის რეზოლვერიც გაითვალისწინეთ. TLS იდენტობისთვის გამოყენებული ჰოსტის სახელი სერვისს უნდა შეესაბამებოდეს.

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