When wrangler dies behind a corporate proxy, use the API

The symptom

On a locked-down Windows machine behind a corporate proxy, wrangler was unusable. wrangler login never completed, deploys threw TLS or self-signed-certificate errors, and other vendor CLIs failed the same way. The Cloudflare dashboard worked fine in the browser, so it clearly wasn’t an outage or a credentials problem.

What’s actually happening

The corporate proxy does TLS interception: it sits in the middle, terminates the real HTTPS connection, and re-encrypts traffic to you with its own certificate signed by an internal CA. The browser trusts that CA because IT installed it in the system store. Many CLIs don’t use the system store, or they pin certificates, so they see an unknown issuer and refuse the connection. It’s not a Cloudflare bug. The proxy is breaking the certificate chain that wrangler expects, and wrangler does the correct, strict thing and bails.

The fix

Stop fighting the CLI. Almost every vendor tool is a wrapper over a REST API, and the API is reachable directly. Talk to it with curl and -k (skip cert verification, since you already know who is intercepting you), authenticating with a scoped API token:

# token from your .env, never inline in the command history
export CF_TOKEN="$(grep CLOUDFLARE_TOKEN .env | cut -d= -f2)"

# example: find a zone, then create a DNS record
curl -sk "https://api.cloudflare.com/client/v4/zones?name=example.com" \
  -H "Authorization: Bearer $CF_TOKEN" | jq -r '.result[0].id'

curl -sk -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE/dns_records" \
  -H "Authorization: Bearer $CF_TOKEN" -H "Content-Type: application/json" \
  --data '{"type":"CNAME","name":"www","content":"my-app.pages.dev","proxied":true}'

In Python the same escape hatch is requests.get(url, verify=False). I have driven whole workflows this way: creating DNS records, attaching a custom domain to a Pages project, setting up email routing, all the things wrangler would normally do.

A word on -k: it disables certificate verification, which is a real tradeoff, not a free pass. It is fine on a machine you control where you already know the proxy is the man in the middle. Do not make it a habit on untrusted networks, and keep the token minimally scoped (only the permissions the task needs) so a leaked or logged token can’t do much.

The lesson

When a vendor CLI dies behind a TLS-intercepting proxy, drop a layer. The CLI is convenience; the REST API underneath it is always there, and curl -sk (or verify=False) plus a scoped token gets you through. The same move rescued RDAP lookups and a handful of other tools on the same machine. The proxy can break a CLI’s certificate handling, but it can’t hide the API.