Got a 407 or a 403? Here's what they mean

Short version: a 407 always comes from the proxy, and it's about your login. A 403 almost always comes from the website you're visiting. Work out who sent it first, because the fixes are completely different.

Who sent it?

Run the request with curl -v and read the lines that start with <:

curl -sv -o /dev/null --proxy "http://HOST:PORT" --proxy-user 'USERNAME:PASSWORD' https://api.ipify.org

For an https:// site, your client first asks the proxy to open a tunnel. If it agrees, you'll see HTTP/1.1 200 Connection established.

• A status before that line came from the proxy.
• A status after it came from the website, through a tunnel the proxy can't read or change.

407 Proxy Authentication Required

The proxy didn't accept your login, so your request never reached the site. Check, in this order:

1. Fresh credentials. Copy the username and password again from the proxy's Connection card. No spaces, no line breaks. Credentials read from a .env file often end in a newline: strip it.
2. Special characters. @, :, / or # in a password break a proxy URL. Percent-encode them (@ is %40) or pass the credentials separately with --proxy-user.
3. Right proxy, right credentials. Copy them from the proxy you're actually dialling.
4. Your tool really sends them. Chrome ignores credentials written into --proxy-server; Puppeteer needs page.authenticate(), Selenium an extension, Playwright the username and password options. Some tools only send credentials after a first 407, so a single 407 in a log isn't always a failure.

One plain curl command with the same credentials works but your script doesn't? The credentials are fine; your script passes them wrong. More in Username and password: getting the proxy URL right.

403 Forbidden

Nearly always the website: it understood the request and said no. Your credentials are fine. Usually it doesn't like the IP range, your headers or your pace.

1. Read the response. The body often says why, and headers like Server or cf-ray show who answered.
2. Try without the proxy. A 403 both ways means it's the request, not the IP.
3. Send normal headers. A browser User-Agent, with matching Accept and Accept-Language. Default ones like python-requests get refused on sight.
4. Slow down. Some sites answer too much traffic with a 403 instead of a 429.
5. Keep cookies and the IP together. A session cookie replayed from a new IP looks stolen. Keep logged-in flows on one static IP.
6. Datacenter IP refused, home connection fine? The site blocks hosting ranges. Try an ISP IP: it's registered to a consumer ISP. Residential, coming soon, is too.

A 403 that arrives before 200 Connection established came from the proxy itself, not the site. Check the proxy is Active and that you're connecting the way it's set up (password or allowlist), then email support@proxymonkey.io with the curl -v output, password removed.

Whatever the code

• Is the proxy running? Its status should be Active, it should be inside its Expires date, and a residential proxy needs traffic left.
• On an IP allowlist? Then the proxy doesn't use usernames and passwords, and only the listed addresses get in. See IP allowlist: skip the username and password.

Still blocked by a site after all that? Send us what Blocked by a site? Send us this lists.