curl Cannot Read Your PAC File: Pass the Proxy Instead
PAC is a JavaScript policy; curl wants an endpoint. Ask which proxy the policy picks for your URL, pass that, and watch NO_PROXY and TLS.
The PAC file address and the proxy endpoint look interchangeable in a config file, and they are not. One is a policy program that has to be evaluated for each URL; the other is a host and port that accepts connections. curl only understands the second. Passing a PAC URL to --proxy is a category error that fails in a confusing way, usually after a long CONNECT timeout to a web server.
What each one actually is
| You have | What it is | What curl does with it |
|---|---|---|
http://wpad.corp.example/proxy.pac | JavaScript that returns a proxy or direct for a given URL | Retrieves it as a file and stops there |
http://proxy.corp.example:8080 | A listener that accepts proxied requests | Uses it, including CONNECT for HTTPS targets |
The curl FAQ states it plainly: curl does not provide JavaScript or PAC interpretation. A PAC-aware wrapper around curl might, but curl itself does not, and no flag turns it into a browser.
Why the browser works and curl does not
A browser integrates with the system proxy configuration, fetches the PAC file and runs its rules against the URL you are opening. That evaluation is the service the PAC file provides, and it happens inside the browser, not inside your terminal.
Downloading the PAC file with curl retrieves its text. It does not make curl execute the policy, and reading it by hand to find a proxy is a manual version of the same evaluation, with the same chance of picking the wrong branch. If you do read it, read the return statement that matches your host rather than the first proxy name in the file. Most PAC files contain several, and only one branch applies to you.
For an approved HTTP proxy and an approved HTTPS service, an illustrative request is:
curl --proxy http://proxy.corp.example:8080 https://service.example.net/statusThe first address is the proxy listener, the second is the service you want. These are example endpoints rather than a test anyone performed, so substitute your organization's scheme, port and authentication workflow.
Pick the proxy for this destination
Ask the administrator which proxy the policy selects for the URL you need, not which proxy the organization owns. PAC rules can return different results for internal services, public sites and failover conditions, and a rule that matches your URL today may match a different one after an edit.
If the workflow needs more than one known request, use an administrator-supported static setting or an approved PAC-aware integration. Hard-coding one copied address works until the day the policy changes and nobody remembers why that address was chosen.
Then look at what curl inherits. Proxy environment variables and NO_PROXY can override or exclude the proxy you passed, and an exclusion matching your target silently sends the request direct. Preserve the intended policy rather than deleting every exclusion or forcing everything through one address. Run the request once with -v and check which address it actually connected to.
Keep the two TLS identities straight
With an HTTPS proxy, there are two TLS connections in play: yours to the proxy and the proxy's to the destination. Each has its own identity to verify, and disabling verification for either one is not a PAC fix, it is a second problem added to the first.
Keep verification enabled and read the failure you get. A proxy authentication challenge, an unreachable proxy and a refusal from the website are three different results, and only the first is about credentials. The VPN still has to provide a permitted path to a private proxy, including name resolution for the proxy host itself, before any of this can succeed.
Write down the endpoint, scheme, port, authentication method, exclusions and the VPN path to the proxy. That record is what makes the next request reproducible, and it is the difference between knowing your proxy and guessing at it.