WPAD los op, maar die blaaier kry 'n 404
Outomatiese proxy-ontdekking kan die regte bediener vind en steeds 'n PAC-lêer by die verkeerde virtuele gasheer of pad aanvra.
Die naam wpad los op na die verwagte masjien. Dit is bemoedigend, maar dit is net die begin. Die blaaier moet steeds 'n lêer by daardie masjien aanvra en die PAC-script ontvang.
'n Nuttige leidraad is in die webbediener se toegangslog te vind: die kliënt het /wpad.dat aangevra en HTTP 404 ontvang. 'n PAC-URL wat met die hand oopgemaak word, kan 'n ander gasheernaam gebruik. Selfs wanneer albei name dieselfde bediener bereik, kan hulle verskillende virtuele gashere kies.
Volg die versoek wat die kliënt gemaak het
Kontroleer die presiese URL wat deur ontdekking gekies is, die HTTP Host-waarde, die pad en die antwoord. Om 'n gerieflike PAC-URL in 'n gewone blaaier-oortjie oop te maak, bewys nie dat outomatiese ontdekking daardie URL aangevra het nie.
As beide kort en volledig gekwalifiseerde name verwag word, stel die beoogde webgasheer in om daardie name doelbewus te hanteer. Bevestig dat /wpad.dat na die korrekte lêer verwys, en nie na 'n verstek-dokumentwortel of 'n onverwante toepassing nie.
Diens 'n script, nie 'n foutbladsy nie
Kontroleer die antwoordliggaam sowel as die status. 'n Aanmeldbladsy, handelsmerk-foutdokument of herleiding kan geloofwaardig lyk wanneer dit met die hand bekyk word, maar is nie die PAC-script wat die oplosser verwag nie. Chromium dokumenteer streng PAC-aflaai-vereistes, insluitend 'n HTTP 200-antwoord.
Eers nadat lewering slaag, maak dit sin om FindProxyForURL() te debug. Om sy gasheernaamreëls te verander, kan nie 'n 404 herstel wat verhoed het dat die blaaier dit verkry nie.
Onderskei ook 'n PAC-webbediener van die voorwaartse proxy wat in sy script genoem word. Hulle kan 'n masjien deel, maar 'n toegangslog-inskrywing by een diens is nie bewys dat die ander diens die gebruiker se bestemmingsversoek hanteer het nie.