Gdy Chrome nie ładuje lokalnego pliku PAC
Odróżnij odrzucony adres URL lokalnego pliku PAC od obsługi routingu PAC, składni skryptu i wybranego serwera proxy.
Jeśli Chrome nie może użyć skryptu PAC dostarczonego jako adres file://, sprawdź tę ścieżkę dostarczania, zanim przepiszesz skrypt. Niepowodzenie w jednym miejscu nie dowodzi, że routing PAC nie jest obsługiwany.
Interfejs proxy Chrome ma tryb pac_script, w którym adres skryptu lub dane wbudowane są dostępne przez obsługiwany interfejs rozszerzenia. Plik lokalny podany w ustawieniach systemu operacyjnego to tylko jeden ze sposobów próby dostarczenia skryptu.
Prześledź skrypt aż do przeglądarki
Ustal, co kontroluje daną przeglądarkę: ustawienia systemu, zarządzana polityka, konfiguracja z wiersza poleceń czy rozszerzenie. Wartość widoczna w ustawieniach macOS nie dowodzi, że Chrome pobrał i ocenił ten skrypt.
Odróżnij odrzuconą lub nieosiągalną lokalizację skryptu od błędu oceny, a oba przypadki od niepowodzenia połączenia z serwerem proxy zwracanym przez poprawny skrypt. Port SOCKS zaczyna mieć znaczenie dopiero po wybraniu tej trasy przez przeglądarkę.
Rozprowadzaj zarządzany PAC przez zatwierdzony mechanizm obsługiwany przez klienty docelowe. Adres dostarczania HTTP lub HTTPS musi pozostać osiągalny, gdy opisany w nim serwer proxy jest niedostępny. Przy danych wbudowanych dostarczanych przez rozszerzenie zmiana pliku źródłowego nie aktualizuje automatycznie skopiowanego skryptu. Dla małej polityki lokalnej przy starcie osadź skrypt w adresie data URL jako kolejną ścieżkę dostarczania.
Wewnętrzny PAC może zawierać prywatne nazwy hostów i reguły routingu. Trzymaj go w zatwierdzonej usłudze dostarczania, zamiast przenosić go do dowolnego publicznego hostingu, aby rozwiązać problem z plikiem lokalnym.