Un résultat PAC désigne à la fois un proxy et un protocole. Si votre déploiement Firefox a besoin de SOCKS5, indiquez-le dans la valeur renvoyée :

return "SOCKS5 proxy.example:1080";

Si la stratégie PAC utilise des points de terminaison publics, choisissez des candidats dans la liste de proxys SOCKS5 et conservez le résultat SOCKS5 explicite. Le jeton générique SOCKS possède un historique de compatibilité. Ce n'est pas une consigne portable que chaque navigateur devrait interpréter comme la version de SOCKS la plus récente.

Dans l'implémentation Firefox examinée ici, l'analyseur PAC associe le SOCKS5 explicite au fournisseur de socket de version 5 et demande une résolution du nom d'hôte de destination côté serveur. La configuration manuelle du proxy suit un chemin de réglages distinct. Un nom de préférence issu d'une configuration manuelle ne doit donc pas être traité comme une explication universelle de chaque résultat PAC.

Consignez la version exacte du navigateur, le script PAC chargé et le jeton renvoyé. Un script que vous avez modifié n'est pas nécessairement celui que le client a récupéré, et un itinéraire différent renvoyé pour un hôte peut modifier l'observation.

Cela concerne le nom de destination associé à la route SOCKS sélectionnée. Le client doit toujours joindre le point de terminaison du proxy, et les autres applications conservent leur propre comportement DNS. Ne transformez pas un résultat PAC correct en affirmation que toutes les résolutions de l'appareil passent désormais à distance.

Lorsque la configuration doit prendre en charge plusieurs navigateurs, vérifiez leur prise en charge documentée des jetons PAC plutôt que de transposer un détail de niveau source de Firefox dans une autre implémentation.

Articles similaires