PAC Request Policy : fonctions de requête au niveau navigateur

Introduction

Les fichiers Proxy Auto-Config font partie du networking des navigateurs depuis longtemps. Un fichier PAC permet au navigateur de décider, pour chaque requête, s'il doit utiliser un proxy ou se connecter directement. Cette décision se produit dans la couche réseau du navigateur avant que la requête quitte le navigateur, ce qui distingue PAC des scripts de page, des hooks de framework ou des gestionnaires de requêtes au niveau application.

Cette fonction ancienne reste utile parce que les workflows navigateur modernes sont plus complexes. Les équipes n'exécutent plus seulement un navigateur sur une machine avec un proxy. Elles exécutent des sessions avec profil, des hôtes Windows, macOS et Linux, des serveurs headless, des pools de proxy, des routes régionales, de longues chaînes de navigation, des pages riches en médias et plusieurs frameworks d'automatisation. Les décisions de routage doivent rester alignées avec l'identité du navigateur au lieu d'être dispersées dans des scripts auxiliaires.

Le support PAC Request Policy de BotBrowser étend ce modèle pour les workflows enterprise approuvés. Il maintient la politique sensible aux requêtes près du stack réseau géré par le navigateur tout en préservant le comportement PAC normal. Le résultat est une façon plus propre d'exprimer une politique de requêtes sans déplacer chaque décision de routage dans du code de page ou des gestionnaires propres à un framework.

Cet article couvre le modèle public de fonctions PAC, les actions de requête prises en charge, les sources de déploiement et les cas où une politique de requête dans le navigateur est plus claire qu'une interception dans le framework. Pour la référence courte, consultez PAC Request Policy et la référence des flags CLI.

Pourquoi PAC compte encore

PAC est simple en apparence : le navigateur demande à une politique quelle route utiliser pour une URL. Cette simplicité est le point fort. Le routage appartient près du stack réseau du navigateur, pas après qu'un framework de page a déjà commencé à traiter les requêtes.

Une décision de proxy dépend souvent de plus que du hostname. Certaines requêtes doivent passer par une route résidentielle ou mobile. Certaines doivent utiliser un proxy régional. Certains services internes doivent rester sur une route locale. Certains assets statiques peuvent utiliser un chemin différent de la navigation authentifiée. Certains workflows enterprise doivent garder quelques classes de requêtes sous une politique plus stricte tout en laissant le reste de la page suivre le comportement normal du navigateur.

Mettre ces décisions dans le code applicatif peut fonctionner pour de petits scripts, mais cela devient difficile à maintenir lorsque le workflow grandit. Un route handler Playwright, un gestionnaire Puppeteer, un proxy latéral, un service Node et un fichier PAC deviennent autant d'endroits séparés où le comportement des requêtes peut changer. Lorsqu'un cas support apparaît, la première question devient : quelle couche a réellement pris la décision de routage ?

PAC réduit cette ambiguïté. Le navigateur possède la question de routage. La règle accompagne la configuration de lancement. La même politique suit plus naturellement les navigations, sous-ressources, redirections et requêtes gérées par le navigateur.

Pour le travail navigateur orienté confidentialité, c'est important parce que l'identité n'est pas seulement JavaScript. Chemin réseau, sélection de route, locale du profil, fuseau horaire, comportement de famille navigateur et signaux runtime doivent être cohérents. Un profil peut sembler cohérent dans la page tout en étant affaibli par un routage incohérent. PAC rend explicite ce côté réseau du modèle.

Le problème de la logique hors navigateur

Les frameworks d'automatisation fournissent des contrôles de requête utiles. Ils sont pratiques pour les tests, les mocks et les tâches simples. Ils ne sont pas toujours le meilleur endroit pour porter une politique enterprise de routage.

Les gestionnaires au niveau page sont souvent limités à une page ou à un contexte. Ils peuvent nécessiter une étape propre au framework. Ils dépendent souvent de l'activation d'un mode de gestion avant la navigation. Ils deviennent plus difficiles à raisonner lorsque des service workers, redirections, preloads, popups ou requêtes gérées par le navigateur entrent dans le workflow.

Les services proxy latéraux ont un autre compromis. Ils centralisent la logique réseau hors du navigateur, mais séparent la politique du profil qui définit l'identité navigateur. Le service proxy voit le trafic réseau, mais il peut ne pas savoir quel profil, contexte ou identité de famille navigateur doit être actif. Les équipes peuvent transmettre des métadonnées supplémentaires, mais le modèle opérationnel devient alors plus grand que la session navigateur elle-même.

Les flags de lancement fixes ont aussi leurs limites. Une seule valeur --proxy-server est propre lorsqu'une route suffit. Elle devient trop large lorsque le navigateur doit choisir une route par classe de requête, groupe de domaines, environnement ou étape de workflow.

PAC comble l'espace entre ces extrêmes. Il est natif du navigateur, sensible aux requêtes et déployable comme petit fichier de politique. Il peut rester près du lancement navigateur, voyager avec la configuration de session et rester compréhensible lors d'une revue support.

L'approche de BotBrowser

BotBrowser prend en charge une politique PAC de confiance pour les workflows enterprise qui doivent garder les décisions de routage dans le modèle réseau du navigateur. Le routage PAC standard reste disponible. Les équipes peuvent continuer à utiliser PAC pour choisir des routes directes, des proxies HTTP, HTTPS, SOCKS ou d'autres résultats PAC normaux pris en charge par le navigateur.

La valeur supplémentaire est la cohérence opérationnelle. Une politique PAC de confiance peut vivre à côté du profil et de la configuration de lancement. Cela maintient politique de routage, identité navigateur, configuration proxy et point d'entrée d'automatisation dans le même paquet révisable. Cela évite aussi de disperser les décisions dans des scripts de page et du code de framework lorsque la couche réseau du navigateur est le propriétaire naturel.

La configuration utilise la forme standard --proxy-pac-url :

chromium-browser \
  --bot-profile="profiles/profile.enc" \
  --proxy-pac-url="file:///absolute/path/to/policy.pac"

Un service PAC contrôlé en loopback est aussi courant lorsqu'une politique est fournie par un outil interne :

chromium-browser \
  --bot-profile="profiles/profile.enc" \
  --proxy-pac-url="http://127.0.0.1:8080/policy.pac"

Gardez la source explicite. Un fichier local est facile à auditer et à versionner avec la définition du job. Un service loopback est utile lorsqu'un outil interne choisit une politique par worker. Dans les deux cas, la politique doit être traitée comme une partie de l'environnement navigateur, pas comme un script auxiliaire incident.

PAC Request Policy est destiné à un usage enterprise approuvé. Il doit être associé à une identité navigateur basée sur profil, une propriété claire des routes et une validation privacy normale. Il ne remplace pas les contrôles d'utilisation responsable ni les vérifications d'autorisation côté client.

Modèle public de fonctions

BotBrowser PAC Request Policy conserve d'abord l'entrypoint PAC normal :

function FindProxyForURL(url, host) {
  if (dnsDomainIs(host, "example.internal")) {
    return "DIRECT";
  }
  return "SOCKS5 proxy.example.com:1080";
}

FindProxyForURL(url, host) reste la bonne fonction pour la sélection proxy ordinaire. Elle reçoit l'URL et le host, puis retourne un résultat PAC standard comme DIRECT, PROXY, HTTPS, SOCKS, SOCKS4 ou SOCKS5.

Les profils ENT Tier3 approuvés peuvent ajouter le callback BotBrowser dans la même source PAC de confiance :

function BotBrowserFindProxyForRequest(url, host, method, headersB64, bodyB64, bodyState) {
  if (method === "POST" && dnsDomainIs(host, "api.example.test")) {
    return "CAPTURE; CAPTURE_FILE /var/botbrowser/captures/api.jsonl; CAPTURE_TAG api-post; CONTINUE";
  }
  if (shExpMatch(url, "https://media.example.test/*")) {
    return "SOCKS5 media-proxy.example.net:1080";
  }
  if (dnsDomainIs(host, "static.example.test")) {
    return "HTTPS static-proxy.example.net:8443";
  }
  return "CONTINUE";
}

BotBrowserFindProxyForRequest est évalué comme callback de politique de requête du navigateur. Il ne supprime pas PAC standard. Lorsque le callback retourne CONTINUE, ou lorsqu'il ne retourne pas de route valide, la requête continue via le routage PAC normal. Lorsqu'il retourne une route PAC standard, cette route s'applique à la requête courante.

Le callback reçoit six valeurs :

Paramètre	Signification
url	URL complète de la requête.
host	Hostname de la requête.
method	Méthode HTTP, par exemple GET ou POST.
headersB64	Enregistrement des headers de requête encodé en Base64.
bodyB64	Body de requête encodé en Base64 lorsque les bytes sont disponibles.
bodyState	État de disponibilité du body : none, bytes, file, stream, too_large ou unsupported.

Cela donne à la politique PAC plus de contexte que FindProxyForURL, tout en gardant la décision dans le chemin réseau du navigateur.

Actions de requête

Le callback BotBrowser peut retourner des actions de routage, des actions de contrôle et des actions de capture. Les actions peuvent être combinées avec des points-virgules.

Valeur retournée	Comportement
CONTINUE	Continue le traitement de la requête et utilise PAC standard si le callback ne fournit pas de route.
BLOCK	Arrête la requête.
CAPTURE	Active la capture pour cette requête lorsqu'elle est associée à CAPTURE_FILE <path>.
CAPTURE_TAG <tag>	Ajoute un tag court à l'enregistrement de capture.
CAPTURE_FILE <path>	Écrit les enregistrements de capture vers un chemin absolu approuvé lorsqu'il est associé à CAPTURE.
DIRECT	Connecte directement pour la requête courante.
PROXY host:port	Route la requête courante via un proxy HTTP.
HTTPS host:port	Route la requête courante via un proxy HTTPS.
SOCKS host:port	Route la requête courante via un proxy SOCKS.
SOCKS4 host:port	Route la requête courante via un proxy SOCKS4.
SOCKS5 host:port	Route la requête courante via un proxy SOCKS5.

La capture est explicite. CAPTURE_FILE <path> seul n'écrit pas d'enregistrement. CAPTURE et CAPTURE_FILE <path> doivent apparaître ensemble. CAPTURE; CAPTURE_FILE <path>; BLOCK écrit l'enregistrement approuvé puis arrête la requête. CAPTURE; CAPTURE_FILE <path>; CAPTURE_TAG <tag>; CONTINUE enregistre la requête et conserve la route normale.

La chaîne de retour peut aussi mélanger politique et sélection de route. Une requête media peut retourner une route SOCKS5, un host interne peut retourner DIRECT, et une navigation ordinaire peut retourner CONTINUE afin que la décision par défaut de FindProxyForURL reste active.

Sources PAC de confiance

Le callback de requête est disponible uniquement depuis des sources PAC explicites contrôlées par le déploiement :

• Fichiers PAC file://.
• URLs PAC data:.
• Services PAC HTTP(S) en loopback.
• Services PAC HTTP(S) distants explicites contrôlés par l'opérateur.

PAC auto-detect et WPAD restent utiles pour le routage PAC standard, mais ne sont pas la bonne source pour les callbacks de requête BotBrowser. Une request policy enterprise doit venir d'un fichier connu, d'un service loopback contrôlé ou d'un service distant contrôlé sur HTTPS.

Ce modèle de confiance compte en production. Le fichier PAC peut router le trafic, arrêter certaines requêtes ou écrire des enregistrements de capture approuvés. Traitez-le comme une partie du paquet de lancement navigateur, avec la même discipline de revue que les profils, l'inventaire proxy et la configuration worker.

Où l'utiliser

PAC Request Policy est surtout utile lorsqu'un workflow comporte plusieurs classes de requêtes mais doit conserver une identité navigateur cohérente.

Un workflow de recherche ou de monitoring peut avoir besoin que les navigations suivent une route régionale tandis que les assets statiques utilisent une autre route. Un workflow QA peut garder les hosts internes en local tandis que les pages externes suivent la route choisie par le profil. Un job de validation multi-région peut vouloir définir le choix de route par une petite table de politique plutôt que par des chemins de code différents dans chaque script.

Il aide aussi lorsque l'équipe veut que le même workflow tourne sous Playwright, Puppeteer, CDP direct ou un service worker sans réécrire la logique de route pour chaque framework. La politique reste dans PAC. Le framework lance le navigateur et pilote la page. Le navigateur possède la décision de route réseau.

La séparation garde les responsabilités claires :

• Le profil définit l'identité navigateur.
• La configuration proxy définit les chemins réseau disponibles.
• La politique PAC sélectionne la route pour chaque classe de requête.
• Le framework d'automatisation exécute le workflow.
• Le processus de validation vérifie que le résultat reste cohérent.

Cette division donne aux équipes support, QA et plateforme moins d'endroits à inspecter lorsque le comportement change.

Relation avec les workflows per-context

L'opération per-context accroît le besoin de frontières propres. Une seule instance navigateur peut héberger plusieurs contextes indépendants, chacun avec son profil, sa route proxy, son stockage et son comportement runtime. Si la logique de requêtes est dispersée dans des gestionnaires de page, il devient plus difficile de savoir quelle règle appartient à quel contexte.

PAC Request Policy permet de garder la politique réseau près de la configuration de lancement du contexte. Un contexte peut porter le profil et la politique de routage dont il a besoin sans dépendre d'hypothèses globales de processus. C'est particulièrement important lorsque des workers sont réutilisés, que des contextes sont créés et détruits dans le temps, ou qu'un fleet exécute plusieurs familles de profils sur le même hôte.

Le même principe s'applique à la cohérence de famille navigateur. Une identité basée sur profil ne doit pas être séparée du comportement réseau. Si un workflow valide une famille navigateur, une région et une route, la politique de requêtes doit faire partie du paquet de validation.

Notes de déploiement

Traitez la politique PAC comme une configuration de production. Stockez-la avec la définition du job, révisez-la comme du code et gardez-la assez petite pour qu'un opérateur comprenne le routage attendu.

Préférez des sources explicites. Un fichier local fonctionne bien pour les déploiements stables. Un service loopback fonctionne lorsqu'un agent worker doit fournir une politique pour le job courant. Évitez de dépendre d'un état ambiant de machine difficile à reproduire.

Utilisez des noms descriptifs. Un fichier policy.pac dans un répertoire de job est plus facile à réviser qu'un chemin généré dont le rôle n'est pas clair. Si une politique est générée, émettez un manifeste avec le job pour que le lancement puisse être reproduit.

Gardez la propriété des routes claire. Si une route de page change, le fichier PAC doit être le premier endroit à inspecter. Si un identifiant proxy change, l'inventaire proxy doit être vérifié en premier. Si un profil change, le paquet de profil est le premier point de revue. Mélanger ces sujets dans un helper rend le support plus lent.

Pour les workflows sensibles, évitez de journaliser le contenu des requêtes depuis du code d'automatisation généraliste. Les logs opérationnels doivent se concentrer sur la décision de route, la version de politique, la famille de profil et le résultat global. Les preuves détaillées doivent rester dans des paquets support contrôlés lorsqu'une revue autorisée les exige.

Validation

La validation doit confirmer que le comportement de la politique correspond au plan de déploiement sans transformer la documentation en recette d'inspection bas niveau.

Commencez par une matrice simple de routes. Listez les classes de requêtes importantes, la famille de route attendue pour chacune et la famille de profil qui exécutera la session. Gardez cette matrice près de la configuration.

Exécutez le workflow avec le même profil et le même setup de route que la production. Relisez ensemble comportement de page, comportement de route et cohérence des signaux navigateur. Une politique qui fonctionne seulement dans un test synthétique mais change pendant une vraie chaîne de navigation n'est pas suffisante.

Répétez la même validation avant et après les mises à jour navigateur, profil ou inventaire proxy. PAC a le plus de valeur lorsqu'il devient partie du processus de release plutôt qu'une option de lancement ponctuelle.

À l'échelle, validez un échantillon représentatif de workers plutôt qu'une seule machine locale. Le comportement de routage peut dépendre du réseau hôte, de la disponibilité proxy, des chemins de fichiers et de l'ordre de démarrage des services. Une politique stable dans le fleet réel est plus utile qu'une politique qui marche uniquement dans un shell de développement.

Erreurs courantes

La première erreur consiste à traiter PAC comme un détail secondaire. Si le chemin réseau du navigateur importe pour la confidentialité et la cohérence, le fichier PAC fait partie de l'environnement produit. Il doit être versionné, revu et gardé avec la configuration de lancement.

La deuxième erreur consiste à répartir la même règle sur trop de couches. Si une décision vit en partie dans PAC, en partie dans Playwright, en partie dans un proxy latéral et en partie dans du code de job, le support devient incertain. Choisissez le propriétaire de chaque décision et gardez-la là.

La troisième erreur est d'utiliser PAC pour compenser un profil incohérent. PAC peut sélectionner des routes. Il ne peut pas rendre cohérent un profil incohérent. Identité navigateur, locale, fuseau horaire, région proxy et politique de route doivent encore être planifiés ensemble.

La quatrième erreur est de rendre la politique trop intelligente. Une petite politique couvrant les routes vraiment nécessaires est plus facile à valider qu'une grande politique avec des branches rarement utilisées. Commencez avec la carte minimale et ajoutez seulement lorsque les opérations l'exigent.

La cinquième erreur est d'oublier headless et les serveurs. Si la production tourne dans des conteneurs Linux ou serveurs headless, tester seulement sur desktop local ne suffit pas. Validez chargement PAC, accès fichier, démarrage loopback et comportement de route sous la même forme de déploiement.

Quand l'utiliser

Utilisez PAC Request Policy lorsque le navigateur a besoin d'un routage sensible aux requêtes et que la politique doit rester liée à l'environnement navigateur.

Il convient à l'automatisation enterprise, la validation régionale, les workflows longs, le routage per-context et la QA de production lorsque le comportement de route doit être répétable. Il est aussi utile lorsque les équipes veulent un seul modèle de politique utilisable sous plusieurs frameworks.

Il n'est pas nécessaire pour les déploiements simples où toutes les requêtes utilisent le même proxy. Dans ce cas, --proxy-server reste l'option la plus propre. Il ne remplace pas non plus la planification des profils, la gestion de l'inventaire proxy ou les contrôles d'utilisation responsable.

La règle pratique est simple : si les décisions de route font partie de l'identité navigateur et du processus support, gardez-les dans le modèle réseau du navigateur. Si le workflow ne demande qu'une route, gardez la configuration simple.

Il existe aussi un signal de processus d'équipe. Si les changements de route exigent une coordination entre ingénieurs navigateur, infrastructure, QA et support, PAC est souvent le bon endroit pour centraliser la politique. Le lancement indique quelle politique est active, la politique indique quelle famille de route s'applique et la validation confirme le résultat contre le même fichier.

FAQ

Est-ce la même chose qu'un fichier PAC normal ?

Le modèle commence par PAC standard. Le routage PAC standard reste disponible. BotBrowser ajoute un modèle opérationnel enterprise autour de sources PAC de confiance afin que la politique reste proche des sessions basées sur profil.

Est-ce que cela remplace --proxy-server ?

Non. Utilisez --proxy-server lorsqu'une seule route proxy suffit. Utilisez PAC lorsque le navigateur a besoin d'un routage sensible aux requêtes sous une politique révisable.

Peut-on utiliser un fichier PAC local ?

Oui. Un fichier PAC local est un bon choix lorsque la politique est stable et doit être versionnée avec le job. Un service loopback contrôlé est utile lorsqu'un outil interne doit fournir une politique dynamique pour un worker.

Est-ce compatible avec les frameworks d'automatisation ?

Oui. Le framework lance et pilote le navigateur, tandis que PAC reste propriétaire de la sélection de route. La politique dépend moins d'une API de gestion de requêtes propre à un framework.

Tous les workflows doivent-ils utiliser PAC ?

Non. PAC apporte de la valeur lorsque les décisions de routage varient par classe de requête ou par contexte. Les workflows simples à route unique doivent rester simples.

Résumé

PAC Request Policy donne aux équipes enterprise une façon, au niveau navigateur, de garder le routage des requêtes, l'identité de profil et les workflows d'automatisation alignés. Il conserve les forces de PAC standard tout en correspondant aux déploiements BotBrowser modernes : sessions basées sur profil, opération per-context, workers headless, routage proxy-aware et validation répétable.

Utilisez-le lorsque la politique de routage fait partie de l'environnement navigateur. Gardez la politique explicite, révisable et proche du profil et de la configuration de lancement. Validez-la avec le vrai workflow, pas seulement une page de test minimale. Pour les équipes qui traitent le navigateur comme infrastructure, cela garde la politique sensible aux requêtes dans le même modèle opérationnel que le reste du stack de protection de confidentialité BotBrowser.

Pour les détails de configuration, consultez PAC Request Policy, Proxy Configuration et Per-Context Proxy.