A WPAD feloldódik, de a böngésző 404-et kap
Az automatikus proxyfelderítés megtalálhatja a megfelelő szervert, és mégis rossz virtuális hoszttól vagy útvonalról kérhet PAC-fájlt.
A wpad név a várt géphez oldódik fel. Ez biztató, de csak a kezdet. A böngészőnek továbbra is fájlt kell kérnie attól a géptől, és meg kell kapnia a PAC-szkriptet.
Hasznos nyom a webkiszolgáló hozzáférési naplójában található: a kliens a /wpad.dat fájlt kérte, és HTTP 404-et kapott. A kézzel megnyitott PAC URL más hosztnevet használhat. Még ha mindkét név ugyanarra a kiszolgálóra jut is, különböző virtuális hosztokat választhatnak.
Kövesse a kliens által küldött kérést
Ellenőrizze a felderítés által kiválasztott pontos URL-t, a HTTP Host értékét, az útvonalat és a választ. Egy kényelmes PAC URL megnyitása egy közönséges böngészőlapon nem bizonyítja, hogy az automatikus felderítés azt az URL-t kérte.
Ha rövid és teljesen minősített nevek is várhatók, állítsa be a szándékolt webhosztot, hogy tudatosan kezelje ezeket a neveket. Erősítse meg, hogy a /wpad.dat a megfelelő fájlra mutat, nem egy alapértelmezett dokumentumgyökérre vagy egy kapcsolódó idegen alkalmazásra.
Szkriptet szolgáljon ki, ne hibaoldalt
Ellenőrizze a válasz törzsét és állapotát is. Egy bejelentkezési oldal, egy márkázott hibaoldal vagy egy átirányítás kézzel nézve hihetőnek tűnhet, de nem az a PAC-szkript, amelyet a feloldó vár. A Chromium szigorú PAC-letöltési követelmények ír le, beleértve a HTTP 200-as választ is.
Csak azt követően, hogy a kézbesítés sikerül, van értelme a FindProxyForURL() hibakeresésének. A hosztnév-szabályainak módosítása nem javítja meg azt a 404-et, amely megakadályozta, hogy a böngésző megszerezze.
Különböztesse meg a PAC-webkiszolgálót a szkriptjében megnevezett előremenő proxytól is. Osztott gépen is lehetnek, de az egyik szolgáltatás hozzáférési naplójában szereplő bejegyzés nem bizonyítja, hogy a másik szolgáltatás kezelte a felhasználó célkérését.