Ошибка 407 proxy authentication required

Feb 1, 2018 10:00:26 AM |
What is a 407 Proxy Authentication Required

An in-depth overview of what a 407 Proxy Authentication Required response code is and how to fix it in your own application.

The 407 Proxy Authentication Required is an HTTP response status code indicating that the server is unable to complete the request because the client lacks proper authentication credentials for a proxy server that is intercepting the request between the client and server. The 407 error code is similar to the 401 Unauthorized error we looked at a few months ago, which indicates that the client could not be authenticated with the server. However, in the case of a 407 Proxy Authentication Required error, the server isn’t reporting a direct authentication issue, but is instead reporting that the client needs to authenticate with a proxy server, which must send a special Proxy-Authenticate header as part of the response.

As with most HTTP response codes — especially those that indicate an error — the cause of a 407 Proxy Authentication Required error code can be challenging to find and fix. With a possible pool of over 50 status codes used to represent the complex relationship between the client, a web application, a web server, and (possibly) multiple third-party web services, determining the cause of a particular status code can be difficult under the best of circumstances.

In this article we’ll examine the 407 Proxy Authentication Required in more detail by looking at what might cause this message to appear, and we’ll go over a handful of tips you can use to diagnose and debug the appearance of this error within your own application. We’ll even examine a number of the most popular content management systems (CMSs) for potential problem areas that could cause your own website to be generating a 407 Proxy Authentication Required unexpectedly. Let’s get to it!

Server- or Client-Side?

All HTTP response status codes that are in the 4xx category are considered client error responses. Errors in the 4xx category contrast with those from the 5xx category, such as the 503 Service Unavailable Error we wrote about a couple months ago, which are considered server error responses. That said, the appearance of a 4xx error doesn’t necessarily mean the issue is on the client side (the «client», in this case, is typically the web browser or device being used to access the application). Oftentimes, if you’re trying to diagnose an issue within your own application, you can immediately ignore most client-side code and components, such as HTML, cascading style sheets (CSS), client-side JavaScript, and so forth. This doesn’t apply solely to web sites, either. Many smart phone apps, which implement a modern looking user interface, are often powered behind the scenes by a normal web application.

On the other hand, the server could be the root cause of a 407 Proxy Authentication Required error. In some cases, the server may be misconfigured and handling requests improperly, which can result in 407 code responses and other problematic traffic routing issues. We’ll explore some of these scenarios (and potential solutions) down below, but be aware that, even though the 407 Proxy Authentication Required is considered a client error response, it doesn’t inherently mean we can rule out either the client nor the server as the culprit in this scenario. In these situations, the server (or a proxy server, in some cases) is still the network object that is producing the 407 Proxy Authentication Required and returning it as the HTTP response code to the client, but it could be that the client is causing the issue in some way.

Start With a Thorough Application Backup

As with anything, it’s better to have played it safe at the start than to screw something up and come to regret it later on down the road. As such, it is critical that you perform a full backup of your application, database, and all other components of your website or application before attempting any fixes or changes to the system. Even better, if you have the capability, create a complete copy of the application and stick the copy on a secondary staging server that is either inactive, or publicly inaccessible. This will give you a clean testing ground on which to test all potential fixes needed to resolve the issue, without threatening the security or sanctity of your live application.

As discussed in the introduction, a 407 Proxy Authentication Required indicates that the client has failed to provide proper authentication credentials to a proxy server that is a node (i.e. connection) between the client and the primary web server accepting the original request. As specified by RFC7235 HTTP/1.1 Authentication standards document the proxy server must send a special Proxy-Authenticate header, which indicates to the client what type of authentication can be used to complete the original request, and what access that will provide.

The basic syntax of the Proxy-Authenticate header is as follows: Proxy-Authenticate: <type> realm=<realm>.

The <type> value can be any of the handful of valid authentication schemes allowed in HTTP/1.1, with the most common authentication scheme being Basic, which accepts a username and password credential pair to validate authentication.

The <realm> value is used as a simple description of the protected area or «scope» of access that this particular authentication process will provide to the client.

Once the client receives a 407 response code that includes a Proxy-Authenticate header indicating the authentication scheme the proxy server will accept, the user agent will then typically respond with the corresponding Proxy-Authorization request header: Proxy-Authorization: <type> <credentials>.

Just as with the Proxy-Authenticate response header, <type> in the Proxy-Authorization request header is used to specify the authentication scheme, which should match the scheme required by the proxy server.

The <credentials> should be replaced with the valid credentials to authenticate the client. In the case of a Basic authentication scheme the username and password values are concatenated with a colon separator (i.e. username:password), which is then encoded to a base64 text string. Thus, a full Proxy-Authorization request header using the Basic scheme with a username and password of username and password would look like this: Proxy-Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=. Once the user agent includes that header in the follow-up request, the proxy server will authenticate and authorize the client and the request will succeed.

Troubleshooting on the Client-Side

Since the 407 Proxy Authentication Required is a client error response code, it’s best to start by troubleshooting any potential client-side issues that could be causing this error. Here are a handful of tips to try on the browser or device that is giving you problems.

Check the Requested URL

The most common cause of a 407 Proxy Authentication Required is simply inputting an incorrect URL. Many servers are tightly secured, so as to disallow unexpected requests to resources that a client/user agent should not have access to. It may be that the requested URL is slightly incorrect, which is causing the user agent to request an unintended resource, which may be routed through a proxy server that requires authentication. For example, a request to the URI https://airbrake.io/login might route requests through a separate proxy server used to handle user authentication. If the original request did not contain appropriate credentials, the result could be a 407 Proxy Authentication Required error response. It’s always a good idea to double-check the exact URL that is returning the 407 Proxy Authentication Required error to make sure it is intended resource.

Debugging Common Platforms

If you’re running common software packages on the server that is responding with the 407 Proxy Authentication Required, you may want to start by looking into the stability and functionality of those platforms first. The most common content management systems — like WordPress, Joomla!, and Drupal — are all typically well-tested out of the box, but once you start making modifications to the underlying extensions or PHP code (the language in which nearly all modern content management systems are written in), it’s all too easy to cause an unforeseen issue that results in a 407 Proxy Authentication Required.

There are a few tips below aimed at helping you troubleshoot some of these popular software platforms.

Rollback Recent Upgrades

If you recently updated the content management system itself just before the 407 Proxy Authentication Required appeared, you may want to consider rolling back to the previous version you had installed when things were working fine. Similarly, any extensions or modules that you may have recently upgraded can also cause server-side issues, so reverting to previous versions of those may also help. For assistance with this task, simply Google «downgrade [PLATFORM_NAME]» and follow along. In some cases, however, certain CMSs don’t really provide a version downgrade capability, which indicates that they consider the base application, along with each new version released, to be extremely stable and bug-free. This is typically the case for the more popular platforms, so don’t be afraid if you can’t find an easy way to revert the platform to an older version.

Uninstall New Extensions, Modules, or Plugins

Depending on the particular content management system your application is using, the exact name of these components will be different, but they serve the same purpose across every system: improving the capabilities and features of the platform beyond what it’s normally capable of out of the box. But be warned: such extensions can, more or less, take full control of the system and make virtually any changes, whether it be to the PHP code, HTML, CSS, JavaScript, or database. As such, it may be wise to uninstall any new extensions that may have been recently added. Again, Google the extension name for the official documentation and assistance with this process.

Check for Unexpected Database Changes

It’s worth noting that, even if you uninstall an extension through the CMS dashboard, this doesn’t guarantee that changes made by the extension have been fully reverted. This is particularly true for many WordPress extensions, which are given carte blanche within the application, including full access rights to the database. Unless the extension author explicitly codes such things in, there are scenarios where an extension may modify database records that don’t «belong» to the extension itself, but are instead created and managed by other extensions (or even the base CMS itself). In those scenarios, the extension may not know how to revert alterations to database records, so it will ignore such things during uninstallation. Diagnosing such problems can be tricky, but I’ve personally encountered such scenarios multiple times, so your best course of action, assuming you’re reasonably convinced an extension is the likely culprit for the 407 Proxy Authentication Required, is to open the database and manually look through tables and records that were likely modified by the extension.

Above all, don’t be afraid to Google your issue. Try searching for specific terms related to your issue, such as the name of your application’s CMS, along with the 407 Proxy Authentication Required. Chances are you’ll find someone who has experienced the same issue.

Troubleshooting on the Server-Side

If you aren’t running a CMS application — or even if you are, but you’re confident the 407 Proxy Authentication Required isn’t related to that — here are some additional tips to help you troubleshoot what might be causing the issue on the server-side of things.

Confirm Your Server Configuration

Your application is likely running on a server that is using one of the two most popular web server softwares, Apache or nginx. At the time of publication, both of these web servers make up 84% of the world’s web server software! Thus, one of the first steps you can take to determine what might be causing these 407 Proxy Authentication Required response codes is to check the configuration files for your web server software for unintentional redirect or request handling instructions.

To determine which web server your application is using you’ll want to look for a key file. If your web server is Apache then look for an .htaccess file within the root directory of your website file system. For example, if your application is on a shared host you’ll likely have a username associated with the hosting account. In such a case, the application root directory is typically found at the path of /home/<username>/public_html/, so the .htaccess file would be at /home/<username>/public_html/.htaccess.

If you located the .htaccess file then open it in a text editor and look for lines that use ProxyXXX directives, which are part of the mod_proxy module in Apache. Covering exactly how these directives work is well beyond the scope of this article, however, the basic concept is that proxy directives allow the Apache server to map or associate local server requests and URIs to remote proxy locations.

For example, here we’ve enabled ProxyPass and ProxyPassReverse directives to match requests to the local /login URI and route them to https://proxy.airbrake.io/login. The <Location /login> section defines the authentication scheme and details we’re using:

ProxyPass        /login https://proxy.airbrake.io/login

ProxyPassReverse /login https://proxy.airbrake.io/login
<Location /login>
 Order deny,allow
 Allow from all
 AuthName "Login Authentication"
 AuthType basic
 AuthUserFile "/usr/local/apache2/conf/httpd.htpasswd"
 AuthGroupFile "/usr/local/apache2/conf/httpd.groups"
 </Location>
 

This is just one possible example, but if your own server is using a proxy then your particular configuration will look quite different. Look for any strange Proxy directives in the .htaccess file that don’t seem to belong, then try temporarily commenting them out (using the # character prefix) and restarting your web server to see if this resolves the issue.

On the other hand, if your server is running on nginx, you’ll need to look for a completely different configuration file. By default this file is named nginx.conf and is located in one of a few common directories: /usr/local/nginx/conf, /etc/nginx, or /usr/local/etc/nginx. Once located, open nginx.conf in a text editor and look for proxy_ directives. For example, here is a simple block directive (i.e. a named set of directives) that configures a virtual server for airbrake.io and ensures that, similar to above, a request to https://airbrake.io/login will be authenticated via the proxy_pass directive to https://proxy.airbrake.io/login:

server {

    listen 80;

    listen 443 ssl;

    server_name airbrake.io;
 location /login/ {
 auth_basic "Login Authentication";
 auth_basic_user_file /etc/nginx/conf.d/nginx.htpasswd;
 proxy_pass https://proxy.airbrake.io/login;
 proxy_set_header Host $http_host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 proxy_read_timeout 900;
 }
 }
 

Have a look through your nginx.conf file for any abnormal proxy_ directives and comment out any abnormalities before restarting the server to see if the issue was resolved.

Configuration options for each different type of web server can vary dramatically, so we’ll just list a few popular ones to give you some resources to look through, depending on what type of server your application is running on:

• Apache
• Nginx
• IIS
• Node.js
• Apache Tomcat

Look Through the Logs

Nearly every web application will keep some form of server-side logs. Application logs are typically the history of what the application did, such as which pages were requested, which servers it connected to, which database results it provides, and so forth. Server logs are related to the actual hardware that is running the application, and will often provide details about the health and status of all connected services, or even just the server itself. Google «logs [PLATFORM_NAME]» if you’re using a CMS, or «logs [PROGRAMMING_LANGUAGE]» and «logs [OPERATING_SYSTEM]» if you’re running a custom application, to get more information on finding the logs in question.

Debug Your Application Code or Scripts

If all else fails, it may be that a problem in some custom code within your application is causing the issue. Try to diagnose where the issue may be coming from through manually debugging your application, along with parsing through application and server logs. Ideally, make a copy of the entire application to a local development machine and perform a step-by-step debug process, which will allow you to recreate the exact scenario in which the 407 Proxy Authentication Required occurred and view the application code at the moment something goes wrong.

No matter the cause — and even if you managed to fix this particular error this time around — the appearance of an issue like the 407 Proxy Authentication Required within your own application is a good indication you may want to implement an error management tool, which will help you automatically detect errors and will alert you the instant they occur. Airbrake’s error monitoring software provides real-time error monitoring and automatic exception reporting for all your development projects. Airbrake’s state of the art web dashboard ensures you receive round-the-clock status updates on your application’s health and error rates. No matter what you’re working on, Airbrake easily integrates with all the most popular languages and frameworks. Plus, Airbrake makes it easy to customize exception parameters, while giving you complete control of the active error filter system, so you only gather the errors that matter most.

Check out Airbrake’s error monitoring software today and see for yourself why so many of the world’s best engineering teams use Airbrake to revolutionize their exception handling practices!

Что такое Proxy Authentication Required или Error 407? – это сбой в работе прокси сервисов, которые используются в программах VPN, например, FriGate. Кроме того, ошибка 407 может возникнуть в ряде других программ, которые подключаются к сети через прокси лист: Visual Studio, Key Collector и другие. Однако, наибольшее беспокойство доставляет ошибка HTTP 407 при работе с бесплатными VPN сервисами.

Как исправить Error 407 Proxy Authentication Required? Как настроить компьютер, чтобы решить проблему? Есть ли аналоги программ, которые работают без Proxy? Что делать, если status code 407 Proxy Authentication Required не исчезает? К слову, эта ошибка очень похожа на ошибку 401, только в этом случае ошибка на вашей стороне, а не на стороне сервера. Посмотрите подробный отчет для действий.

Вы спокойно ищите нужную информацию в своем браузере и тут натыкаетесь на ошибку 407. Окошко может иметь разные уведомления, но чаще всего все сводится к следующему: «The request with HTTP status 407: Proxy Authentication Required”. Данное уведомление сообщает, что между вами и сервером возникла ошибка. Причем ошибка 407 возникает только на стороне клиента, т.е. пользователя.

Чаще всего проблема возникает при использовании плагина FriGate – дополнения, которое работает с помощью прокси. Для чего оно у вас стоит? Скорее всего, вы пытаетесь зайти на сайт, который заблокирован провайдером, роскомнадзором или другими органами, которые контролируют интернет трафик. FriGate – это посредник между вашим браузером и сайтом, который вы хотите открыть. Работает он по принципу VPN. Подключаясь к нему, вы создаете видимость подключения из другой страны.

Например, вы хотите попасть на сайт, который закрыт провайдером. Устанавливая FriGate вы подменяете свое настоящее местоположение фиктивным. Провайдер видит трафик, но обращение идет на посторонний сервер. Не будем углубляться в детали – суть одна, FriGate не работает, и вы видите ошибку 407. В чистом браузере ошибка http 407 возникнуть просто не может. Она возникает только ввиду не работающего соединения с прокси.

Что делать, если в браузере возникла ошибка 407? Как устранить Error 407 Authentication Required? Ниже список шагов, которые актуальны именно для проблемы, которая возникла на стороне браузера.

• Если вы использовали платный прокси – выйдите из аккаунта и войдите снова;
• Если вы использовали FriGate – отключите плагин и удалите его из браузера. Затем установите более свежие и обновляемые VPN сервисы. На крайний случай можно использовать платные VPN или установить браузер Opera? Перейти в приватный режим и включить кнопку VPN в адресной строке. Эффект тот же – ошибка 407 вас больше не затронет.
• Если в браузере чисто – закройте программу VPN. Возможно сервер с прокси сегодня не доступен или сама программа перестала корректно работать.
• Установите для теста бесплатную версию платных прокси серверов или VPN сервисов. Если проблема устранена – отлично, проблема ясна.
• Используйте платные прокси. Стоит это дёшево и если есть на, то необходимость, можно потратить в месяц 1$ для стабильности в трафике.
• Пройдите на сайт определения IP адреса. Если у вас выдает ваш стандартный местный ip адрес – у вас проблемы с VPN 100%.

ВАЖНО: Ошибка 407 возникает ТОЛЬКО со стороны вашего компьютера. Сайт, на который вы не можете зайти тут не при чем! Ошибка возникает ТОЛЬКО если у вас установлены дополнения, прокси сервисы или VPN.

Не нужно «лечить» компьютер перезагрузкой или переустановкой системы. Когда у вас болит палец на ноге, вы же не лечите проблему свечами от геморроя? Так и здесь. Таблетка от проблемы и шаги к исправлению ошибки 407 Proxy Authentication Required указаны выше. Ни реестр, ни система, ни антивирус тут ни при чем. Действуйте.

1. Ошибка 407 в программах, работающих через Proxy

Предположим вы – вебмастер. У вас установлена программа Key Collector, которая работает через прокси для безопасности аккаунтов в Яндекс и Google. Кроме того, программа использует прокси лист для ускорения работы парсера.  Вы купили прокси и ввели их в настройках. Другие программы работают по аналогичному принципу. В настройках вы прописываете адрес и данные авторизации.

Что означает ошибка 407 Proxy Authentication Required в программах? На самом деле все просто – либо вы ошиблись при вводе данных авторизации оплаченных прокси, либо ваш прокси лист закончился. Например, вы купили прокси 1 января до 1 марта. Естественно, что вы получите ошибку 407, если сегодня 2 марта. А еще, вы могли попытаться купить прокси как можно дешевле и получили не самый отзывчивый прокси сервер.

Для подобных программ стоит покупать проверенные прокси. Также следует не забывать, что на работе некоторые администраторы ставят защиту от использования подобных программ и прокси. Поэтому, если вы решили «подрабатывать» на работе – займитесь своими прямыми задачами.

Мы помогли вам решить вопрос? Удалось ли вам исправить HTTP 407 Proxy Authentication Required? Если остались вопросы – напишите нам в комментариях с деталями проблемы. В идеале прикрепить скриншот с ошибкой, чтобы наш специалист помог разобраться с проблемой.

Errors are one of the most frustrating aspects of running a WordPress site. Some problems like HTTP Error 407 can make your content inaccessible, leading to a drop in sales or conversions.

Luckily, there are some easy steps you can take to resolve this issue, plus tools to help you debug your site. By identifying the root cause of the problem, you can implement the right fix and hopefully prevent it from happening again in the future.

In this article, we’ll take a closer look at the HTTP 407 error and its causes. Then, we’ll show you how to fix it on the client side and server side. Let’s get started!

Check Out Our Video Guide To Fixing HTTP Error 407 “Proxy Authentication Required”

What Does “407 Proxy Authentication Required” Mean?

The “407 Proxy Authentication Required” error occurs when the server is unable to complete a request. This happens due to a lack of authentication credentials when a proxy server is used between the client and server. Essentially, the proxy is unable to authenticate the client.

Since there are multiple parties involved, it can be tricky to identify the exact cause of the problem. It may even be caused by the proxy itself, meaning there is no fix on your end.

However, there are some things that you can do to try to resolve the communication with the proxy.

Note that this problem may also be related to the generic 400 Bad Request error.

Inaccessible content can mean a drop in sales or conversions… but luckily, there are some easy steps you can take to resolve this frustrating error 💪Click to Tweet

What Causes the HTTP Error 407?

HTTP errors happen when a client requests to connect to a server and fails. Anytime a web browser attempts to access an online server through the HTTP protocol, there is a conversation between the client and server. HTTP codes are used to handle that conversation, sending success and failure messages back and forth.

HTTP error 407 is similar to error 401, which occurs due to unauthorized access. The only difference is that error 407 fails authentication with a proxy rather than a direct server connection.

Client authentication is part of the process of establishing a secure connection. One component of this communication is the exchange of a digital certificate. This certificate may be tied to the digital ID of a person, company, program, or individual machine. Servers can approve or deny requests based on the data within a digital certificate and grant or withhold access to connect.

In many cases, a simple connection delay, typo, or code contradiction can lead to a digital ID being misunderstood and rejected. Alternatively, you might not have access to the server.

How To Fix the “407 Proxy Authentication Required” Error

Since there are three different parties involved, you may need to try a few different solutions to resolve HTTP error 407. You may have access to the client and server, but the proxy is likely out of your control.

Hopefully, you’re using an Application Performance Monitoring (APM) software that caught the error before it became a larger problem. There are several powerful APM tools that can help you identify and resolve errors on your site, including our Kinsta APM tool. You can access this from the MyKinsta dashboard.

Now, let’s look at how to identify the cause of HTTP error 407 and resolve the issue. As always, it’s a good idea to perform a backup before making changes to your site.

Fixing a Client-Side Issue

Checking for client-side issues is probably the quickest and easiest place to start. To rule out any oddities, you can try to connect from a different browser or device. For instance, if you get a 407 error on your computer but not your phone, there may be an issue with the device’s digital ID or security program.

If you’ve made changes to your site recently, you may want to undo them and test the connection again. Otherwise, if you have reason to believe it could be a client-side issue, you can try the following steps.

Step 1: Check the URL

First, you’ll want to make sure that you’re entering the correct URL. This may sound silly, but a minor typo can lead to the HTTP 407 error. Therefore, you’ll want to double-check the URL, clear your cache, and try revisiting the website.

Better yet, try using a search engine to pull up the page you’re looking for, rather than typing in the URL directly. If you’re still receiving an authentication error, there is likely an issue on the back end.

Step 2: Deactivate Your Plugins

If you’ve recently made any changes that seem to coincide with the error, that is a good lead to pursue. If the error is happening on your own website, you might want to take a look at any recent plugins, themes, or extensions you have added or updated.

If you’re still able to access your dashboard, go to the Plugins page and deactivate all of your plugins:

Then, try to connect to the site again to see if the error persists. If not, you may have found the source of the problem.

Now, reactive your plugins one at a time and keep refreshing the page. If HTTP error 407 only occurs when a certain plugin is active, there may be some issue with the coding that is preventing you from accessing the proxy server.

If you’re unable to access the WordPress dashboard, you’ll need to connect to your site via a File Transfer Protocol (FTP) client like FileZilla. Once you enter your credentials and connect to your site, navigate to public_html > wp-content and locate the plugins folder.

Then, right-click on the folder and select Rename:

By renaming this folder, you’ll automatically deactivate all plugins on your site. Now, check to see if the error has disappeared. If it has, you can rename the folder back to plugins and log into your WordPress dashboard to reactive your plugins one by one until you find the culprit.

You might want to check to see if there is an update available for the glitchy plugin, as this may resolve the issue. If not, consider reaching out to the developer to see if they’re aware of the problem and if they’re working on a solution.

Step 3: Review and Roll Back Recent Changes

If you can’t find any issues on the client-side that could be causing the problem, the last thing you can do before moving on is to run a restoration. If you can revert the site to a previous instance before the error cropped up, this will determine if the problem was caused by a recent change or an external source.

If possible, run a backup before rolling back so you can return to the current version if the error persists. Otherwise, you may revert back and still encounter the problem, then have to redo your work to return your site to its previous state.

If the error no longer occurs after restoring a backup, this may indicate that a recent modification to your site is causing the issue. If you can think of any likely culprits, you can try testing them first. Otherwise, you’ll need to redo any updates incrementally and check to see if the error returns as a result of a specific change.

Fixing a Server-Side Issue

If none of the above steps resolved HTTP error 407, you may be dealing with a server-side issue. If you have other sites on your server, you can check to see if they are experiencing the same error. This will help confirm if the error is present on a particular site only or if it’s originating on the server.

Let’s look at a few troubleshooting steps to help you resolve error 407 on the server side.

Step 1: Review Error Logs

Error logs record activity on your website and server, including any errors that occur. These logs can show you which connection requests are successful and which are failing.

To access your error logs, open your site’s root folder from your FTP. Then, select the logs folder. Here, you’ll see two options: nginx and php. These folders contain error logs that you can view:

Nginx handles serving, proxying, and caching. Note that if your host uses a different server, the name of this file will be different. Meanwhile, PHP is the scripting language that WordPress runs on. If you search either log for error 407, it may shed some light on why it’s happening and when it started.

Step 2: Check Server Config Files

A common cause for a proxy authentication error is an unexpected redirect. This may look suspicious to a proxy server, causing it to deny access. Therefore, you’ll want to check your web server’s configuration files to see if there are any unintentional redirect instructions.

You can do this by checking the .htaccess file. Using an FTP client, go to your website’s root folder and click on the app folder. Then, select public and you should see the .htaccess file:

Open this file and look for any lines of code that include the term “redirect” or are rewriting URLs. If any of these look suspicious or unnecessary, consider removing them (you may want to make a copy of the file first). Then, check to see if error 407 is still present when you try visiting your site.

Since this code is probably in your .htaccess file for a reason, removing it may cause aspects of your site to stop functioning. However, if this code is the cause of HTTP error 407, you will need to address it. We recommend contacting your hosting provider for assistance.

Step 3: Debug App or Scripts

One last thing you can try is debugging your site. If you’ve recently added custom code or new plugins, there’s a chance that a simple bug could be causing authentication issues. The free Query Monitor can help you comb through the code to look for anything suspicious.

Before you get started, we recommend that you clone your site to a staging environment. This can be easily done using DevKinsta. Then, you can safely try to isolate the events that are triggering error 407.

If you need a little help, you can enable WordPress debugging to get a better look at what is going on. You can also turn on the WordPress debug log to track bugs for you to review later.
Learn how to fix this frustrating error (and keep it from happening again) with help from this guide ✅Click to Tweet

Summary

HTTP Error 407 usually happens when the server is unable to complete a request as the client lacks proper authentication credentials for a proxy server. Since this error can prevent users from accessing your site, you’ll want to fix it straight away.

If the problem occurs on the client side, you can try deactivating your plugins and rolling back recent changes to resolve the issue. If it happens on the server side, you’ll need to check your server configuration files, review your application logs, and debug your apps or scripts.

Either way, the simple fixes above should clear the HTTP error 407, and you will be able to move forward.

I’m getting this error when I call a web service:

«The remote server returned an error: (407) Proxy Authentication Required».

I get the general idea and I can get the code to work by adding

myProxy.Credentials = NetworkCredential("user", "password", "domain");

or by using DefaultCredentials in code. My problem is that the call to the web service works in production without this.

It seems like there is a non code solution involving Machine.config, but what is it? At the moment I can’t get to the production box’s machine.config file to see what that looks like. I tried updating my machine.config as follows, but I still get the 407 error.

<system.net>
    <defaultProxy enabled="true" useDefaultCredentials="true">
        <bypasslist>
            <clear />
        </bypasslist>
        <proxy proxyaddress="myproxy:9000"
               usesystemdefault="false"
               bypassonlocal="true"
               autoDetect="False" />
    </defaultProxy>
</system.net>

Умные люди придумали коды, по которым можно определить, что произошло с HTTP-запросом. Успешен ли он, произошло ли перенаправление. Или же все закончилось ошибкой. Как раз об ошибках и будем говорить в этой статье. Вкратце расскажу, какие они бывают и с чем связаны. 

А еще тут будет парочка забавных (и не очень) пикч и анимаций на тему описанных ошибок. Хоть какое-то развлечение.

Ошибки со стороны клиента (4xx)

Для начала перечислим коды ошибок на стороне клиента. Вина за их появление ложится на плечи обоих участников соединения.

400 Bad Request

Такой ответ от браузера можно получить в том случае, если сервер не смог правильно отреагировать на запрос со стороны пользователя. Часто код 400 возникает при попытке клиента получить доступ к серверу без соблюдения правил оформления синтаксиса протокола передачи гипертекста (HTTP). Повторный запрос не стоит отправлять до тех пор, пока не будет исправлена ошибка (или несколько из них). 

401 Unauthorized

Код 401 возникает при попытке клиента получить доступ к серверу, используя неправильные данные для авторизации. По сути, используется, когда пользователь вводит неправильный логин и пароль на ресурсе, где требуется эта информация для входа. Читайте: Как исправить ошибку 401

402 Payment Required

Эта ошибка сообщает клиенту о том, что для успешного выполнения запроса ему необходимо оплатить доступ к серверу. Изначально код 402 должен был стать неким стандартом для цифровой валюты и оплаты контента в сети. Но не срослось. До сих пор нет единого решения по поводу того, как должны выглядеть платежи в сети. Также нет и единого решения по поводу того, как стоит использовать 402. 

Все еще считается, что код существует с расчетом на будущее. Сейчас почти не используется и поддерживается не всеми браузерами.

403 Forbidden

Почти то же, что и 401. Сервер снова не разрешает к нему подключиться, хотя с запросом все в порядке. Просто нет доступа. Причем повторная авторизация с другими логином и паролем никак не помогут. Все вопросы к владельцам сервера (но не всегда). Инструкция по устранению ошибки. 

Творчество на тему знаменитой киносаги

404 Not Found

Легендарная ошибка, ставшая популярным мемом. 404 оповещает клиента о том, что его запрос ведет в никуда. Код возникает, когда пользователь пытается попасть на страницу, которой не существует. Например, когда случайно ошибается при вводе ссылки и вводит ее с опечаткой. Или же пытается получить доступ к странице, которой на сайте уже нет. 

В отличие от других кодов, страницу с 404 частенько кастомизируют, создавая для нее уникальный дизайн. Мало того, что это выглядит симпатичнее, так еще и полезнее для посетителей. Можно прямо на странице с ошибкой разъяснить, что произошло и как дальше действовать.

И таких вариаций тысячи. Каждый пытается добавить в оформление что-то свое.

405 Method Not Allowed

405 сообщает клиенту о том, что метод, используемый при запросе, не разрешен. В качестве примера можно привести попытку со стороны клиента ввести данные в форму с помощью GET, когда она работает только с POST. Ну и в таком же духе. 

406 Not Acceptable

Ошибка 406 сообщает о том, что страница передает контент, который не может быть распознан клиентом. Возможно, проблема в методе сжатия или в формате страницы. Иногда сюда же приплетают неправильные настройки кодировки.

Этот код редко используют на практике, так как его появления можно избежать, предоставив пользователю информацию на сайте в том виде, который его браузер способен принять. Посетитель сайта по итогу получит не то, что ожидал, но хотя бы не ошибку.

407 Proxy Authentication Required

Этот код тоже похож на 401. Только на этот раз логин и пароль нужны не для основного сервера, а для прокси, который находится между клиентом и сервером. Обычно в теле ошибки содержится информация о том, как можно правильно пройти авторизацию и получить доступ к ресурсу.

408 Request Timeout

408 говорит нам о том, что сервер пожелал разорвать соединение с клиентом, потому что оно никак не используется. Происходит это в том случае, если сервер буквально устал ждать, пока наладится соединение с ним. Поэтому такую ошибку часто можно лицезреть после очень долгой и безуспешной загрузки какого-нибудь сайта. 

Многие серверы не отправляют никаких сообщений, а просто прерывают соединение по той же причине. На запрос уходит больше времени, чем на то полагается.

В Мистере Роботе частенько называли серии в честь ошибок HTTP (весь четвертый сезон в нумерации 4хх). В честь 408, например, назвали восьмую серию четвертого сезона

409 Conflict

Сообщение о конфликте возникает, когда запрос со стороны клиента не соответствует тому, чего ожидает сервер. В качестве примера приводят проблемы при проверки версий, когда пользователь пытается с помощью метода PUT загрузить на сервер новый файл, но там уже имеется более новая версия того же файла. Конфликта версий можно легко избежать, загрузив корректную версию.

410 Gone

Своего рода аналог 404. Разница лишь в том, что 410 намекает на перманентность отсутствия страницы. Так что этот код стоит использовать, когда на 100% уверен, что страница ушла в небытие (ну или с текущего адреса) навсегда. В любом другом случае есть универсальный 404. 

411 Length Required

411 оповещает пользователя о том, что сервер не желает принимать запрос со стороны клиента, потому что в нем не определен заголовок Content-Length. Да, это первый код в подборке, который смогут понять только люди, сведущие в настройке серверов. По-простому уложить сущность HTML-заголовков в этот материал не получится.

412 Precondition Failed

Еще один код, сообщающий о том, что сервер отклонил запрос пользователя и не разрешает доступ к выбранному ресурсу. Проблемы возникают при неправильной настройке работы методов, отличающихся от GET и HEAD. 

413 Payload Too Large/Request Entity Too Large

Код 413 говорит нам, что запрос, который посылает клиент на сервер, слишком большой. Поэтому сервер отказывается его обрабатывать и разрывает соединение. Обычно это происходит при попытке загрузить на ресурс какой-то файл, превышающий ограничение, выставленное в настройках сервера. Соответственно, решается проблема изменением настроек сервера. 

414 URI Too Long

Чем-то этот код похож на предыдущий. Здесь тоже идет речь о превышение лимита. Только теперь это касается не запроса со стороны клиента, а длины URI. То есть ссылки. Выходит, что адрес, используемый клиентом, больше, чем тот, что может обработать сервер. Как-то так. 

Такая ошибка иногда выскакивает при попытке взломать ресурс. Сайт так реагирует на слишком частые попытки воспользоваться потенциальными дырами в безопасности.

415 Unsupported Media Type

Ошибка 415 возникает, когда клиент пытается загрузить на сервер данные в неподходящем формате. В таком случае сервер просто отказывается принимать посылаемые файлы и разрывает соединение. Как и в случае с 413. 

416 Range Not Satisfiable

Подобный ответ можно ожидать, если клиент запрашивает у сервера определенные данные, но эти данные на сервере не соответствуют запросу. То есть, грубо говоря, вы просите у сервера какой-то набор данных с заранее заданным размером, а в итоге оказывается, что размер этих данных меньше, чем объем, указанный в запросе. Серверу ничего не остается, кроме как послать вас, ведь он не обучен поведению в таких ситуациях.

417 Expectation Failed

Такая ошибка высвечивается, когда ожидания сервера не совпадают с данными в запросе клиента. Сведения об ожиданиях прописываются в заголовке Expect заранее. Так что можно ознакомиться с ними, чтобы выяснить, как решить названную проблему.

418 I’m a teapot

Код 418 можно увидеть, если сервер откажется варить кофе, потому что он чайник. Это первоапрельская шутка. Естественно, 418 не используется нигде всерьез и просто существует как дань памяти программистам-юмористам, придумавшим это в 1998 году.

У Google получился такой симпатичный чайник

421 Misdirected Request

Появляется когда запрос клиента переправляется на сервер, который не может дать на него адекватный ответ. Например, если запрос был отправлен на ресурс, который вообще не настроен обрабатывать запросы извне. 

Чтобы исправить проблему, можно попробовать переподключиться к ресурсу заново или попробовать другое соединение.

422 Unprocessable Entity

Код 422 говорит, что сервер вроде бы принял запрос, понял его, все хорошо, но из-за семантических ошибок корректно обработать не смог. Значит, где-то в запросе затаилась логическая ошибка, мешающая корректному взаимодействию клиента и сервера. Надо ее найти и исправить.

423 Locked

Обычно на этот код напарываются, когда запрашиваемый ресурс оказывается под защитой. Используемые клиентом методы блокируются на уровне сервера. Это делается, чтобы обезопасить данные, хранящиеся на защищенной странице. Без логина и пароля выудить информацию с такого сервера не получится.

424 Failed Dependency

424 сообщает о том, что для выполнения запроса со стороны клиента успешно должна завершиться еще одна или несколько параллельных операций. Если какая-то из них «провалится», то «помрет» все соединение сразу, и обработать запрос до конца не получится. Аналогичное происходит, если некорректно был обработан один из предыдущих запросов.

425 Too Early

Появляется в ответ на запрос, который может быть моментально запущен заново. Сервер не рискует и не берется за его обработку, чтобы не подставиться под так называемую «атаку повторного воспроизведения».

426 Upgrade Required

Тут нам прямо сообщают, что сервер не желает с нами общаться, пока мы не перейдем на более современный протокол. Наткнуться на такую ошибку очень тяжело, но в случае появления, скорее всего, будет достаточно установить браузер посвежее.

428 Precondition Required

428 выскакивает, если пользователь отправляет запрос на сервер, но получает некорректные или неактуальные данные. Так ресурс оповещает о необходимости внести в запрос информацию о предварительных условиях обработки данных. Только так он сможет гарантировать получение клиентом нужной информации.

429 Too Many Requests

Здесь все просто. Ошибка появляется, когда клиент отправляет на сервер слишком много запросов в короткий промежуток времени. Очень похоже на поведение взломщиков. По этой причине запрос моментально блокируется. 

431 Request Header Fields Too Large

Из названия понятно, что ошибка с кодом 431 появляется из-за того, что в запросе клиента используются слишком длинные заголовки (неважно, один или несколько из них). Исправляется это с помощью сокращения заголовков и повторной отправки запроса. В теле ошибки обычно отображается краткая информация о том, как пользователь может решить эту проблему самостоятельно.

444 No Response

Этот код вам вряд ли удастся увидеть. Он отображается в лог-файлах, чтобы подтвердить, что сервер никак не отреагировал на запрос пользователя и прервал соединение. 

449 Retry With

Код используется в расширениях компании Microsoft. Он сигнализирует о том, что запрос от клиента не может быть принят сервером. Причиной становятся неверно указанные параметры. Сама 449 ошибка говорит о необходимости скорректировать запрос и повторить его снова, подготовив к работе с сервером.

450 Blocked by Windows Parental Controls

450 код увидят дети, попавшие под действие системы «Родительский контроль» компании Microsoft. По сути, ошибка говорит о том, что с компьютера попытались зайти на заблокированный ресурс. Избежать этой ошибки можно изменением параметров родительского контроля.

451 Unavailable For Legal Reasons

Этот код сообщает клиенту, что он не может попасть на запрашиваемый ресурс из юридических соображений. Скорее всего, доступ был заблокирован из-за каких-нибудь государственных санкций, нового законодательства или цензуры со стороны властей. В общем, все вопросы к государству и провайдеру связи.

Список ошибок на стороне сервера (5xx)

Теперь поговорим об ошибках, которые возникают где-то на сервере. Все они связаны с запросами, которые не удается обработать на том конце. Пользователь зачастую в их появлении не виноват.

500 Internal Server Error

Этот код возникает, когда сервер сталкивается с непредвиденными обстоятельствами. Такими, которые и сам не может пояснить. Как, собственно, и завершить запрос со стороны пользователя. По факту, эта ошибка говорит нам что-то вроде «Я не могу подобрать более подходящий код ошибки, поэтому лови 500 и делай с этим, что хочешь». Мы писали о нем чуть подробнее тут.

Дело не в тебе, дело во мне (С)

501 Not Implemented

501 говорит нам, что функциональность, необходимая для обработки запроса со стороны клиента, попросту не реализована на сервере. Он не сможет корректно обработать используемый метод. 

Иногда в теле ошибки еще пишут что-то в духе «Приходите попозже, возможно, в будущем нужная функция появится».

502 Bad Getaway

Можно встретить в том случае, если запрашиваемый сервер выступает в роли шлюза или прокси. Возникает из-за несогласования протоколов между вышестоящим серверов и его шлюзом. Рассказываем о том, как ее исправить, в этой статье. 

503 Service Unavailable

Появляется, когда сервер не может обработать запрос клиента по одной из двух технических причин:

1. Слишком много пользователей в текущий момент пытаются отправить запросы, и у сервера не остается ресурсов, чтобы ответить кому-либо еще.
2. На сервере ведутся технические работы, временно блокирующие его работу.

Обычно ошибка 503 носит временный характер, и для ее решения достаточно немного подождать. 

504 Gateway Timeout

Ошибка похожа на 408. Здесь же прокси-сервер пытается выйти на контакт с вышестоящим сервером, но не успевает это сделать до истечения тайм-аута. Отсюда и ошибка.

505 HTTP Version Not Supported

Этот код похож на 426. Он тоже связан с неподходящей версией протокола HTTP. В этом случае нужно обеспечить и клиента, и сервер единой версией. Она, как правило, указывается в запросе со стороны пользователя. 

506 Variant Also Negotiates

Обычно с такой ошибкой сталкиваются только в том случае, если сервер изначально настроен неправильно. То есть это не сиюминутная проблема, а что-то серьезное на уровне базовой конфигурации. Тут придется потрудиться разработчикам. Выявить проблему и разрешить ее.

507 Insufficient Storage

Код 507 встречается в тех ситуациях, когда серверу не хватает пространства в хранилище для обработки запроса со стороны клиента. Проблема решается освобождением места или расширением доступного пространства. Тогда сервер сможет без проблем обработать запрос пользователя.

508 Loop Detected

Таким кодом сервер отзовется в случае, если заметит бесконечный цикл в запросе клиента. Можно расценивать его как провал запроса и выполняемой операции в целом.

509 Bandwidth Limit Exceeded

Возникает, если сервер начинает потреблять больше трафика, чем ему позволено. 

510 Not Extended

Появляется, если клиент посылает запрос на использование какого-либо расширения, отсутствующего на сервере. Чтобы исправить проблему, надо убрать декларирование неподдерживаемого расширения из запроса или добавить поддержку на сервер.

511 Network Authentication Required

511 код говорит о том, что перед тем как выйти в сеть, надо авторизоваться (ввести логин и пароль). Можно воспринимать это неким PPPoE подключением, когда от клиента требуются данные для авторизации.

Заключение

Закончили. Это все ошибки, которыми отзывается HTTP, если на стороне сервера или клиента что-то пошло не так. Наткнуться на большую их часть довольно тяжело. Особенно, если вы раньше только серфили в интернете, а не занимались разработкой сайтов. А тем, кто входит в эту стезю, полезно знать основные ошибки, так как, скорее всего, придется не раз их исправлять.