„Resolving Host in Proxy Script“-ზე გაიჭედეთ? ნახეთ PAC ფაილი

სტატუსის შეტყობინება ამბობს „Resolving host in proxy script“, მაგრამ პროქსი სერვერების შეცვლა ცოტას ცვლის. ეს სასარგებლო მინიშნებაა: შესაძლოა ბრაუზერი ჯერ კიდევ წყვეტს, სად გაგზავნოს მოთხოვნა.

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

1. იპოვეთ შეჩერების ადგილი

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

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

2. მოაშორეთ ზედმეტი DNS სამუშაო

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

ნუ „შეაკეთებთ“ ნელ სკრიპტს ზემოთ უპირობო DIRECT დაბრუნების დამატებით. ეს შეყოვნებასთან ერთად მარშრუტიზაციის გადაწყვეტილებასაც აშორებს.

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