WPAD lost op, mar de browser krijt in 404
Automatyske proxy-ûntdekking kin de juste tsjinner fine en dochs in PAC-bestân by de ferkearde firtuele host of paad oanfreegje.
De namme wpad lost op nei de ferwachte masine. Dat is oanmoedigjend, mar it is mar it begjin. De browser moat noch in bestân by dy masine oanfreegje en it PAC-skript ûntfange.
In nuttige oanwizing is te finen yn it tagongslog fan de webserver: de klient frege /wpad.dat oan en krige HTTP 404. In mei de hân iepene PAC-URL kin in oare hostnamme brûke. Sels as beide nammen deselde tsjinner berikke, kinne se ferskate firtuele hosts kieze.
Folgje it fersyk dat de klient die
Kontrolearje de krekte URL dy't troch de ûntdekking keazen is, de HTTP Host-wearde, it paad en it antwurd. In handige PAC-URL iepenje yn in gewoan browser-tab bewissiget net dat automatyske ûntdekking dy URL oanfrege hat.
As sawol koarte as folslein kwalifisearre nammen ferwachte wurde, konfigurearje de bedoelde webhost om dy nammen bewust te behanneljen. Befêstigje dat /wpad.dat nei it juste bestân wiist, en net nei in standert dokumintwoartel of in net besibbe applikaasje.
Tsjinje in skript, gjin flispagina
Kontrolearje it lichem fan it antwurd en ek de status. In oanmeldside, in merkbrief fan in flisdokumint of in trochferwizing kin by hânmjittich besjen betrouber lykje, mar it is net it PAC-skript dat de oplosser ferwachtet. Chromium dokumintearret strikte PAC-downloadeasken, ynklusyf in HTTP 200-antwurd.
Pas nei't de levering slagget, hat it sin om FindProxyForURL() te debuggen. It feroarjen fan syn hostnamme-regels kin in 404 net reparearje dy't de browser behindere it te krijen.
Underskiede ek in PAC-webserver fan de forward-proxy dy't yn syn skript neamd wurdt. Se kinne in masine diele, mar in tagongslog-ynskriuwing by ien tsjinst is gjin bewiis dat de oare tsjinst it bestimmingsfersyk fan de brûker behannele hat.