Калі Chrome не можа загрузіць лакальны файл PAC
Аддзяліце адхілены URL лакальнага файла PAC ад падтрымкі маршрутызацыі PAC, сінтаксісу скрыпта і выбранага проксі.
Калі Chrome не можа выкарыстаць скрыпт PAC, пададзены як URL file://, праверце гэты шлях дастаўкі перад перапісваннем скрыпта. Няздольнасць загрузіць адно месца не даказвае, што маршрутызацыя PAC не падтрымліваецца.
У API проксі Chrome ёсць рэжым pac_script: URL скрыпта або ўбудованыя даныя даступныя праз падтрымліваны інтэрфейс пашырэння. Лакальны файл, пададзены праз налады аперацыйнай сістэмы, — гэта толькі адзін са спосабаў паспрабаваць даставіць скрыпт.
Прасачыце за скрыптам аж да браўзера
Вызначце, што кіруе закранутым браўзерам: сістэмныя налады, кіраваная палітыка, канфігурацыя каманднага радка або пашырэнне. Значэнне, паказанае ў наладах macOS, не даказвае, што Chrome атрымаў і выканаў гэты скрыпт.
Адрозніце адхіленае або недаступнае месца скрыпта ад памылкі выканання, а абодва — ад няздольнасці падключыцца да проксі, які вяртае сапраўдны скрыпт. Порт SOCKS мае значэнне толькі пасля таго, як браўзер выбраў гэты маршрут.
Размяркоўвайце кіраваны PAC праз зацверджаны механізм, які падтрымліваюць мэтавыя кліенты. URL дастаўкі па HTTP або HTTPS павінен заставацца даступным, нават калі апісаны ім проксі недаступны. Пры ўбудованых даных ад пашырэння змяненне зыходнага файла не абнаўляе скапіяваны скрыпт аўтаматычна. Для невялікай лакальнай палітыкі пры запуску, убудуйце скрыпт у data URL як іншы шлях дастаўкі.
Унутраны PAC можа змяшчаць прыватныя імёны хостаў і правілы маршрутызацыі. Трымайце яго на зацверджаным сэрвісе дастаўкі, а не пераносьце на адвольны публічны хостынг, каб вырашыць праблему лакальнага файла.