თუ Chrome ვერ იყენებს file:// URL-ად მოწოდებულ PAC სკრიპტს, შეამოწმეთ ეს მიწოდების გზა სკრიპტის გადაწერამდე. ერთი მდებარეობის ჩატვირთვის წარუმატებლობა არ ამტკიცებს, რომ PAC მარშრუტიზაცია მხარდაუჭერელია.

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

თვალყური ადევნეთ სკრიპტს ბრაუზერამდე

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

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

გაავრცელეთ მართვადი PAC დამტკიცებული მექანიზმით, რომელსაც სამიზნე კლიენტები მხარს უჭერენ. HTTP ან HTTPS მიწოდების URL უნდა დარჩეს მისაწვდომი მაშინაც, როცა მის მიერ აღწერილი პროქსი მიუწვდომელია. გაფართოების მიერ მოწოდებული ჩაშენებული მონაცემების შემთხვევაში, ორიგინალი ფაილის შეცვლა ავტომატურად არ აახლებს დაკოპირებულ სკრიპტს. გაშვებისას მცირე ლოკალური პოლიტიკისთვის, ჩააშენეთ სკრიპტი data URL-ში როგორც მიწოდების სხვა გზა.

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

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