Коли 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 може містити приватні імена хостів і правила маршрутизації. Тримайте його в схваленій службі доставки, а не переносьте на довільний публічний хостинг, щоб розв'язати проблему з локальним файлом.