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.

Kapcsolódó cikkek