An HTTP 407 Proxy Authentication Required error means a proxy server sitting between you and the website is refusing to forward your request until you prove who you are. The key word is proxy: unlike a 401, which comes from the destination website, a 407 comes from the proxy itself. If you are using proxies for scraping, automation, or privacy and you see a 407, the fix is almost always in how your client is sending (or not sending) its proxy credentials.
This guide explains exactly what a 407 is, how it differs from a 401, the eight real-world causes, and copy-paste fixes for curl, Python, Node.js, Scrapy, and your browser.
HTTP 407, defined in RFC 9110, is sent by a proxy when the client must authenticate with that proxy before the request can continue. The response includes a Proxy-Authenticate header that tells the client which authentication scheme to use (usually Basic). The client is then expected to retry the request with a Proxy-Authorization header carrying the credentials.
In other words, the chain is: your client to the proxy to the destination. A 407 stops the request at the very first hop. The destination website never even sees your request, so the problem is never the website — it is the handshake between your client and the proxy.
These two codes look similar but point at completely different machines:
| 401 Unauthorized | 407 Proxy Authentication Required | |
|---|---|---|
| Who sends it | The destination server | The proxy in front of you |
| Challenge header | WWW-Authenticate | Proxy-Authenticate |
| Credentials header | Authorization | Proxy-Authorization |
| What it means | Log in to the website | Log in to the proxy |
| Typical fix | API key or session token | Proxy username and password (or IP whitelist) |
If you see a 401, fix your website credentials. If you see a 407, fix your proxy credentials. A common mistake is putting site credentials in the Authorization header and proxy credentials in the same place — they are separate headers for a reason.
Most commercial proxies, including SpyderProxy, support two ways to authenticate:
username:password and sends it in the Proxy-Authorization header. Most HTTP libraries do this automatically when you put the credentials in the proxy URL.Knowing which method your account uses is the first diagnostic step. If you are on IP whitelisting and your server changed IPs (or you moved to a new box), that alone produces a 407.
You pointed your client at the proxy host and port but never supplied a username and password. The proxy challenges you with 407 and your client has nothing to answer with.
A typo, a trailing space, or stale credentials after a password rotation. Re-copy the exact values from your provider dashboard.
If your password contains characters like @, :, #, or / and you put it inside a proxy URL, the URL parser mis-splits it. The @ in a password breaks user:p@ss@host:port because the parser treats the first @ as the host separator. You must URL-encode the password.
On IP-authentication plans, the proxy only accepts requests from registered IPs. New server, new home IP, or a dynamic IP that changed overnight all trigger 407. Add the current public IP to your whitelist.
Providers expose different ports for rotating vs sticky sessions, HTTP vs SOCKS5, or per region. Using the wrong port can route you to an endpoint your credentials are not valid on, returning 407.
If you have several plans (residential, datacenter, mobile), each may have its own sub-user or credential set. Using residential credentials against the datacenter endpoint fails auth.
Rare, but some corporate proxies require Digest or NTLM rather than Basic. If the Proxy-Authenticate header asks for a scheme your client does not implement, you cannot authenticate until you match it.
On managed laptops and office networks, an OS-level or corporate proxy may intercept traffic and demand its own credentials. The 407 then comes from that device, not the proxy you intended to use.
Put the credentials directly in the proxy flag, or use the dedicated proxy-user flag:
curl -x http://USERNAME:[email protected]:12321 https://httpbin.org/ip
# or, keeping credentials out of the URL
curl -x http://geo.spyderproxy.com:12321 -U USERNAME:PASSWORD https://httpbin.org/ipIf this returns your proxy IP instead of a 407, authentication is working.
import requests
proxy = "http://USERNAME:[email protected]:12321"
proxies = {"http": proxy, "https": proxy}
r = requests.get("https://httpbin.org/ip", proxies=proxies, timeout=20)
print(r.status_code, r.text)If your password has special characters, encode it first so the URL parser does not choke:
from urllib.parse import quote
user = "myuser"
pwd = quote("p@ss:w0rd/!") # encodes @ : / ! safely
proxy = "http://" + user + ":" + pwd + "@geo.spyderproxy.com:12321"const axios = require("axios");
const { HttpsProxyAgent } = require("https-proxy-agent");
const agent = new HttpsProxyAgent(
"http://USERNAME:[email protected]:12321"
);
axios.get("https://httpbin.org/ip", { httpsAgent: agent, proxy: false })
.then((res) => console.log(res.data))
.catch((err) => console.log(err.response && err.response.status));Set the proxy in the request meta and add the Basic auth header explicitly, since Scrapy does not always parse credentials from the proxy URL:
import base64
user_pass = base64.b64encode(b"USERNAME:PASSWORD").decode()
request.meta["proxy"] = "http://geo.spyderproxy.com:12321"
request.headers["Proxy-Authorization"] = "Basic " + user_passWhen you set a proxy in Chrome, Firefox, Windows, or macOS, the system pops up a username and password dialog the first time the proxy challenges with 407. Enter the proxy credentials there. If the dialog never appears or keeps rejecting, the credentials or the whitelist are the issue.
SpyderProxy supports both username/password and IP whitelisting on every plan. You will find your exact credentials and endpoints in the dashboard after signup. A few tips that prevent 407s:
SpyderProxy residential plans start at $1.75/GB (Budget) and $2.75/GB (Premium), static residential ISP at $3.90/day, static datacenter at $1.50/proxy/month, and LTE mobile at $2/IP.
It means a proxy server between you and the website needs you to authenticate before it forwards your request. The proxy sends a Proxy-Authenticate header, and your client must reply with a Proxy-Authorization header containing valid proxy credentials. The destination website is never reached until that succeeds.
A 401 comes from the destination server and means you must log in to the website (Authorization header). A 407 comes from the proxy and means you must log in to the proxy (Proxy-Authorization header). They use different headers and different credentials.
The most common reasons are a special character in the password that was not URL-encoded, using the wrong port or product endpoint, or being on an IP-whitelist plan from a server whose IP is not whitelisted. URL-encode the password, confirm the endpoint, and check your IP whitelist.
Pass credentials with the proxy: curl -x http://USER:PASS@host:port https://httpbin.org/ip, or use the -U USER:PASS flag. If it returns the proxy IP instead of 407, it works.
Put the credentials in the proxy URL and pass it via the proxies argument. If the password has characters like @ or :, wrap it with urllib.parse.quote first so the URL parses correctly.
Yes. On IP-authentication plans the proxy only accepts whitelisted IPs and ignores passwords. If your machine's public IP is not on the list — for example after moving servers or because of a dynamic IP — you get a 407. Add the current IP to your whitelist.
No. A 407 is an authentication problem, not a block. The proxy is working fine; it just has not accepted your credentials yet. A block would more likely show as a 403 from the destination once you are past the proxy.
HTTP 407 is one of the easiest proxy errors to fix once you know where to look: it is always about the credentials your client sends to the proxy, never about the website. Confirm whether you are using password or IP authentication, URL-encode any special characters, point at the right endpoint and port, and test against httpbin.org/ip. With clean credentials and the correct endpoint, the 407 disappears on the first retry.
If you want proxies with both password and IP authentication, clear per-product endpoints, and credentials you can manage from a dashboard, start with a SpyderProxy residential plan from $1.75/GB.