407 Proxy Authentication Error: Causes and How to Fix It

Short answer: A 407 Proxy Authentication Required error means the proxy server didn't accept the credentials your request sent — either because they're missing, incorrect, malformed, or because your account is set up for IP whitelisting and the request came from an unregistered IP. Unlike a 401 (which comes from the target website), a 407 always comes from the proxy itself, before your request ever reaches its destination. This is exactly what SimplyNode's own gateway returns on failed authentication — a standard 407 with a Proxy-Authenticate header, no custom error body.

What does 407 actually mean?

HTTP status code 407 is defined specifically for proxy authentication — it's the proxy equivalent of a 401 Unauthorized. When your client sends a request through a proxy, the proxy checks the Proxy-Authorization header (or the source IP, if you're using whitelisting) before forwarding anything. If that check fails, the proxy returns 407 immediately — the target website never sees the request at all.

That distinction matters for debugging: if you're getting a 407, the problem is 100% in how your proxy connection is configured, not in anything related to the site you're trying to reach.

Cause 1: No credentials sent at all

The most basic cause — the proxy URL doesn't include a username or password, but the account requires them.

python

import requests

# This will return 407 if the account requires username:password auth
proxies = {
    "http": "http://ip.simplynode.io:10000",
    "https": "http://ip.simplynode.io:10000",
}

response = requests.get("https://ifconfig.me", proxies=proxies, timeout=10)

Fix: add credentials to the connection string.

python

proxies = {
    "http": "http://username:password@ip.simplynode.io:10000",
    "https": "http://username:password@ip.simplynode.io:10000",
}

Cause 2: Wrong username or password

A typo, an expired password, or credentials copied from the wrong project will all produce a 407 — the proxy has no way to distinguish "wrong password" from "no password" in the response, both return the same status code.

Fix: copy credentials directly from your dashboard rather than retyping them, and double-check you're not mixing credentials from a different account or sub-user.

Cause 3: Unescaped special characters in the password

This is the cause that's hardest to spot, because it doesn't always produce a 407 — sometimes it breaks the request before the proxy is even contacted. Characters like #, @, :, and / have structural meaning in a URL. If your password contains one of them and you paste it directly into the connection string, the URL parser can misread where the password ends and the host begins.

python

import requests

# Password contains an unescaped "#" — this raises InvalidURL,
# the request never even reaches the proxy
proxies = {
    "http": "http://username:test#pass@ip.simplynode.io:10000",
}
response = requests.get("https://ifconfig.me", proxies=proxies, timeout=10)
# requests.exceptions.InvalidURL: Failed to parse: http://username:test#pass@ip.simplynode.io:10000

Fix: percent-encode the username and password with urllib.parse.quote before building the connection string.

python

import requests
from urllib.parse import quote

username = "username"
password = "test#pass"

encoded_user = quote(username, safe="")
encoded_pass = quote(password, safe="")

proxies = {
    "http": f"http://{encoded_user}:{encoded_pass}@ip.simplynode.io:10000",
    "https": f"http://{encoded_user}:{encoded_pass}@ip.simplynode.io:10000",
}

response = requests.get("https://ifconfig.me", proxies=proxies, timeout=10)
print(response.status_code)  # 200

Cause 4: IP whitelist mismatch

If your account is set up for IP whitelisting instead of username:password, a 407 usually means the request is coming from an IP that isn't on the registered list — most often because your server's IP changed, or you're testing from a different network (home instead of office, a new VPS, a CI/CD runner with a dynamic IP).

Fix: check your current outbound IP and confirm it matches what's registered in your dashboard. If you're running from an environment where the IP isn't fixed (a laptop, most CI/CD runners), switch to username:password authentication instead — it isn't tied to network origin.

Cause 5: Mixing authentication methods incorrectly

Some setups accidentally combine both methods — for example, sending credentials in the URL on an account that's configured for IP whitelisting only, or whitelisting an IP that then also has stale credentials embedded in old scripts. If you're not sure which method your requests are actually using, that ambiguity is itself worth resolving before debugging further.

Fix: confirm in your dashboard which authentication method is active for the credentials or IP in question, and make sure your code only follows that one method consistently.

Summary table

FAQ

Is a 407 error caused by my code, the proxy provider, or the target website? It's always the proxy layer. A 407 is returned by the proxy server itself before your request reaches the target website, so the website's availability or configuration has no bearing on it.

Does a 407 mean my account is out of bandwidth or blocked? No. Running out of bandwidth or being suspended typically produces a different error (often 403 or a provider-specific message), not 407. A 407 specifically indicates an authentication problem, not an account-status problem.

Why does my password work in a browser but not in my script? Browsers and proxy-aware apps often handle special characters and encoding automatically when you enter credentials in a dialog box. Scripts that build a raw connection string don't — which is why unescaped special characters are a common cause of 407s in code that otherwise works fine when tested manually.

Can I avoid this entirely by using IP whitelisting instead? It avoids credential-related 407s, but only if your outbound IP is genuinely static. If it isn't, whitelisting introduces its own version of the same error whenever the IP changes.

What does a 407 response actually look like from SimplyNode's gateway? A plain HTTP 407 status line with a Proxy-Authenticate header and no JSON body — for example, running curl -v against the gateway with wrong credentials returns:

< HTTP/1.1 407 Proxy Authentication Required
< Proxy-Authenticate: Basic realm="..."
< Proxy-Connection: close
* CONNECT tunnel failed, response 407

The connection closes immediately (Connection: close), so your code should open a fresh connection on retry rather than reusing the old one.

Does the 407 error look different between HTTP, HTTPS, and SOCKS5 proxies? The status code itself is an HTTP-layer concept, so it applies directly to HTTP and HTTPS proxy connections. SOCKS5 uses a different authentication negotiation and will typically surface a connection or authentication failure at the socket level rather than an HTTP 407 — the underlying causes (wrong or missing credentials) are the same either way.