Wanneer Chrome nie 'n plaaslike PAC-lêer kan laai nie
Skei 'n verwerpte URL van 'n plaaslike PAC-lêer van ondersteuning vir PAC-roetering, script-sintaks en die gekose proxy.
As Chrome nie 'n PAC-script kan gebruik wat as 'n file:// URL voorsien word nie, ondersoek daardie afleweringspad voordat jy die script herskryf. Die mislukking om een ligging te laai bewys nie dat PAC-roetering nie ondersteun word nie.
Chrome se proxy-API het 'n pac_script-modus, met script-URL of inline data beskikbaar deur sy ondersteunde uitbreidingskoppelvlak. 'n Plaaslike lêer wat deur bedryfstelselinstellings voorsien word, is net een spesifieke manier om die script te probeer aflewer.
Volg die script tot in die blaaier
Stel vas wat die betrokke blaaier beheer: stelselinstellings, bestuurde beleid, opdragreelkonfigurasie of 'n uitbreiding. 'n Waarde wat in macOS-instelling vertoon word, bewys nie dat Chrome daardie script verkry en geëvalueer het nie.
Onderskei 'n verwerpte of onbereikbare script-ligging van 'n evalueringsfout, en albei van 'n mislukking om aan die proxy te koppel wat 'n geldige script teruggee. Die SOCKS-poort word eers relevant nadat die blaaier daardie roete gekies het.
Versprei 'n bestuurde PAC deur 'n goedgekeurde meganisme wat die teikenkliënte ondersteun. 'n HTTP- of HTTPS-aflewerings-URL moet bereikbaar bly wanneer die proxy wat dit beskryf, onbeskikbaar is. Met inline data van 'n uitbreiding verander die oorspronklike lêer nie outomaties die gekopieerde script nie. Vir 'n klein plaaslike beleid by die opstart, sluit die script in 'n data-URL in as 'n ander afleweringspad.
'n Interne PAC kan private gasheernname en roeteringsreëls bevat. Hou dit op 'n goedgekeurde afleweringsdiens eerder as om dit na willekeurige publieke gasheer te skuif om 'n probleem met 'n plaaslike lêer op te los.