Error reference HTTP status

How to fix a 401 Unauthorized error

A 401 Unauthorized comes from the site or API you're calling, not from your proxy — proxy credential failures return 407 instead. Something about your credentials is missing, expired, or malformed, or your session no longer matches the client the server expects. This guide walks through the fixes, including the rotation trap that silently logs scrapers out mid-run.

Try clean residential routes All error codes

401 Unauthorized

What 401 Unauthorized means

HTTP 401 means the target server requires authentication it didn't get: the credential is missing, expired, malformed, or wrong for this resource. The response carries a WWW-Authenticate header naming the scheme it expects (Bearer, Basic, or a custom one). Despite the name 'Unauthorized', it's an authentication failure — who are you — not an authorization failure, which is 403.

The first triage step is separating 401 from its proxy cousin, 407 Proxy Authentication Required. A 401 comes from the site or API you're calling and is about your credentials for that service. A 407 comes from the proxy itself and means your proxy username or password was rejected. Mixing these up sends people down the wrong debugging path for hours.

Typical concrete causes: no Authorization header on the request, an expired or revoked token, Bearer sent where Basic is expected (or vice versa), a sandbox key used against a production host, a session cookie that has lapsed — or, in proxy pipelines specifically, a session the server invalidated because your exit IP changed mid-flow.

401 Unauthorized

How to fix 401 Unauthorized, step by step

Confirm what the server actually said, then walk the credential path from your code to the wire.

Read the response headers first. WWW-Authenticate means the target wants credentials (a real 401); Proxy-Authenticate with a 407 status means the proxy rejected your proxy credentials — a different fix entirely.
Confirm the Authorization header actually leaves your client. Log or capture the outgoing request; a header set on the wrong object (client vs. individual request) silently vanishes.
Check token expiry. Decode the JWT payload and look at exp, or check your provider dashboard for revocation. Expired tokens are the single most common 401.
Verify the scheme and format: Bearer TOKEN vs Basic BASE64 vs a custom header like X-API-Key. One wrong word or a missing space fails authentication.
For Basic auth, check the base64. Special characters in the password must survive encoding; build the header with your library's auth helper rather than by hand.
Watch for redirects that drop credentials. Many HTTP clients strip the Authorization header when a redirect crosses to a different host — request the final URL (correct scheme, host, and trailing slash) directly.
Match key to environment. Test keys against production hosts, or production keys against sandbox hosts, return 401s that look identical to expired-token errors.
For signed requests (HMAC, cloud-style signatures), check clock skew — a system clock a few minutes off invalidates every signature you produce.

401 Unauthorized

The proxy angle: rotation, 407s, and IP-bound sessions

Proxies don't touch your credentials in HTTPS traffic — the tunnel is encrypted end to end, so the proxy can't see or strip an Authorization header even if it wanted to. What a proxy does change is your visible IP, and that matters because some services bind sessions and tokens to the client IP that created them. Log in through one exit IP, make the next call from another, and the server treats the session as hijacked and returns 401.

The fix is IP continuity for the lifetime of the authenticated flow. On ProxyOmega, append -session-<id> to your proxy username and every request with that session ID keeps the same residential exit IP for up to 24 hours — long enough for login, token exchange, and the authenticated crawl that follows. On the proxy-credential side, your proxy password is your dashboard API key, or you can whitelist your server's IP and skip proxy credentials entirely, which eliminates 407s from the picture.

The rotation logout trap

Rotating proxies swap your exit IP on an interval or per session ID. If a login flow spans that swap, IP-bound sessions break with a 401 (or a forced re-login) even though your cookies and tokens are intact.

Run the entire authenticated flow through one sticky session — username-session-abc123 — and rotate only between accounts or jobs, not inside them.

401 vs 407: read the status, not the vibe

Client libraries often surface both as a generic 'authentication failed', so check the actual status code. 407 means fix your proxy credentials: with ProxyOmega, that's your username plus your dashboard API key as the password. 401 means fix the credentials for the target service.

IP whitelisting removes the proxy-credential variable altogether — useful on servers where secrets handling is a pain.

Geo redirects that shed your header

Some services redirect by region — an exit IP in the wrong country bounces you to a country-specific host, and your HTTP client strips the Authorization header on the cross-host redirect, producing a 401 on arrival.

Pin your exit country with -country-us (or whichever region your account expects) so you land on the host your integration was built against.

401 Unauthorized

An authenticated flow that survives the proxy

This pattern keeps one exit IP for the whole authenticated session and sends target credentials on every request. The sticky session ID holds the IP stable for up to 24 hours; change the ID when you want a fresh one.

import requests

# Sticky session: same residential exit IP for the whole flow (up to 24h)
proxy = "http://USERNAME-country-us-session-job42:[email protected]:10000"

s = requests.Session()
s.proxies.update({"http": proxy, "https": proxy})
s.headers["Authorization"] = "Bearer YOUR_TARGET_API_TOKEN"

login = s.post("https://api.example.com/v1/login", json={"user": "me"}, timeout=30)
account = s.get("https://api.example.com/v1/account", timeout=30)
print(account.status_code)  # 200 — same exit IP for both calls

FAQ

Frequently asked questions

What's the difference between 401 and 403?

401 is authentication: the server doesn't know who you are, or your proof expired — send valid credentials and it will reconsider. 403 is authorization: it knows exactly who you are and still refuses. A 401 response includes a WWW-Authenticate header telling you which scheme to use; a 403 offers no such invitation. Fix credentials for 401s; fix permissions or access strategy for 403s.

What's the difference between 401 and 407?

The source. A 401 comes from the target site and concerns your credentials for that service; a 407 comes from the proxy and means your proxy username or password failed. With ProxyOmega, the proxy password is your dashboard API key — or whitelist your server IP and authenticate by source address, which removes 407s from the equation entirely.

Why do I get 401 after a successful login through a rotating proxy?

The service bound your session to the IP that logged in, and rotation moved you off it. From the server's view, a valid session arriving from a new address looks like theft, so it invalidates it. Route the entire flow — login through last request — over one sticky session (-session- on the username) so the exit IP stays constant for up to 24 hours.

Can a proxy strip my Authorization header?

Not on HTTPS. The client builds an encrypted tunnel through the proxy, and everything inside — headers included — is invisible to it. When an Authorization header disappears, the culprit is nearly always your own HTTP client dropping it on a cross-host redirect, or code setting the header on the wrong object. Capture the outgoing request to confirm what actually left your machine.

Keep authenticated sessions alive at scale. Start routing today.

ProxyOmega sticky sessions hold one residential exit IP for up to 24 hours — long enough for any login flow you run.

Get started