Proxy Error 407: Why Your Authenticated Request Is Being Rejected

HTTP 407 Proxy Authentication Required is the proxy talking, not the target site. Your request never left the gateway. That is good news — it narrows the search enormously — but the error text is identical across six unrelated causes, which is why it wastes so much time.

Work through these in order. The first two account for most reports.

1. The credentials never reached the proxy

The commonest cause is a client that parses the URL but drops the userinfo. Confirm with curl, which handles it correctly and gives you a known-good baseline:

curl -v -x http://user-country-us:[email protected]:8080 \
  https://api.fleetproxy.com/v1/ip

If curl succeeds and your code does not, the bug is in your code, not the account. The usual suspects:

• Node's built-in fetch ignores HTTP_PROXY entirely and has no proxy option. You need a dispatcher.
• Requests sessions honour session.proxies, but an explicit proxies= argument on a call overrides it, and a trust_env=False client silently ignores environment variables.
• Some HTTP/2 clients send Proxy-Authorization only after a challenge, and drop it on redirect.

For Node, use undici's ProxyAgent:

import { ProxyAgent, request } from "undici";

const agent = new ProxyAgent({
  uri: "http://gate.fleetproxy.com:8080",
  token: "Basic " + Buffer.from("user-country-us:pass").toString("base64"),
});

const { statusCode, body } = await request("https://api.fleetproxy.com/v1/ip", {
  dispatcher: agent,
});

console.error(statusCode, await body.text());

2. A special character in the password broke the URL

If a password contains @, :, /, # or ?, embedding it raw in a proxy URL produces a string that parses into the wrong fields. A password of p@ss:1 turns the host into ss:1 and the error you get is 407, not a parse failure.

Percent-encode it, or keep credentials out of the URL entirely:

from urllib.parse import quote

user = quote("user-country-us", safe="")
password = quote("p@ss:1", safe="")
proxy = f"http://{user}:{password}@gate.fleetproxy.com:8080"

Rotating the password to an alphanumeric string is the more durable fix. Every layer between your config file and the socket is a place where encoding can be lost.

3. The targeting segment does not resolve

FleetProxy encodes targeting in the username: user-country-us, user-country-gb-city-manchester, user-country-us-asn-7922. If a segment names a pool that does not exist — a misspelled country, a city with no inventory, an ASN that has no presence in the requested country — the gateway rejects the credential rather than quietly serving a different location.

That rejection is a 407 with a reason header:

curl -sI -x http://user-country-us-city-atlantis:[email protected]:8080 \
  https://api.fleetproxy.com/v1/ip | grep -i x-fleet-reason
# x-fleet-reason: no-matching-pool

Countries are ISO 3166-1 alpha-2, lowercase. Cities are lowercase with hyphens for spaces: new-york, sao-paulo. The locations page lists what is live.

4. IP whitelisting is on and your address changed

If the credential has an IP whitelist attached, password authentication is still required and the source address must be on the list. A dynamic office IP, a new CI runner, or a container that egresses through a different NAT will all produce 407.

Check the whitelist on the credential in the dashboard, and remember that whitelists are per-credential, not per-account. Adding your address to one credential does not add it to the others.

5. The plan is out of bandwidth or has expired

An exhausted or expired plan stops authenticating. The reason header distinguishes it:

Bandwidth on FleetProxy plans does not expire, but a plan can still be suspended for a failed payment, and a suspended plan authenticates exactly like a wrong password unless you read the header.

6. You are authenticating to the wrong port

Port 8080 is HTTP and HTTPS via CONNECT. Port 1080 is SOCKS5. SOCKS5 authentication is a different handshake, and pointing an HTTP client at 1080 produces a confusing failure that some libraries surface as 407. Match the scheme to the port:

# HTTP/HTTPS
curl -x http://user-country-us:[email protected]:8080 https://example.com

# SOCKS5, with remote DNS resolution
curl -x socks5h://user-country-us:[email protected]:1080 https://example.com

Use socks5h, not socks5. The h resolves DNS at the proxy; without it your resolver leaks the hostname locally and, on geo-targeted work, resolves to the wrong CDN edge.

A checklist you can run in a minute

1. Reproduce with curl. If curl works, the fault is client-side.
2. Percent-encode credentials, or rotate to an alphanumeric password.
3. Read x-fleet-reason on the failing response.
4. Confirm the targeting segment against the live locations list.
5. Check the credential's IP whitelist against your actual egress address.
6. Confirm plan status and remaining bandwidth in the dashboard.

If all six pass and you are still seeing 407, send support the failing username (never the password) and the timestamp with a timezone. Gateway auth decisions are logged and can be looked up directly.