PAC Request Policy pour un routage cohérent

Proxy Auto-Config, généralement appelé PAC, donne au navigateur une politique pour choisir une route réseau. La décision reste dans le chemin réseau du navigateur, de sorte que la même politique peut couvrir la navigation, les redirections, les sous-ressources et les requêtes gérées par le navigateur sans dépendre d'un framework de page.

Cet emplacement est utile lorsqu'un déploiement utilise plusieurs routes proxy approuvées. La navigation régionale, les tests d'applications internes, la validation de contenus multimédias et les charges à plusieurs contextes peuvent chacun exiger des familles de routes différentes. Une politique PAC garde ces choix à proximité du profil du navigateur et de la configuration de lancement.

BotBrowser documente le routage PAC standard via --proxy-pac-url et, pour les profils d'entreprise approuvés, un callback de requêtes supplémentaire dans le même script PAC. Le PAC standard reste le modèle par défaut. Le callback est une couche facultative qui aide les équipes autorisées à traiter les requêtes de façon cohérente, tandis que la source PAC, l'inventaire des proxies et le profil sont revus ensemble.

TL;DR

• Gardez le routage PAC dans la couche réseau du navigateur et rendez FindProxyForURL(url, host) vérifiable.
• Notez proxy, direct ou blocked et conservez policyVersion pour le retour arrière.
• BotBrowser applique les capacités PAC approuvées, mais ne rend pas un proxy fiable et n'approuve pas une destination.

Contents

• Pourquoi le routage appartient au navigateur
• Modèle opérationnel et callback de requêtes
• Cas d'usage adaptés de la politique de requêtes PAC
• Protections et validation fondée sur les résultats
• Responsabilité, déploiement et dossiers
• Reprise et maintenance
• Practical conclusion

Pourquoi le routage appartient au navigateur

Conservez FindProxyForURL(url, host) et le retour DIRECT dans le registre de politique.

Un proxy statique suffit souvent pour une session simple. Il convient moins lorsqu'un même flux du navigateur a besoin de plusieurs chemins approuvés. Déplacer les choix de route dans des gestionnaires du framework peut aussi créer des comportements différents entre Playwright, Puppeteer, CDP brut et le trafic géré par le navigateur, et l'interception dans la couche d'automatisation peut interrompre la continuité des connexions et des flux HTTP/2 dans certains scénarios.

PAC donne au navigateur une seule politique de routage. Le code d'automatisation pilote la page, tandis que le navigateur choisit la route réseau. Comme la politique n'est liée à aucun framework, elle peut servir différents outils d'automatisation. Ce partage facilite la revue d'un déploiement, car le profil, l'inventaire des proxies et la politique de routage ont des responsabilités claires. Pour savoir comment attribuer les responsabilités de chaque couche réseau dans de grands déploiements, voir Frontières réseau du navigateur d'entreprise : responsabilités.

Cette approche soutient aussi la cohérence en matière de confidentialité. Un profil de navigateur peut définir une région, une langue, un fuseau horaire et une famille d'appareils, mais ces réglages perdent leur valeur si le trafic suit un chemin réseau sans rapport. Garder la politique de routes à côté du profil réduit la dérive de configuration entre les réglages du profil et la sortie approuvée.

Quand un proxy statique suffit

PAC n'est pas nécessaire pour tous les déploiements. Privilégiez un proxy statique lorsque tout le trafic doit emprunter une seule route et qu'aucune politique par classe de requête n'est à maintenir. Un contexte à route unique n'a pas besoin de PAC, et une configuration plus petite est plus simple à exploiter et comporte moins d'éléments mobiles.

Utilisez PAC lorsque le choix de la route est une vraie exigence au niveau du navigateur. Ne l'ajoutez pas uniquement pour reproduire une logique du framework qui dispose déjà d'une route unique et stable. La politique doit réduire la complexité opérationnelle, et non déplacer la même complexité dans un autre fichier.

Modèle opérationnel et callback de requêtes

Un déploiement maintenable sépare quatre responsabilités :

1. Le profil du navigateur définit les réglages prévus du navigateur.
2. L'inventaire des proxies définit les chemins réseau approuvés.
3. La politique PAC choisit un chemin pour chaque classe de requêtes concernée.
4. Le flux d'automatisation exécute la tâche autorisée dans le navigateur.

Cette organisation évite de copier des règles de routage dans chaque script. Elle offre aussi aux équipes de support et de confidentialité un endroit stable pour examiner un changement de route sans lire le code d'automatisation des pages. Utilisez des noms de politique descriptifs et gardez chaque politique centrée sur un seul objectif de déploiement, car une tâche de validation régionale, un test d'application interne et un flux multimédia ne doivent pas partager une grande politique uniquement parce qu'ils s'exécutent sur le même nœud. Les petites politiques sont plus faciles à revoir, à versionner et à annuler.

Les scripts PAC standard continuent d'utiliser FindProxyForURL(url, host) pour la sélection ordinaire du proxy. Pour les profils ENT Tier3 approuvés, le même script PAC de confiance peut aussi définir BotBrowserFindProxyForRequest, un callback BotBrowser qui reçoit l'URL, l'hôte, la méthode, les en-têtes et l'état du corps de la requête. Le callback ne remplace pas le PAC standard. Lorsqu'il renvoie CONTINUE ou aucun résultat valide, le routage revient à la fonction standard. Le callback peut effectuer les actions suivantes :

• Poursuivre la requête et conserver la route PAC standard.
• Bloquer la requête.
• Écrire un court enregistrement de capture étiqueté vers un chemin absolu approuvé.
• Router uniquement la requête en cours par un autre résultat PAC standard, tel que DIRECT, HTTPS ou SOCKS5.
• Terminer la requête par une réponse synthétique contrôlée.

Les résultats peuvent être combinés avec des points-virgules. La capture est écrite en premier. Une réponse contrôlée termine ensuite la requête et prend le pas sur le blocage et le routage ; sans réponse, le blocage prend le pas sur une route. Une réponse mal formée, trop volumineuse, non sûre ou non prise en charge échoue en mode fermé et n'est jamais envoyée à la destination ni au proxy.

Le callback n'est disponible que pour les profils approuvés et les sources PAC explicites : fichiers PAC file:, URL PAC data:, services PAC HTTP(S) en loopback et services PAC HTTP(S) distants que votre équipe contrôle. La détection automatique de PAC et WPAD restent valables pour le routage PAC standard, mais ils ne reçoivent pas le callback. Privilégiez des sources file: ou en loopback pour les nœuds locaux, et utilisez HTTPS lorsque la source est distante.

Les réponses contrôlées obéissent à une politique de sources plus restreinte que celle du callback. Elles sont limitées aux profils approuvés qui chargent une source PAC file: ou data:. Une source PAC HTTP(S) peut toujours router, capturer et bloquer des requêtes, mais elle ne peut pas renvoyer de réponse contrôlée. Les administrateurs doivent placer la politique sous les mêmes contrôles d'accès que le paquet du profil et refuser les voies de livraison non revues.

Les réponses contrôlées conviennent aux endpoints et aux fixtures que le déploiement possède, comme un résultat de disponibilité, une ressource de test stable ou une réponse déterministe utilisée dans un flux autorisé de contrôle qualité. Gardez les fixtures détenues séparées du trafic réel vers des destinations. Elles doivent servir à des tests reproductibles et à des vérifications opérationnelles, non à remplacer la navigation ordinaire vers des services tiers.

Cas d'usage adaptés de la politique de requêtes PAC

Cohérence régionale des routes

Une session adossée à un profil peut avoir besoin d'une route conforme à sa région. PAC peut garder la navigation et les requêtes associées sur la famille de routes approuvée sans dupliquer la logique de sélection entre les frameworks d'automatisation.

Chemins internes et externes des applications

Un test d'entreprise peut combiner un service interne et des dépendances web publiques. Une petite politique PAC peut garder le trafic interne sur le chemin privé prévu pendant que le trafic externe emprunte la route proxy approuvée.

Nœuds à plusieurs contextes

Les nœuds qui créent et ferment des contextes de navigateur ont besoin d'une responsabilité prévisible. Associer chaque configuration de contexte à son profil et à sa politique facilite la revue ultérieure et réduit la dépendance à des hypothèses valables pour tout le processus. Le guide du proxy par contexte explique comment attribuer des routes à des contextes distincts.

Contrôle qualité reproductible

Les fixtures détenues peuvent supprimer une variabilité réseau inutile sur un chemin de test choisi. Avec une source de politique locale approuvée, les réponses contrôlées permettent cet usage limité pendant que le reste de la page suit le réseau standard du navigateur.

Protections et validation fondée sur les résultats

Enregistrez proxy, direct et blocked comme les trois résultats attendus pour chaque URL.

Traitez la source PAC, le profil du navigateur et l'inventaire des proxies comme une seule unité de version revue.

• Limitez qui peut modifier la source de la politique.
• Gardez la référence de la politique approuvée explicite dans la configuration du déploiement.
• Utilisez le contrôle de version pour les fichiers de politique stables.
• Examinez la responsabilité des routes avant de changer les identifiants ou les régions du proxy.
• Démarrez une nouvelle session du navigateur lorsque la configuration de la tâche change.
• Gardez les fixtures contrôlées sous les mêmes contrôles d'accès que le flux de test.
• Préférez une petite liste d'autorisation de classes de requêtes à une politique générale qui couvre tout.

La livraison distante des politiques exige la même revue du transport et des accès que les autres configurations de production. Le fait que le PAC standard accepte davantage de types de sources ne doit pas être confondu avec une autorisation d'utiliser des réponses contrôlées.

La validation doit confirmer le résultat du déploiement sans collecter de données de page inutiles. Commencez par le plan de routes. Notez quelles classes de requêtes doivent utiliser chaque route approuvée et lesquelles doivent rester sur le comportement PAC standard. Exécutez le flux autorisé habituel et comparez son résultat réseau observable à ce plan.

Vérifiez ensemble l'alignement du profil et de la route. La région, la langue, le fuseau horaire et la sortie du proxy doivent décrire un environnement cohérent. Pour les tâches à plusieurs contextes, examinez chaque contexte séparément afin qu'un contexte réussi ne masque pas un problème de configuration dans un autre.

Pour une fixture contrôlée détenue, confirmez le comportement attendu de l'application par les vérifications ordinaires de l'application. Examinez ensemble l'identifiant de la politique effective, l'affectation du profil, le registre d'accès et le résultat du navigateur. Ces observations montrent si le déploiement respecte son plan de routes approuvé. Joignez le résultat au même dossier de version que celui utilisé pour décider du déploiement et du retour arrière.

Gardez des preuves de validation concises. La version de la politique, la famille de profil, la famille de routes attendue, la sortie observée et le résultat du flux suffisent généralement pour un dossier de version.

Responsabilité, déploiement et dossiers

Ajoutez aussi routeClass au dossier afin de distinguer une route régionale d'une route de test.

Conservez policyVersion, effectiveAt, owner et rollbackTarget lors de chaque déploiement.

Une politique de routage agit sur le trafic du navigateur avant que l'automatisation des pages n'évalue le résultat. Attribuez à chaque politique un responsable nommé qui comprend les chemins d'application qu'elle régit. Cette personne doit pouvoir expliquer pourquoi chaque classe de routes existe, quelles familles de profils l'utilisent et quelle équipe approuve les changements. L'exploitation des proxies peut rester une responsabilité distincte, mais la frontière entre le choix d'une route et sa disponibilité doit être écrite.

Examinez la politique comme un élément de configuration de production. Un bon dossier de revue contient le nom de la politique, sa révision, les groupes de déploiement concernés, les familles de profils qui lui sont affectées et le résultat attendu pour chaque classe de routes approuvée. Il doit aussi indiquer la révision de retour arrière et la personne chargée de cette décision. Ce contexte suffit pour qu'un opérateur agisse sans copier la politique dans un ticket ni exposer des détails qui n'ont pas leur place dans un dossier opérationnel.

Évitez le partage informel de politiques entre tâches. Une politique qui convient à une application peut inclure des hypothèses sur les régions, les services privés ou la propriété des proxies qui ne s'appliquent pas ailleurs. Créez une politique revue distincte lorsque l'objectif change. Ce dossier supplémentaire coûte moins cher que l'enquête sur une route inexpliquée lorsque deux déploiements ont évolué séparément.

Les identifiants ne doivent pas figurer dans un texte de politique copié dans des tickets ni dans l'automatisation du navigateur. Utilisez le circuit normal de gestion des secrets du déploiement et limitez l'accès aux comptes de service qui exécutent la tâche approuvée. Faites tourner les identifiants indépendamment de la logique de routage lorsque la plateforme le permet, puis exécutez les mêmes vérifications autorisées de l'application que pour une version normale. Le guide sur l'authentification du proxy et l'hygiène des identifiants décrit cette pratique plus en détail.

Commencez par un petit groupe de déploiement représentatif de l'environnement de production. Utilisez la version prévue du navigateur, la famille de profil, le système d'exploitation, l'inventaire des proxies et la version d'automatisation. Un test sur un ordinateur portable de développement peut confirmer la syntaxe, mais il ne prouve pas que la responsabilité des routes, les identifiants et les contrôles d'accès de production sont corrects.

Comparez le groupe de test à un groupe inchangé sur la même période. Les observations utiles sont l'achèvement réussi de l'application, l'état de démarrage et de sortie du navigateur, la disponibilité du proxy, le résultat par famille de routes et le nombre de tâches remises dans la file. Gardez comparables l'ensemble de pages et le mélange de tâches. Si plusieurs paramètres changent en même temps, la comparaison ne montrera pas si la politique a aidé ou si elle a seulement coïncidé avec une autre charge.

Étendez le déploiement groupe par groupe plutôt que de modifier tous les nœuds à la fois. Mettez le déploiement en pause lorsque le résultat de l'application, la stabilité du navigateur ou le registre de responsabilité des routes ne correspondent plus au plan de version. Restaurez la politique revue précédente avant de tenter un second changement. Le retour arrière reste ainsi prévisible et la base de comparaison suivante reste claire.

Les nœuds de longue durée doivent recevoir les changements de politique par le même cycle de vie que les mises à jour de profil et de navigateur. Terminez ou arrêtez le travail attribué selon les règles d'arrêt habituelles de l'application, puis démarrez une nouvelle session du navigateur avec la nouvelle unité de version. Mélanger une ancienne session du navigateur avec une nouvelle affectation de politique rend les dossiers de support difficiles à interpréter.

Les enregistrements de routage peuvent révéler des informations opérationnelles sensibles même lorsqu'ils ne contiennent pas de contenu de page. Limitez la collecte à ce dont une revue de support ou de confidentialité a besoin : révision de la politique, famille de profil, famille de routes approuvée, groupe de déploiement, plage horaire et résultat de l'application. Évitez de conserver des historiques complets de destinations uniquement pour prouver qu'une politique était active.

Appliquez à ces enregistrements le calendrier de conservation ordinaire de l'organisation. Un enregistrement de préproduction de courte durée peut ne nécessiter que la fenêtre de version, alors qu'un flux de production réglementé peut exiger une piste d'audit plus longue. Le responsable du déploiement doit fixer la durée avant le lancement et consigner qui peut lire ou exporter l'enregistrement. Ne laissez pas les journaux du navigateur devenir une copie non gérée de l'historique réseau. Les enregistrements de capture écrits par le callback suivent la même règle : leur chemin, leur étiquette et leur durée de conservation font partie de la politique revue.

Les revues d'accès doivent couvrir à la fois la modification et l'affectation des politiques. Quelqu'un qui ne peut pas modifier le texte d'une politique peut tout de même rattacher une politique existante au mauvais groupe de déploiement. Examinez ces droits ensemble. Supprimez les affectations qui n'ont plus de responsable actif et retirez les révisions de politique qui ne sont plus disponibles pour un retour arrière.

Reprise et maintenance

Utilisez lastKnownGood, errorCode et retryAt pour distinguer la reprise d'un nouveau déploiement.

Lorsqu'un flux autorisé produit un résultat de route inattendu, cessez d'envoyer de nouvelles tâches au groupe de déploiement concerné. Gardez disponibles la dernière révision de politique réussie et le dossier de version. Confirmez que la famille de profil affectée, la version du navigateur, l'inventaire des proxies et la révision de la politique correspondent au changement approuvé. Cette première comparaison révèle souvent une dérive de configuration sans enquête au niveau de la page.

Vérifiez l'état des routes proxy approuvées de façon indépendante, avec la supervision habituelle de l'infrastructure de l'organisation. Une route peut être indisponible alors que la politique n'a pas changé. De même, un proxy en bonne santé ne prouve pas que la politique prévue a été affectée. Traitez le choix de la politique et la disponibilité de la route comme deux faits distincts, puis comparez-les au résultat de l'application. Le guide de basculement de proxy explique quoi faire lorsque la route elle-même est indisponible.

Modifiez un seul composant de la version à la fois pendant la reprise. Restaurer la politique précédente tout en changeant le paquet de profil, la version du navigateur et la région du proxy détruit la base de comparaison. Revenez d'abord à la dernière unité revue. Lorsque les vérifications ordinaires de l'application réussissent, introduisez le changement suivant par le processus de déploiement progressif.

Le dossier d'incident doit indiquer le résultat visible par l'utilisateur, les groupes de déploiement concernés, la dernière révision connue comme correcte, l'action corrective et le résultat de la validation de la version. Résumez le comportement observé au lieu de conserver des données de page requête par requête. Ce dossier plus restreint soutient la responsabilité tout en respectant la limite de confidentialité de la session de navigation.

Passez en revue les politiques actives à intervalles réguliers et après les changements importants de l'application, du navigateur, du profil ou du réseau. Confirmez que chaque classe de routes a toujours un objectif et un responsable à jour. Supprimez les classes inutilisées au lieu de les laisser disponibles pour un éventuel travail futur. Une politique plus courte est plus facile à raisonner pendant une version et risque moins de porter des hypothèses obsolètes.

Vérifiez que les liens de documentation pointent vers la version actuelle du produit et que les modèles de déploiement référencent une révision de politique active. Testez le matériel de retour arrière tant qu'il est valide. Une révision qui n'existe que dans un ancien ticket n'est pas une option de reprise fiable si son inventaire de proxies ou son affectation de profil ont déjà été retirés.

Associez les responsables de la confidentialité et du support à la revue de maintenance. L'exploitation peut confirmer l'état des routes, tandis que la confidentialité vérifie que la collecte et la conservation restent proportionnées. Le support peut repérer les questions de configuration récurrentes qui devraient être résolues dans les modèles de déploiement. Cette revue partagée garde la politique utile sans élargir son périmètre.

Erreurs de configuration courantes

Comparez proxy.pac, --proxy-pac-url et le code DIRECT avant d'accuser le navigateur.

• Considérer toutes les sources de politique comme équivalentes. Les exigences de source varient selon la capacité ; choisissez donc une source documentée et approuvée pour le flux prévu et revoyez ce choix lorsque le navigateur ou le paquet de politiques change.
• Répartir la responsabilité du routage entre plusieurs couches. Lorsque PAC, les gestionnaires du framework et un service externe de transfert choisissent tous des routes, le chemin final devient difficile à expliquer ; choisissez donc un seul responsable pour chaque décision.
• Réutiliser une politique pour des profils sans rapport. Une politique créée pour une région ou une famille de navigateurs peut ne pas convenir à une autre ; revoyez-la donc lorsque la famille de profil, la région du proxy ou le rôle du nœud change.
• Employer les réponses contrôlées pour le trafic web réel. Elles sont destinées aux fixtures détenues et aux chemins de test autorisés, et le trafic ordinaire vers les destinations doit continuer par le réseau standard du navigateur.

Ce que BotBrowser prend en charge et où il s'arrête

BotBrowser prend en charge le routage PAC standard via --proxy-pac-url et, pour les profils ENT Tier3 approuvés, un callback de requêtes de confiance dans le même script PAC qui peut poursuivre, bloquer, capturer, router une seule requête ou renvoyer une réponse synthétique contrôlée depuis une source PAC file: ou data:. La politique de routes reste ainsi dans le chemin réseau du navigateur, et votre équipe revoit une politique associée à chaque profil au lieu d'une logique de routage dispersée dans des scripts d'automatisation. BotBrowser ne peut pas rendre une route proxy disponible ni saine, ne peut pas approuver une politique au nom de votre organisation, n'autorise pas les réponses contrôlées depuis des sources PAC HTTP(S) et ne vérifie pas à qui appartient une destination, donc réserver les réponses contrôlées à des fixtures détenues plutôt qu'au trafic réel de tiers relève de la politique de votre équipe.

Consultez la documentation du callback de requêtes PAC pour les sources prises en charge, les valeurs de retour et les exigences opérationnelles, ainsi que le guide de configuration du proxy pour les choix de proxy sous-jacents. L'article sur la configuration du proxy explique comment ces choix s'articulent.

Sources publiques

• MDN : fichier Proxy Auto-Configuration (PAC)
• Documentation de BotBrowser PAC-Like Request Callback

Practical conclusion

Conservez dans un même dossier la source PAC, l'inventaire des proxies approuvés, le profil et la révision de retour arrière. Validez le résultat de la route avant d'exposer le flux au trafic de production.