The 407 error code is called the Proxy Authentication Required code. If a request gets stopped by a proxy server before it reaches the website, then you are most likely facing this code. It is the proxy telling you that either it needs authentication credentials or the ones you entered are incorrect.
Anyone who uses proxies for scraping, automation, or general data collection has run into a 407 error at some point. It is a frustrating roadblock but it is one of the easiest to fix because the reason for it traces back to how the proxy credentials are set up.
In this article, we will explain what the 407 error code means, why it happens, how to tell the code apart from the 401 error code, and seven ways to fix it. If you are troubleshooting other proxy failures too, start with our full guide to proxy error codes.
What is 407 Error Code?
The RFC 9110 defined the 407 error code as “407 Proxy Authentication Required”. It means that a proxy server looked at your request and refused to pass it along because it was missing authentication.
While most 4XX error codes are about a direct interaction between your browser and a website, 407 is exclusively a proxy-based code. This is because of what the proxy does to your connection. A proxy sits between your router and the website’s server. As such, it needs authentication before it can process the request.
When the proxy rejects your request, it sends back a response containing a Proxy-Authenticate header. That header will specify the authentication scheme the proxy expects such as Basic, Digest, NTLM, or Negotiate. Your client will then need to retry the same request and include a Proxy-Authorization header with your credentials formatted to match the scheme the proxy asked for.
In raw HTTP, the proxy's rejection looks like this:
Your client's retry should look like this:
If you get your credentials right, the proxy will forward the request as if nothing happened. If your credentials are wrong, then the 407 error code will appear.
The 407 error code comes in a couple of variations that all account to the same thing. These include:
- 407 Proxy Authentication Required
- HTTP Error 407
- HTTP 407
- 407 Authorization Required
- Proxy Authentication Required
- Error 407
- Status Code 407
407 vs 401 Error Code
The 407 error code often shares similarities to the 401 error code. Both codes are authentication errors and mean you failed to prove your identity. Where they differ is in where they sit on the chain of connection.
The 407 error code is about the proxy. Your request has reached the proxy server but the proxy has blocked it because you did not provide valid credentials. The response comes with a Proxy-Authenticate header and you will need to answer with a Proxy-Authorization header.
401 error code is more about the destination website. Your request has made it past any proxies in place just fine and arrived at the website successfully. The issue happens because the website itself is not giving your authorization to enter. The response comes with a WWW-Authenticate header and will need an Authorization header as an answer.
The trick comes from being able to tell which is which. The best way to know this is to check the response headers. If you see Proxy-Authenticate, then you are dealing with 407. If you see a WWW-Authenticate, then it is a 401. It is critical to be aware of this minor difference as it will save you from wasting time debugging the wrong thing.
Some of the other 4XX error codes to be aware of are the 403 error code which means the server knows who you are but is still refusing access, making it a permission issue and not a credential one, and the error code 400 which means the request was broken or malformed, meaning it has nothing to do with your credentials or permissions. To get a full understanding of all possible error codes and some way to bypass them, check out our article on How to Resolve a Proxy Error Code in 2026.
What Causes 407 Error Code?
As the 407 error code belongs to the 4XX class, that means it is a client-side issue. The proxy server is doing what it is supposed to do but when it checks for valid credentials, it does not find them. This unfortunately does mean the issue is from your end rather than the server or the website.
The primary culprit behind a 407 error is bad or missing credentials. This could happen because your browser or script is connecting through the proxy but never including the Proxy-Authorization header, or you could have pasted the password from your provider’s dashboard and accidentally grabbed an extra space at the end or missed something at the start, or you mistyped one character in a structured name like user-country-us-session-abc123, thus invalidating the whole string. The 407 response does not specify which of these happened, just that something went wrong.
Expired credentials often catch people off guard because nothing about their setup changes. Everything has been working perfectly fine for a while and then suddenly, the 407 error code appears. What likely happened in this instance is that the provider rotated the API keys or passwords on their end. This is a common occurrence on trial accounts where providers enforce periodic credential rotation. Most providers would send an email informing you of this instance beforehand but if the email was not sent to you or got buried in your inbox, you will not know until it is too late.
The authentication scheme mismatch is another possible reason but is a bit more difficult to spot. Your username and password may still be correct but the proxy will still reject you because it expects NTLM while your client sends Basic. The credentials themselves are valid, but the format does not match what the server expects. This comes up in corporate proxy environments that are tied to Windows Active Directory where the proxy infrastructure uses Windows-integrated authentication while the script or tool you are running does not support it.
One other possibility is that you may be talking to the wrong proxy. One wrong digit in the address or port number can send your request to a completely different server. This still makes the error code a 407 despite it not having anything to do with the credentials you sent. It is more about where you sent them.
Proxy users who work with web crawling tools and scraping frameworks often deal with the 407 error code because their setup has more moving parts. The proxy endpoint, the credential format, the auth scheme, the IP rotation configuration, and the HTTP library all need to line up perfectly. When a single piece is off, the 407 error code appears with no further explanation about which of those is causing the issue.
How to Fix 407 Error Code
In this section, we will be providing you with seven possible solutions. We recommend you go through them one by one until the issue is resolved. The steps run from simple configuration checks to deeper technical adjustments.
1. Verify Your Proxy Server Address and Port
The first step you should take before diving into deeper configuration changes is to confirm you are connecting the right server. Open up the proxy details your provider gave you and compare the address and port against what you have in your configuration. Make sure the details match exactly.
Having an incorrect address or port does not always produce the 407 error code. Sometimes it will route you to a different proxy that is live and responding but is not the one that recognizes your credentials.
You can check the active system-level proxy on Windows by opening the Command Prompt and running the following:
On macOS, go to System Settings > Network > Wi-Fi (or your active connection) > Proxies.
2. Check Your Authentication Credentials
For most users, their troubleshooting ends here. Go to your proxy provider’s dashboard and find the active credentials. Once you do, compare them character by character against what you have configured. The reason you go character by character is that there could be an extra space or accidental dot or comma you entered while quickly typing or copy/pasting the details which is causing the 407 error code.
Structured usernames need extra attention, depending on how your providers formats them. Some providers choose to format usernames like this: user-country-us-session-abc123. Carefully make sure every part is present and in the right order. With the dashboard still open, it might be wise to verify that your account is still active. Any credentials tied to a trial period or lapsed billing cycle may have been deactivated without your knowledge.
3. Inspect the Proxy-Authenticate Response Header
The Proxy-Authenticate header will tell you exactly what authentication scheme the proxy wants. If there is a mismatch between what the proxy expects and what your client is sending, then no matter how many times you rewrite the password, the issue will not be resolved.
To find the header in Google Chrome, press F12 (or Cmd+Option+I on macOS), switch to the Network tab, reload the page, find the 407 request, and look at the Response Headers for the Proxy-Authenticate value.
If the request comes back as Basic, then you are dealing with the most common scheme and one that most tools will handle natively. If it is coming back as NTLM or Negotiate, then it means it is a Windows-integrated authentication and not every HTTP client supports those. This frequently catches developers off guard, especially those who write scripts behind corporate proxies as many lightweight HTTP libraries do not have built-in support for anything beyond Basic.
4. Test the Connection with cURL
If all of the above steps have not worked yet, then it is time for a little bit of coding. cURL is the fastest way to figure out whether your problem is credential based or application based. It strips away everything else and sends a raw request through the proxy with exactly the credentials you provided. It removes any browser, extensions, or framework middleware, just a basic connection check. This can be done by running this command:
Use the -v flag as you want the verbose output to show you the entire conversation between your client and proxy, including the Proxy-Authenticate challenge and any Proxy-Authorization header your request sent back.
If cURL returns a successful response with an IP address, then the credentials work and the problem is in your application’s proxy setup. If cURL sends back a 407 error code, then the credentials themselves are definitely the issue.
If you are using HTTPS proxies, try this command:
5. Review Your Code or Script Configuration
If you are connecting through a proxy in your code rather than your browser, then this might be your solution. Check if the Proxy-Authorization header is actually being sent with each request. Not all HTTP libraries do this automatically as some expect you to embed credentials in the proxy URL while others require you to construct and attach the header yourself.
While using the requests library in Python, embedding credentials in the URL is the standard approach and looks something like this:
If your code is in a shared repository, it is better to store credentials as environment variables. Most HTTP clients read these automatically and it will keep sensitive information out of your source files.
Windows (Command Prompt):
macOS and Linux:
6. Check Whether IP Whitelisting is Required
In addition to a username and password authentication, some proxy providers use IP whitelisting. When this is active, only requests from pre-approved IP addresses get through. Your credentials could be correct but if your IP is not on the list, you will see the 407 error code.
Residential internet connections cycle through IP addresses frequently. Switching from Wi-Fi to a mobile hotspot gives you a different IP entirely. Even rebooting your router can sometimes result in a new address from your ISP. You can check your current public IP by entering the following:
Compare the result against the whitelist in your provider’s dashboard. If there is a mismatch, update it and try again.
7. Contact Your Proxy Provider or Network Administrator
If you find yourself at the seventh solution and nothing above has worked, then your next step is to contact your proxy provider directly. Occasionally, providers have their own issues such as authentication backends going down, bad configurations getting deployed, or maintenance windows without warning.
You should reach out to the support team and include the Proxy-Authenticate header from the 407 response, the proxy endpoint you were connecting to, and your cURL test results. This will give them everything they need to start investigating the issue right away and save you any more time wasted.
Preventing 407 Error Code
Since the 407 error code is based on incorrect credentials, preventing it should not be too difficult, as long as the provider's systems are not experiencing an outage.
It is recommended to keep all credentials in a password manager or in environment variables. Do not paste them directly into your script files where they sit in plain text. There is an added security risk if the code ever ends up in a shared repository. If your provider rotates credentials on a regular cycle, set a reminder to yourself a few days before so you can anticipate and plan the rotation.
Anytime your network setup changes, take a moment to verify that the proxy connection still works. Providers that use IP whitelisting will need the new address added to the approved list.
Lastly, build 407-specific error handling in your scripts and pipelines to log the status code, proxy endpoint, and timestamp. Generic error handlers bury authentication failures in noise and you end up debugging for much longer than necessary.
Conclusion
407 error code means a proxy server got your request, could not verify your identity, and refused to pass it along. The credentials were missing, wrong, expired, or formatted incorrectly. It is a client-side error, so the fix is most likely coming from your proxy configuration rather than the destination website.
Key Takeaways:
- 407 triggers when a proxy server requires authentication and your client does not deliver valid credentials. The website you were trying to reach is not involved.
- It is not the same as the 401 error code. 401 comes from the website, 407 comes from the proxy. Check the response headers to tell them apart.
- The Proxy-Authenticate header is your best diagnostic tool because it tells you exactly what scheme the proxy expects.
- cURL isolates credential issues from application issues. If cURL works but your application does not, the credentials are fine and the problem is in the application.
- If you use mobile proxies for scraping, automation, or data collection, treat credential management as an operational concern. Store them securely, watch for expiration, and catch 407 responses explicitly in your error handling.
- The same applies to residential proxies, especially when your setup depends on rotating credentials, sticky sessions, or IP whitelisting.
Start with the credentials as more often than not, that is where the problem is. If those are confirmed correct, work through the rest of the list. The error itself is simple once you understand it involves your client and the proxy. Your browser cache, your DNS, and your firewall are not the cause here. It is just you, the proxy, and whether you authenticated properly.