Når Chrome ikke kan indlæse en lokal PAC-fil
Skeln mellem en afvist lokal PAC-fil-URL og understøttelse af PAC-routing, script-syntaks og den valgte proxy.
Hvis Chrome ikke kan bruge et PAC-script, der leveres som en file://-URL, skal du kontrollere den leveringsvej, før du omskriver scriptet. At indlæsning af én placering mislykkes beviser ikke, at PAC-routing ikke understøttes.
Chromecs proxy-API har en pac_script-tilstand, hvor script-URL eller inline-data er tilgængelige via den understøttede udvidelsesgrænseflade. En lokal fil, der leveres via operativsystemets indstillinger, er blot én bestemt måde at forsøge at levere scriptet på.
Følg scriptet ind i browseren
Fastslå, hvad der styrer den berørte browser: systemindstillinger, administreret politik, kommandolinjekonfiguration eller en udvidelse. En værdi vist i macOS-indstillinger beviser ikke, at Chrome har hentet og evalueret scriptet.
Skeln mellem en afvist eller utilgængelig scriptplacering og en evalueringsfejl, og begge fra en fejl med at oprette forbindelse til den proxy, et gyldigt script returnerer. SOCKS-porten er først relevant, når browseren har valgt den rute.
Distribuér en administreret PAC via en godkendt mekanisme, som målmiljøerne understøtter. En leverings-URL over HTTP eller HTTPS skal forblive tilgængelig, når den proxy, den beskriver, ikke er tilgængelig. Med inline-data fra en udvidelse opdaterer ændringer i den oprindelige fil ikke automatisk det kopierede script. Til en lille lokal politik ved opstart, indlejr scriptet i en data-URL som en anden leveringsvej.
En intern PAC kan indeholde private værtsnavne og routingregler. Hold den på en godkendt leveringstjeneste i stedet for at flytte den til vilkårlig offentlig hosting for at løse et lokalt filproblem.