PAC URL asks for a login
high
The PAC URL answers with a login challenge (401 or 407, Basic, NTLM, Negotiate). Chrome, Edge and Windows do not log in to fetch a PAC file, so they run without one.
Why it matters
The PAC file is fetched before the client knows which proxy to use, often before the user has signed in, and by system services that have no user to ask. Clients therefore fetch it without credentials. Chromium cancels the download as soon as the server asks for a login. In the lab, Windows (WinHTTP) failed on both a Basic and an NTLM login request (error 12015). Firefox shows a login dialog for the PAC URL, which users do not expect and often cannot answer.
This usually happens when the PAC file sits behind a single sign-on web server, a reverse proxy that protects everything, or a proxy that requires a login and also serves the PAC file. A PAC file contains no secrets that a login would protect: it only lists proxies and host names. Serve it anonymously.
How to fix
Exempt the PAC URL (and wpad.dat) from authentication on the web server or proxy that serves it.
Examples
Bad
HTTP/1.1 401 Unauthorized
WWW-Authenticate: NTLM
WWW-Authenticate: Negotiate
Good
HTTP/1.1 200 OK
Content-Type: application/x-ns-proxy-autoconfig
Cache-Control: max-age=3600
Engine behaviour
| Engine | Behaviour | Source |
|---|---|---|
| chromium | When the server asks for a login, the PAC download is cancelled; no PAC is used. | code, verified 2026-10-13 · ref |
| firefox | The PAC download can show the normal login dialog; without an answer the PAC is not loaded. | code, verified 2026-10-13 · ref |
| winhttp | A 401 answer with a Basic or an NTLM login request failed (error 12015); no PAC was used. | lab, verified 2026-10-11 |
Related rules
- PAC URL does not return 200 PAC-D010
- PAC served over plain HTTP PAC-D001