WPAD se résout, mais le navigateur reçoit un 404
La découverte automatique de proxy peut trouver le bon serveur et néanmoins demander un fichier PAC sur un hôte virtuel ou un chemin incorrect.
Le nom wpad se résout vers la machine attendue. C'est encourageant, mais ce n'est que le début. Le navigateur doit encore demander un fichier à cette machine et recevoir le script PAC.
Un indice utile se trouve dans le journal d'accès du serveur web : le client a demandé /wpad.dat et a reçu HTTP 404. Une URL PAC ouverte manuellement peut utiliser un autre nom d'hôte. Même lorsque les deux noms atteignent le même serveur, ils peuvent sélectionner des hôtes virtuels différents.
Suivez la requête émise par le client
Vérifiez l'URL exacte choisie par la découverte, la valeur HTTP Host, le chemin et la réponse. Ouvrir une URL PAC pratique dans un onglet de navigateur ordinaire ne prouve pas que la découverte automatique a demandé cette URL.
Si des noms courts et des noms pleinement qualifiés sont attendus, configurez l'hôte web prévu pour gérer ces noms délibérément. Confirmez que /wpad.dat pointe vers le bon fichier, et non vers une racine de documents par défaut ou une application sans rapport.
Servez un script, pas une page d'erreur
Vérifiez le corps de la réponse ainsi que son statut. Une page de connexion, un document d'erreur de marque ou une redirection peuvent sembler plausibles à l'examen manuel, mais ce n'est pas le script PAC attendu par le résolveur. Chromium documente des exigences de téléchargement du PAC strictes, y compris une réponse HTTP 200.
Ce n'est qu'une fois la livraison réussit qu'il est utile de déboguer FindProxyForURL(). Modifier ses règles de noms d'hôtes ne peut pas réparer un 404 qui a empêché le navigateur de l'obtenir.
Distinguez aussi un serveur web PAC du proxy direct nommé dans son script. Ils peuvent partager une machine, mais une entrée du journal d'accès d'un service ne prouve pas que l'autre service a traité la requête de destination de l'utilisateur.