PAC URL does not return 200
high
A 3xx, 4xx or 5xx on the PAC URL means clients have no script to run. Browsers then connect directly (or, with a mandatory-PAC policy, fail every request). Redirects add a hop that some consumers do not follow.
Why it matters
A missing or inaccessible PAC is indistinguishable from “no proxy configured” for most clients: they go DIRECT and keep retrying on an engine-specific back-off. An authentication challenge (401/407) on the PAC URL is a classic misconfiguration: the browser has no credentials at that stage. Redirects (301/302) are followed by browsers but are an unnecessary dependency and are reported not to be followed by all consumers. The PAC URL should answer 200 directly, anonymously, over https.
How to fix
Make the PAC URL answer 200 without authentication and without redirects; monitor it like any other critical endpoint.
Examples
Bad
HTTP/1.1 302 Found
Location: https://sso.corp.example/login?next=/proxy.pac
Good
HTTP/1.1 200 OK
Content-Type: application/x-ns-proxy-autoconfig
Cache-Control: max-age=3600
Engine behaviour
| Engine | Behaviour | Source |
|---|---|---|
| chromium | Fetch failure falls back to DIRECT unless ProxyPacMandatory is set; the fetch is retried with back-off. | doc, unverified |