URL de proxy automatique : fichiers PAC et configuration WPAD

Une URL de proxy automatique pointe vers un fichier PAC, un petit script généralement nommé proxy.pac qui décide, pour chaque requête, s'il faut se connecter directement ou passer par un proxy. Cette approche est née en 1996, avec la conception par Netscape d'un navigateur capable de sélectionner automatiquement le mode de routage.

Vous avez probablement déjà vu ce type de problème. Quelqu'un de votre équipe colle un paramètre dans un navigateur, consulte une page de vérification d'IP, voit le pays attendu et déclare que tout est réglé. Quelques heures plus tard, un parcours d'assurance qualité affiche les prix locaux, une vérification publicitaire renvoie la mauvaise création ou un appel API en arrière-plan révèle le réseau de votre bureau. Le paramètre semblait correct, mais tout le trafic ne l'a pas suivi. C'est là que naissent la plupart des confusions, car une URL de proxy automatique n'est pas vraiment une adresse à laquelle envoyer le trafic. C'est une adresse qui mène à une décision.

Ce vers quoi pointe réellement une URL de proxy automatique

La personne responsable de la vérification publicitaire ouvre un navigateur de test à Lyon et voit une campagne exactement comme un utilisateur mobile français devrait la voir. Un collègue effectue la même vérification depuis un autre ordinateur portable et obtient la page mondiale par défaut. Tous deux jurent avoir utilisé « le proxy ». En pratique, l'un des appareils a récupéré le script de routage et l'a appliqué, tandis que l'autre a conservé un paramètre manuel ou n'a jamais récupéré le script.

C'est là la distinction essentielle. Un paramètre de proxy classique pointe vers un serveur, par exemple un hôte et un port. Une URL de proxy automatique pointe vers un fichier de configuration automatique du proxy, généralement appelé proxy.pac, que le navigateur ou le système d'exploitation télécharge et exécute. Imaginez qu'un proxy fixe soit une route que vous empruntez toujours. Un fichier PAC ressemble davantage à une application de navigation qui recalcule l'itinéraire à chaque trajet en fonction de la destination.

Pourquoi centraliser la décision est important

Le système repose sur la méthode de configuration automatique du proxy conçue à l'origine par Netscape en 1996 pour Netscape Navigator 2.0. Un fichier PAC contient une fonction JavaScript appelée FindProxyForURL(url, host), qui décide si chaque requête passe directement ou par un ou plusieurs proxys, comme l'explique le guide de Mozilla sur les fichiers PAC. L'Internet Engineering Task Force a ensuite documenté PAC dans la RFC 3040 en janvier 2001.

Ce contexte historique n'est pas anecdotique. La RFC 3040 indiquait que PAC simplifiait l'administration en centralisant les règles de proxy dans un seul script, permettant ainsi aux administrateurs de mettre à jour celui-ci au lieu de reconfigurer manuellement chaque agent utilisateur. Elle avertissait également que l'interopérabilité était imparfaite, car les navigateurs pouvaient interpréter différemment un même script.

Une URL de proxy automatique valide prouve qu'un appareil peut récupérer des instructions de routage. Elle ne prouve pas que toutes les applications de cet appareil les suivront.

Lorsque vous collez cette URL dans un écran de paramètres, vous ne choisissez pas un serveur de sortie. Vous choisissez qui décide de la sortie pour chaque requête, et à quelle vitesse vous pouvez modifier cette décision pour tout le monde sans intervenir manuellement sur chaque ordinateur portable, téléphone ou profil de navigateur.

Comment un fichier PAC décide où acheminer chaque requête

Suivons une requête. Votre navigateur veut ouvrir une page produit. Avant d'établir une connexion, il transmet l'URL et l'hôte à FindProxyForURL(url, host). La fonction évalue des règles simples et renvoie une instruction comme DIRECT ou le nom d'un proxy, parfois accompagnée de proxys de secours que le navigateur peut essayer si le premier ne fonctionne pas.

Un exemple simple permet de comprendre. Les outils internes peuvent renvoyer DIRECT, puisqu'ils se trouvent déjà sur votre réseau. Les cibles de recherche publiques peuvent renvoyer un proxy situé dans la région souhaitée. Un second proxy dans la liste renvoyée sert de solution de secours, et non de deuxième saut pour la même requête.

Limite liée à la mise en cache par nom d'hôte

Ne partez pas du principe que vous pouvez acheminer chaque chemin différemment. Les recommandations actuelles indiquent que la mise en cache automatique des résultats de proxy est indexée par nom d'hôte, ce qui limite la possibilité de choisir différents proxys en fonction du chemin de l'URL ou d'autres composants de l'URL. En pratique, deux pages sur le même hôte réutilisent souvent le même résultat de routage, même si vous espériez qu'un chemin de paiement se comporte différemment de la page d'accueil.

Ce qui change avec HTTPS

Une URL de proxy automatique ne modifie pas la sémantique des tunnels HTTP. Pour les destinations HTTPS, un client conforme se connecte au proxy configuré et envoie CONNECT destination-host:port. Après une réponse positive, le proxy relaie les octets chiffrés sans les examiner, tandis que TLS reste de bout en bout entre le client et la destination, conformément à la sémantique HTTP définie dans la RFC 9110.

Cette distinction permet de gagner du temps lors du dépannage :

• 400 Bad Request : Le port explicite dans CONNECT est obligatoire ; une valeur de port invalide ou vide doit entraîner ce rejet.
• 407 Proxy Authentication Required : Le proxy nécessite des identifiants et renvoie un défi Proxy-Authenticate.
• CONNECT réussit, mais TLS échoue : Le tunnel a été ouvert ; examinez donc l'établissement de la connexion avec la destination plutôt que d'incriminer la bande passante du proxy.
• Échecs répétés de CONNECT : Vérifiez d'abord l'authentification, les listes d'autorisation, les ports ou les règles de la destination.

Une URL de proxy commençant par ` peut tout de même acheminer du trafic HTTPS via CONNECT. Cela ne signifie pas que le proxy peut examiner le contenu de la page chiffrée. Mesurez séparément le temps de résolution DNS, le temps de connexion TCP, le taux de réussite de CONNECT, la latence de négociation TLS et le débit soutenu, sans quoi vous interviendrez sur la mauvaise couche.

Héberger un fichier PAC et permettre aux clients de le trouver

Votre script peut être parfaitement logique et pourtant ne servir à rien si les appareils ne peuvent pas le récupérer. L'hébergement est un travail d'infrastructure peu spectaculaire, mais c'est là que les équipes obtiennent soit des mises à jour sans effort, soit un point de défaillance unique et silencieux.

Placez proxy.pac sur un serveur web accessible à tous les appareils concernés, sans qu'ils aient besoin du proxy que vous essayez de configurer. C'est un piège courant pour le personnel à distance. Si un ordinateur portable doit utiliser le proxy pour accéder au fichier PAC, mais qu'il a besoin de ce fichier pour connaître le proxy, il ne pourra pas démarrer.

Deux façons pour les clients de découvrir le script

La méthode explicite est la plus simple à comprendre. Un administrateur ou un utilisateur saisit directement l'URL de proxy automatique dans les paramètres du système ou du navigateur. Vous savez exactement quel script l'appareil doit récupérer et pouvez tester cette même URL depuis un appareil vierge connecté au même réseau.

La méthode automatique est le WPAD, abréviation de Web Proxy Auto-Discovery. Les clients recherchent un emplacement wpad.dat via DNS ou DHCP, puis récupèrent la configuration à cet emplacement. WPAD réduit la configuration manuelle dans les réseaux de bureau gérés, mais augmente les enjeux liés au contrôle des noms. Si le mauvais hôte répond au nom WPAD, des instructions de routage que vous n'avez pas publiées peuvent être envoyées aux appareils.

Règle pratique : privilégiez une URL de proxy automatique explicite si vous ne pouvez pas contrôler entièrement DNS et DHCP sur tous les réseaux auxquels vos appareils se connectent.

Les changements ne sont pas non plus appliqués instantanément. Les clients n'appliquent une nouvelle version qu'après avoir récupéré le fichier, ce qui peut dépendre de la mise en cache, d'une reconnexion ou du redémarrage de l'application. Ne modifiez pas les règles de production quelques minutes avant une vérification de campagne en supposant que tous les postes utiliseront le nouveau comportement.

Liste de vérification succincte pour l'hébergement

• Versionnez le fichier : examinez les modifications de routage comme du code, car une règle erronée peut envoyer le trafic direct vers un proxy ou le trafic du proxy directement vers sa destination.
• Limitez les personnes autorisées à publier : toute personne capable de remplacer le fichier PAC peut influencer la destination du trafic du navigateur.
• Utilisez une URL stable : changer l'emplacement impose de reconfigurer les clients, ce qui va à l'encontre de l'objectif des mises à jour centralisées.
• Maintenez une URL de test : ouvrez-la depuis un appareil vierge situé en dehors du réseau d'administration et vérifiez que le script attendu se charge.
• Rédigez des règles lisibles : le dépannage sera plus difficile à l'avenir si personne ne sait pourquoi un hôte a été forcé à passer directement il y a plusieurs mois.

Configurer l'URL de proxy automatique sur les plateformes courantes

Commencez par prendre une décision avant de toucher à un menu. Ce routage doit-il s'appliquer à tout l'appareil ou uniquement à un profil de navigateur utilisé pour une tâche précise ? Un responsable des réseaux sociaux qui vérifie du contenu régional peut préférer un profil isolé. Un appareil de QA qui teste un parcours utilisateur complet a généralement besoin d'un comportement au niveau du système, sachant que toutes les applications ne le respectent pas.

Les intitulés des menus changent d'une version à l'autre : consultez donc la documentation officielle actuelle de la plateforme plutôt que de vous fier à des chemins de clics mémorisés. Les concepts ci-dessous restent les mêmes, même si leur formulation évolue.

Ordinateurs de bureau et navigateurs

Sous Windows et macOS, recherchez les paramètres réseau ou proxy du système qui proposent un script de configuration automatique ou une option de configuration automatique du proxy. Activez-la, collez l'URL du proxy automatique, enregistrez, puis redémarrez complètement le navigateur que vous testez. Certains navigateurs reprennent les paramètres du système d'exploitation, tandis que d'autres permettent un choix distinct : vérifiez donc quelle couche contrôle le routage.

Si vous travaillez au niveau du navigateur, consultez les étapes pour modifier les paramètres du proxy dans Chrome avant de supposer que le navigateur et le système d'exploitation sont d'accord. Un proxy manuel obsolète dans un profil peut remplacer votre nouveau script. Ce décalage explique de nombreux cas où les captures d'écran d'une personne ne correspondent pas aux résultats d'une autre.

Pour les déploiements en équipe, consignez trois éléments dans votre procédure :

• Périmètre : Tout le système, un navigateur ou un profil géré.
• Sortie attendue : Pays, type de réseau et tout comportement de session requis pour la tâche.
• Retour en arrière : Comment désactiver le script et revenir à DIRECT si l'hôte PAC tombe en panne.

Appareils mobiles

Sur mobile, configurez le proxy pour le réseau Wi-Fi concerné lorsque cette option est disponible, choisissez le paramètre automatique et saisissez l'URL PAC. Les recommandations actuelles de mise en œuvre indiquent qu'iOS peut gérer les PAC au niveau du système, tandis que les clients personnalisés Android tels qu'OkHttp peuvent nécessiter l'analyse explicite du PAC et l'exécution de JavaScript, une distinction expliquée dans ce guide d'intégration d'un proxy d'entreprise dans les applications mobiles.

Cette distinction doit changer votre façon de valider le routage. Une vérification réussie dans le navigateur d'un téléphone ne prouve pas que votre application, sa WebView intégrée ou son SDK d'analytique a emprunté le même itinéraire.

Exécutez une courte routine de vérification sur chaque plateforme. Chargez une page de test connue, confirmez l'IP de sortie à l'aide d'une page de vérification fiable, puis répétez exactement le même processus sur un deuxième appareil. Testez sur le réseau que les utilisateurs utiliseront réellement, et pas uniquement sur le Wi-Fi du bureau, à côté de la personne qui a écrit le script.

Types de proxy, sessions persistantes et IP mobiles

Un fichier PAC choisit un itinéraire, mais les caractéristiques de cet itinéraire dépendent du proxy qui le termine. Trois termes sont d'abord importants. La rotation d'IP modifie l'adresse de sortie au fil du temps ou à la demande. Les sessions persistantes conservent une adresse pendant une période définie afin qu'une connexion ou un parcours de paiement reste cohérent. Un ASN, ou numéro de système autonome, identifie l'opérateur réseau qui annonce un bloc d'adresses, et le ciblage géographique permet de sélectionner un pays ou une région.

Les adresses de centres de données sont généralement les plus faciles à reconnaître comme du trafic non résidentiel pour un site de destination, car leur ASN appartient à un réseau d'hébergement. Les adresses résidentielles ressemblent davantage à des connexions domestiques ordinaires. Les adresses mobiles proviennent des réseaux d'opérateurs, et c'est là que le partage d'adresses change le calcul du blocage.

Pourquoi le NAT de qualité opérateur est important

Le NAT de qualité opérateur, ou CGNAT, permet à un opérateur de faire transiter les appareils de nombreux abonnés par un ensemble plus restreint d'adresses IPv4 publiques. La RFC 6598 réserve le bloc 100.64.0.0/10, qui contient 1 048 576 adresses, à l'espace d'adressage partagé utilisé par les équipements CGN des fournisseurs de services. Ce bloc n'est pas routable à l'échelle mondiale, comme le définit la RFC 6598 sur l'espace d'adressage partagé.

Comme de vrais clients peuvent partager une même IP mobile publique, un site qui bloque agressivement cette adresse risque d'affecter de nombreuses personnes sans lien entre elles. C'est pourquoi les IP mobiles sont plus difficiles à associer à un seul acteur et plus risquées à bloquer purement et simplement. C'est aussi pour cette raison qu'une IP constitue un indicateur d'identité imparfait.

Pour concevoir vos sessions, lisez comment la persistance de session maintient la stabilité d'une adresse proxy et déterminez dans quels cas la cohérence est utile. Utilisez un comportement persistant pour la gestion légitime de comptes, la QA en plusieurs étapes et les parcours publicitaires qui échouent si l'adresse de sortie change en cours de route. Utilisez la rotation pour les recherches publiques générales sans état. Dans les deux cas, consignez les horodatages, la destination, le statut de la réponse et le contexte de la session, car une sortie partagée par un opérateur ne correspond pas à un utilisateur unique.

Les proxys HTTP gèrent les requêtes Web et les tunnels CONNECT, tandis que SOCKS5 est un protocole proxy plus général qui peut transporter une gamme plus large de trafic TCP. La valeur de retour PAC, la prise en charge par le client et la tâche doivent toutes être compatibles avec ce choix.

Tester la couverture et la sécurité avant la mise en production

Un résultat positif sur une page de vérification d'IP est le test le moins probant que vous puissiez effectuer. Il prouve qu'à un instant donné, une requête du navigateur a utilisé la sortie attendue. Il ne dit rien des redirections, des téléversements, des appels en arrière-plan ni de la fiabilité du proxy sélectionné demain.

Un PAC est un mécanisme de routage du navigateur ou du système d'exploitation. Les applications mobiles personnalisées et les clients HTTP peuvent ne pas exécuter automatiquement la logique PAC. Un test dans le navigateur peut utiliser le proxy prévu, tandis qu'une WebView intégrée, un SDK, une requête en arrière-plan ou un client API passe directement. Pour une QA dépendante de la géolocalisation, cet angle mort peut invalider tout le résultat.

Organisez vos vérifications autour de processus réels, en vous appuyant sur une configuration structurée d'environnement de test de proxy plutôt que sur des vérifications ponctuelles improvisées :

• Résolution DNS : Vérifiez que les recherches ne révèlent pas une localisation indésirable et qu'elles ne sont pas en échec lorsque le chemin du proxy est actif.
• Redirections et HTTPS : Suivez toute la chaîne et vérifiez que CONNECT fonctionne pour chaque hôte de destination.
• WebSockets et téléversements : Testez les connexions de longue durée et l'envoi de fichiers, pas seulement l'affichage de pages.
• Appels en arrière-plan : Déclenchez les requêtes d'analytique, d'API et de SDK, puis vérifiez par où elles sortent.
• Comportement de repli : Désactivez le premier proxy dans une copie de test du script et vérifiez que les clients utilisent la solution de secours prévue ou échouent clairement.

Pourquoi examiner la provenance des proxys

L'automatisation ne rend pas un point de terminaison sûr. Dans une étude portant sur plus de 107 000 proxys ouverts répertoriés publiquement, environ 92 % étaient indisponibles ou n'autorisaient pas le trafic proxy, selon des mesures à grande échelle de proxys ouverts répertoriés publiquement. Les mêmes résultats vérifiés indiquent que cinq pays représentaient près de 60 % des proxys ouverts fonctionnels et que 41 % étaient hébergés par seulement 10 systèmes autonomes.

Une analyse distincte de neuf mois présentée dans ces résultats a recensé plus de 436 000 proxys et 104 000 exemples réactifs. Parmi les proxys réactifs, 7,17 % modifiaient le contenu des pages Web, et 76,42 % de ces proxys modificateurs effectuaient des actions malveillantes. Inutile de mémoriser ces chiffres. Mais leur leçon, elle, est importante.

Ne faites pas transiter les recherches en production, la protection de marque ou les activités liées aux comptes par des points de terminaison sélectionnés automatiquement que vous n'avez pas vérifiés et dont vous n'avez pas contrôlé l'accès.

Avant toute utilisation en production, effectuez des vérifications continues de disponibilité, conservez une logique de secours dans le fichier PAC, surveillez l’intégrité du contenu sur des pages de test connues et exigez une authentification lorsque votre configuration le permet. Consignez quel proxy a traité une tâche, à quel moment et quel statut a été renvoyé. Lorsque les résultats semblent incorrects, ces enregistrements vous permettent de distinguer une erreur de routage d’un problème lié à un point de terminaison.

Choisir la configuration adaptée à votre équipe

Choisissez en fonction de votre flux de travail, et non par habitude. Une connexion directe convient aux systèmes internes et aux vérifications publiques pour lesquelles votre emplacement réel est précisément l’objet du test. Un proxy configuré manuellement convient à une personne qui effectue une tâche courte et stable, mais cette solution devient fragile lorsque dix personnes doivent appliquer les mêmes règles et que celles-ci changent chaque semaine.

Une configuration basée sur PAC justifie sa complexité lorsque le routage varie selon la destination. Par exemple, les outils internes peuvent se connecter directement, la surveillance publique des prix peut passer par une sortie résidentielle sur le marché cible et un proxy de secours peut prendre le relais en cas de panne. Une mise à jour du script suffit à modifier la politique, sans devoir intervenir sur chaque poste de travail.

Les sources mobiles 4G sont pertinentes lorsque l’expérience de destination dépend des réseaux des opérateurs. Les spécialistes de la vérification publicitaire peuvent avoir besoin de voir une campagne comme la voit un abonné mobile. Les équipes d’assurance qualité peuvent avoir besoin d’une sortie via un opérateur français pour un parcours d’inscription localisé. Les gestionnaires de réseaux sociaux qui s’occupent légitimement de comptes clients peuvent avoir besoin de sessions persistantes, cohérentes avec l’emplacement et qui ne changent pas de réseau en cours de tâche. Les équipes de protection des marques et de surveillance SEO peuvent avoir besoin du même ciblage géographique sans rattacher chaque vérification à la connexion d’un seul bureau.

Évaluez ces critères avant de vous engager :

• Couverture requise : Navigateur uniquement, appareil entier ou application dotée de son propre client HTTP.
• Comportement des sessions : Rotation pour les recherches sans état, sessions persistantes pour les flux de travail légitimes en plusieurs étapes.
• Identité réseau : Vitesse d’un centre de données, contexte résidentiel ou sortie via un opérateur au moyen d’IP mobiles.
• Contrôle opérationnel : Accès authentifié, vérifications de disponibilité, règles de secours et journaux exploitables.
• Cadre de conformité : Règles des plateformes, législation applicable, autorisation du client et objectif commercial documenté.

Dans ce cadre, Evoproxy est un fournisseur de proxy mobile basé dans le sud de la France, qui donne accès à plus de 1,500,000 adresses IP mobiles. Ses offres personnelles fonctionnent sur du matériel mobile dédié, avec 250 GB de trafic mensuel et une rotation d’une à cinq minutes, tandis que les ports partagés offrent 50 GB avec une rotation programmée pour les tests courts.

Ne choisissez pas uniquement en fonction de la taille du pool. Faites passer un flux de travail réel par la configuration, appliquez les vérifications de couverture et de sécurité ci-dessus, puis vérifiez que chaque composant a suivi la route prévue. Gardez les règles PAC lisibles, documentez les sessions et respectez toujours les règles des plateformes et la législation applicable. C’est ainsi qu’une URL de proxy automatique devient une politique de routage fiable au lieu d’une chaîne mystérieuse qu’une personne a collée dans les paramètres il y a des mois.

Si votre prochain test nécessite une véritable sortie via un opérateur plutôt qu’une approximation limitée au navigateur, essayez la configuration mobile 4G d’Evoproxy dans le cadre d’un véritable flux de travail de vérification publicitaire, d’assurance qualité ou d’étude de marché. Configurez le comportement de session dont vous avez besoin, vérifiez la couverture au-delà de la simple vérification de l’IP visible et ne passez à l’échelle supérieure que lorsque vos propres journaux confirment que le routage fonctionne de bout en bout.