Si Chrome ne peut pas utiliser un script PAC fourni sous forme d'URL file://, vérifiez ce chemin de distribution avant de réécrire le script. L'échec du chargement d'un emplacement ne prouve pas que le routage PAC n'est pas pris en charge.

L'API proxy de Chrome dispose d'un mode pac_script, l'URL du script ou des données intégrées étant disponibles via son interface d'extension prise en charge. Un fichier local fourni par les réglages du système d'exploitation n'est qu'un moyen particulier de tenter de distribuer le script.

Suivez le script jusque dans le navigateur

Déterminez ce qui contrôle le navigateur concerné : réglages du système, politique gérée, configuration en ligne de commande ou extension. Une valeur affichée dans les réglages de macOS ne prouve pas que Chrome a obtenu et évalué ce script.

Distinguez un emplacement de script refusé ou injoignable d'une erreur d'évaluation, et les deux d'un échec de connexion au proxy renvoyé par un script valide. Le port SOCKS ne devient pertinent qu'une fois que le navigateur a choisi cette route.

Distribuez un PAC géré par un mécanisme approuvé pris en charge par les clients cibles. Une URL de distribution HTTP ou HTTPS doit rester joignable lorsque le proxy qu'elle décrit est indisponible. Avec des données intégrées fournies par une extension, modifier le fichier d'origine ne met pas à jour automatiquement le script copié. Pour une petite politique locale au démarrage, intégrez le script dans une URL de données comme autre voie de distribution.

Un PAC interne peut contenir des noms d'hôtes privés et des règles de routage. Conservez-le sur un service de distribution approuvé plutôt que de le déplacer vers un hébergement public quelconque pour résoudre un problème de fichier local.

Articles similaires