WPAD išsprendžiamas, bet naršyklė gauna 404
Automatinis proxy aptikimas gali rasti tinkamą serverį ir vis tiek paprašyti PAC failo iš netinkamo virtualiojo prieglobos ar kelio.
Pavadinimas wpad išsprendžiamas į laukiamą mašiną. Tai džiugina, bet tai tik pradžia. Naršyklė vis tiek turi paprašyti failo iš tos mašinos ir gauti PAC scenarijų.
Naudingą užuominą galima rasti žiniatinklio serverio prieigos žurnale: klientas paprašė /wpad.dat ir gavo HTTP 404. Rankiniu būdu atidarytas PAC URL gali naudoti kitą prieglobos vardą. Net kai abu vardai pasiekia tą patį serverį, jie gali pasirinkti skirtingus virtualiuosius prieglobus.
Sekite užklausą, kurią atliko klientas
Patikrinkite tikslų aptikimo pasirinktą URL, HTTP Host reikšmę, kelią ir atsakymą. Patogaus PAC URL atidarymas įprastoje naršyklės kortelėje neįrodo, kad automatinis aptikimas paprašė būtent šio URL.
Jei tikimasi ir trumpų, ir visiškai kvalifikuotų vardų, sukonfigūruokite numatytą žiniatinklio prieglobą sąmoningai apdoroti tuos vardus. Patvirtinkite, kad /wpad.dat rodo į tinkamą failą, o ne į numatytąją dokumentų šaknį ar nesusijusią programą.
Pateikite scenarijų, o ne klaidos puslapį
Patikrinkite atsakymo turinį ir jo būseną. Prisijungimo puslapis, prekės ženklu pažymėtas klaidos dokumentas ar peradresavimas rankiniu būdu gali atrodyti įtikinamai, bet tai nėra PAC scenarijus, kurio tikisi sprendiklis. Chromium dokumentuoja griežtus PAC atsisiuntimo reikalavimai, įskaitant HTTP 200 atsakymą.
Tik po to, kai pristatymas pavyksta, prasminga derinti FindProxyForURL(). Jo prieglobos vardų taisyklių keitimas negali ištaisyti 404, dėl kurio naršyklė negavo scenarijaus.
Taip pat atskirkite PAC žiniatinklio serverį nuo jo scenarijuje nurodyto tiesioginio proxy. Jie gali dalytis mašina, tačiau vienos tarnybos prieigos žurnalo įrašas nėra įrodymas, kad kita tarnyba apdorojo naudotojo paskirties užklausą.