Error request failed with status code 499

When managing and maintaining a website, there are a handful of HTTP status codes to be aware of. Some, such as the HTTP 499 error, can cause a timeout that interrupts your workflow. Therefore, you’ll need to ensure that your site is configured properly to avoid this issue.

Whether you’re seeing the HTTP 499 status code frequently or for the first time, it may indicate an issue with your website that needs to be addressed. The good news is that there are multiple steps you can take to resolve it.

Check Out Our Video Guide to Fixing the 499 Error

In this post, we’ll explain the HTTP 499 status code and what can cause the error. Then we’ll walk you through five potential solutions you can use to fix it. Let’s get started!

What the HTTP 499 Status Code Means

The HTTP 499 status code, also known as a “client closed request,” is a special case of the 502 Bad Gateway Error. It indicates that the client has closed the connection while the server is still processing the request.

HTTP 499 falls within the category of client-based errors. This means the issue is on the client side. Other common errors in this category include HTTP 400 Bad Request and HTTP 404 Not Found. With these errors, the problems are usually easy to define. However, HTTP 499 is more general.

The HTTP 499 error can happen on both Nginx and Apache servers. However, it is more common on Nginx servers because it was created by Nginx.

HTTP 499 is more common on Nginx because the server software handles client connections differently than Apache. With Nginx, each client connection is processed in a separate thread. Therefore, if one client connection takes a long time to process, it won’t slow down the other clients.

However, with Apache, all client connections are processed in the same thread. This can cause problems if one client connection takes a long time to process because it will slow down all other clients.

The HTTP 499 error can cause a timeout that interrupts your workflow- but with a little help from this guide, you can get right back on track 👩‍💻Click to Tweet

What Causes the HTTP 499 Error

Typically, the HTTP 499 error appears in Nginx logs. This can happen for several reasons, but most commonly, it’s due to either a browser timing out or a user canceling the request.

For example, a website may encounter an HTTP code 499 when it’s loaded with too much traffic. Alternatively, the error can happen when the request comes from algorithms that create issues within the site.

In some cases, this status code may also display when there is no response from the server, and the client has timed out waiting for a response. In these cases, it’s usually best to just try again later. However, if you are consistently getting this status code from a particular server, it may be worth investigating further to see if there is an overarching issue.

How To Fix the HTTP 499 Error (5 Potential Solutions)

Now that we understand more about the HTTP 499 error, let’s look at how to resolve it. Below are five potential solutions for the HTTP 499 status code!

1. Clear Your Browser Cache and Try Again

As we mentioned earlier, this error may be a temporary issue that can be resolved by simply trying to load the page again. It might be that your host or server is overloaded. Therefore, we recommend clearing your browser cache and trying again.

The process for clearing the cache will vary depending on your browser. If you’re using Google Chrome, you can navigate to the three vertical dots in the upper right-hand corner of the window, then go to More tools > Clear browsing data:

You’ll then be prompted to choose which data to clear from your browser cache:

When you’re done, reload your browser. You can also try using a different browser in the meantime. Then revisit your site to see whether the error message is still showing.

2. Disable Your Plugins and Extensions

Some users have reported that certain plugins cause the HTTP 499 status code error. Therefore, we recommend temporarily disabling your plugins to see if this resolves the issue.

You can do this by navigating to your Plugins screen in the WordPress dashboard, selecting all of them, then clicking on Deactivate > Apply from the bulk actions menu:

You can also connect to your site via a File Transfer Protocol (FTP) client or File Manager, then navigate to your plugins folder (wp_content > plugins). Right-click on the plugins folder and rename it to something such as “plugins_old.”

This will deactivate all of the plugins on your WordPress site. You can revisit your website to see whether the error message is still showing. If not, you can try activating your plugins one by one until you find the tool causing the issue.

3. Check Your Error Logs

When troubleshooting the HTTP 499 code, it’s essential to leverage your error logs. This approach will make it easier to narrow down the issue and determine whether it results from a specific plugin or tool.

If you’re not a Kinsta user, you can enable and view error logs by turning on WordPress debugging mode. However, if you’re a Kinsta user, you can quickly and easily see errors in the Log viewer from your MyKinsta dashboard:

You can also check your log files in Nginx (/var/log/nginx.error.log) and Apache (/var/log/apache2/error.log). Furthermore, Kinsta users can take advantage of our analytics tool to take a closer look at errors on your site. Then you can understand how often they’re occurring and whether the HTTP 499 error is an ongoing issue.

4. Use an Application Performance Monitoring (APM) Tool

When managing a website, it’s important to have reliable solutions for identifying and troubleshooting errors on your site. We recommend using an Application Performance Monitoring (APM) tool.

APM tools can help you narrow down which script or plugin may lead to various errors, such as HTTP 499. We include our Kinsta APM, as well as a variety of other DevKinsta tools, with all of our plans:

For example, your APM tool can help you collect valuable data and determine which applications are causing delays. Once enabled, you can use KinstaAPM to view the slowest transactions on your site, trace their timelines, and figure out the causes of issues. Our APM also provides insight into your PHP processes, MySQL queries, external HTTP requests, and more.

5. Contact Your Web Host and Request a Timeout Increase

As we’ve discussed, sometimes HTTP 499 errors can occur when a request is canceled because it’s taking too long. Some hosting providers use a ”kill script”.

In short, a kill script forces a request to be terminated after a certain amount of time. This script is often used in shared hosting environments to prevent long requests from impacting other sites.

If you’re a Kinsta user, this isn’t something you need to worry about. Each site hosted on our platform runs on an isolated software container that includes all resources and software. Everything is completely private, and none of your resources are shared, so we don’t run kill scripts.

However, when it comes to the HTTP 499 error, it’s important to note that the “client” may be a proxy, such as a Content Delivery Network (CDN) or load balancer. A load balancing service can act as a client to the Nginx server and proxy data between your server and users. This can cause a timeout that cancels the request to the Nginx server.

PHP timeouts happen if a process runs longer than the maximum execution time (max_execution_time) or max_input_time specified in your server’s PHP configuration. You may encounter timeouts if you have a busy website or scripts that need longer execution times. Therefore, it might be necessary to extend your timeout value.

Let’s say you have a request that is expected to take 20 seconds to complete. If you have an application with a timeout value of 10 seconds, the application will probably time out before completing the request. You’ll likely see the HTTP 499 status code in such an instance.

Therefore, it’s wise to check with your host about the values set on your server. At Kinsta, the default max_execution_time and max_input_time values are set to 300 seconds (5 minutes). The maximum PHP timeout values vary depending on your plan.

If necessary, you can reach out to your hosting provider to request a timeout increase. As a Kinsta user, you can open a ticket with our support team.

With help from this guide, you can ensure your site is properly configured to avoid seeing this error in the future. ✅ Here’s how… 🚀Click to Tweet

Summary

There are a wide variety of HTTP status codes to be aware of as a website owner. Some of the trickiest are client-based errors, such as the HTTP 499 code. The good news is that you can take a handful of steps to resolve this issue.

In this post, we discussed five potential solutions you can use to fix the HTTP 499 status code error. All of them are viable options; if one doesn’t work, another one should.

Do you want to troubleshoot and resolve issues in WordPress as painlessly as possible? Check out Kinsta hosting plans to learn how our APM tool and other solutions can streamline your website maintenance and management!

How To Fix NGINX Timeout – 499 Client Closed Request

I recently stumbled on an interesting error coming from an nginx / php-fpm build. A long-running script I was trying to load kept seemingly “timing out” and leaving an empty white screen. There were no errors reported and I was a bit perplexed. I checked all the below:

PHP

• max_execution_time set to 0
• max_input_time set to -1
• memory_limit set to 4G

NGINX

• fastcgi_send_timeout 6000 seconds
• fastcgi_read_timeout 6000 seconds

Even stranger, the only note of the issue in the php / nginx logs was an entry in the nginx log with the HTTP status code 499 – “Client Closed Request.” Initially, I thought my browser was killing the connection after a certain amount of time, but that did not seem to be the case.

Amazon Elastic Load Balancers (AWS ELB)

I realized that this build was running behind an Elastic-Load-Balancer (“ELB”) on the Amazon AWS infrastructure. After poking around, I realized that by default the Load Balancer has an Idle Timeout of 60 seconds. This turned out to be the culprit. As a refresher, the Load Balancer acts as an intermediary between the Client (Browser) and the Server (Host). When the Client requests something from the Server, the Load Balancer opens a connection to both of them, and acts as a messenger for any requests. If the Server doesn’t return something by the Idle Timeout cutoff, the connections are automatically closed.

Since the Load Balancer closes the connection to the Server, NGINX thinks the Client terminated the request (since in this case the ELB *is* the Client).

Luckily the fix is easy, navigate to:

AWS Dashboard -> EC2 -> Load Balancers -> Attributes -> Edit idle timeout

From there, you can set the idle timeout higher.

Источник

HTTP 499 Client Closed Request: Solved

Understand the HTTP 499 Client Closed Request error: What are the causes and how to fix it.

Table of Contents

What is the 499 Client Closed Request error?

The 499 HTTP is a non-standard status code introduced by Nginx when a client, for instance a browser, closes the connection while Nginx is processing the request.

How to fix the 499 Client Closed Request error

There are various reasons why the client would not process the request and ended up with a 499 error code. In the following sections, we will help you identify the different causes and how to fix them in each case.

499 error when the website is behind a proxy

You may find 499 errors when you have a Load Balancing service between your users and your Nginx. A similar situation occurs when your Nginx site is served by a CDN or is behind a WAF (Web Application Firewall).

The 499 error happens when the front server attending your browser request is an Nginx server in reverse proxy mode, and it sends the request to your server site, but your site process exceeds the waiting time of the front server.

When the Nginx proxy Load Balancer timeouts waiting for the answer of your WordPress server

To fix this error, you can:

• Increase the processing capacity of your application server. By increasing the “processing power”, you will reduce the waiting time of the Nginx clients in front of your service.
• If you cannot increase the power of your application server, then increase the timeouts of your proxies (load balancer, CDN, firewall, …).

★ Zero-config: configuration files for all server services are transparently adjusted to the power.

The right way to set the timeouts

If there are proxies on your setup such as a “Load balancer”, a Firewall, a CDN, etc, you should set the timeouts so that you timeout first your application server and then the other proxies to the user.

User → CDN → Nginx Load Balancer → Nginx application → Php_fpm

It’s recommended to set the timeouts like this:

• n seconds to Php_fpm timeout.
  Set the php.ini max_execution_time and
  the request_terminate_timeout in your php_fpm config file.

• n+1 seconds to Nginx application timeout.
  Set the fastcgi_read_timeout in your nginx config.

• n+2 seconds to timeout to Nginx Load Balancer
  In your location doing the proxy_pass set the timeouts of:
  proxy_connect_timeout
  proxy_send_timeout
  proxy_read_timeout
• n+3 seconds of timeout for your CDN. NOTE: If you can’t set the timeouts of your CDN, then find what is its timeout and adjust the others according to it.

It provides a correct chain of timeouts: Setting an incremental chain of timeouts lets you find who is reaching the timeout.

499 when your server closed the connection

This could be your case, If:

1. your site is running with an Nginx server and,
2. the request is passed to an application processor e.g. php_fpm , or
3. the request is passed to your API

This setup is configured using the nginx fastcgi_pass directive.

This 499 error code is produced when your server is too slow.

e.g. your WordPress page process takes too long or freezes

To correct this error, you can:

• Increase the processing capacity of your server. By increasing “processing power”, you will reduce the period Nginx waits.
• If you cannot increase your server power, increase Nginx timeouts with the directive: fastcgi_read_timeout .

How to fix the 499 error when your application dies

If your application dies without an answer, the solution could be in your API or CGI code.

NOTE: This is the least common case, PHP and other processors always throw a note to notify a problem. If the app was throwing an error, Nginx would pass you a 5XX error code, not a 499.

If your application freezes, you have 2 options:

• First, tell the Nginx to wait longer. Increase the timeouts of your Nginx by modifying the fastcgi_read_timeout .
• If waiting longer does not solve the problem, increase the processing capacity of your server.
• If the 499 error occurs on a specific page or request, it could be a “hung” or “code freeze” in your application or content manager. If you use WordPress, check plugin compatibility. If database queries are made, check the good status of tables and indexes.

499 when your server is under a DOS or DDOS attack

There might be a case when someone attacks, and intentionally consumes the server resources. This makes the server unable to process the request and return the result on time.

To verify if this is your case: look at your analytics, and search for spikes in traffic with requests giving the 499 status code:

How to fix the 499 error when DOS/DDOS attacks:

In this case, the best solution is a combination of security measures:

• Prevention: avoid non-legit traffic. You can filter malicious traffic with a combination of public and private blacklists.
• Add infrastructure protection against DOS (Denial of Service) and DDOS (Distributed Denial of Service). Find a hosting provider with infrastructure ready to mitigate this kind of attack.
• Add a protection layer, a security proxy, in front of your server, or
• Add an external security service. A well-known one is Cloudflare. They put a distributed infrastructure in front of your server to fight against DDOS attacks.

We are techies passionate about WordPress. With wetopi, a Managed WordPress Hosting, we want to minimize the friction that every professional faces when working and hosting WordPress projects.

Not a wetopi user?

Free full performance servers for your development and test.
No credit card required.

Источник

NginX issues HTTP 499 error after 60 seconds despite config. (PHP and AWS)

Part of AWS Collective

At the end of last week I noticed a problem on one of my medium AWS instances where Nginx always returns a HTTP 499 response if a request takes more than 60 seconds. The page being requested is a PHP script

I’ve spent several days trying to find answers and have tried everything that I can find on the internet including several entries here on Stack Overflow, nothing works.

I’ve tried modifying the PHP settings, PHP-FPM settings and Nginx settings. You can see a question I raised on the NginX forums on Friday (http://forum.nginx.org/read.php?9,237692) though that has received no response so I am hoping that I might be able to find an answer here before I am forced to moved back to Apache which I know just works.

This is not the same problem as the HTTP 500 errors reported in other entries.

I’ve been able to replicate the problem with a fresh micro AWS instance of NginX using PHP 5.4.11.

To help anyone who wishes to see the problem in action I’m going to take you through the set-up I ran for the latest Micro test server.

You’ll need to launch a new AWS Micro instance (so it’s free) using the AMI ami-c1aaabb5

This PasteBin entry has the complete set-up to run to mirror my test environment. You’ll just need to change example.com within the NginX config at the end

Once that’s set-up you just need to create the sample PHP file which I am testing with which is

Save that into the webroot and then test. If you run the script from the command line using php or php-cgi, it will work. If you access the script via a webpage and tail the access log /var/log/nginx/example.access.log, you will notice that you receive the HTTP 1.1 499 response after 60 seconds.

Now that you can see the timeout, I’ll go through some of the config changes I’ve made to both PHP and NginX to try to get around this. For PHP I’ll create several config files so that they can be easily disabled

Update the PHP FPM Config to include external config files

Create a new PHP-FPM config to override the request timeout

Change some of the global settings to ensure the emergency restart interval is 2 minutes

Next, we will change some of the PHP.INI settings, again using separate files

As you can see, this is increasing the socket timeout to 3 minutes and will help log errors.

Finally, I’ll edit some of the NginX settings to increase the timeout’s that side

First I edit the file /etc/nginx/nginx.conf and add this to the http directive fastcgi_read_timeout 300;

Next, I edit the file /etc/nginx/sites-enabled/example which we created earlier (See the pastebin entry) and add the following settings into the server directive

Finally I add the following into the location

.php$ section of the server dir

Before retrying the script, start both nginx and php-fpm to ensure that the new settings have been picked up. I then try accessing the page and still receive the HTTP/1.1 499 entry within the NginX example.error.log.

So, where am I going wrong? This just works on apache when I set PHP’s max execution time to 2 minutes.

I can see that the PHP settings have been picked up by running phpinfo() from a web-accessible page. I just don’t get, I actually think that too much has been increased as it should just need PHP’s max_execution_time, default_socket_timeout changed as well as NginX’s fastcgi_read_timeout within just the server->location directive.

Update 1

Having performed some further test to show that the problem is not that the client is dying I have modified the test file to be

If I run the script from a web page then I can see the content of the file be set to the first string. 60 seconds later the error appears in the NginX log. 10 seconds later the contents of the file changes to the 2nd string, proving that PHP is completing the process.

Update 2

Setting fastcgi_ignore_client_abort on; does change the response from a HTTP 499 to a HTTP 200 though nothing is still returned to the end client.

Update 3

Having installed Apache and PHP (5.3.10) onto the box straight (using apt) and then increasing the execution time the problem does appear to also happen on Apache as well. The symptoms are the same as NginX now, a HTTP200 response but the actual client connection times out before hand.

I’ve also started to notice, in the NginX logs, that if I test using Firefox, it makes a double request (like this PHP script executes twice when longer than 60 seconds). Though that does appear to be the client requesting upon the script failing

Источник

HTTP Status 499 Error Code

There are numerous HTTP error codes out there, but let’s talk about the 499 error code. We can also refer to the 499 error code as HTTP code 499, or HTTP error 499. But whatever you call it, the 499 error code is something worth understanding. HTTP code 499 can happen anytime without you knowing, so let’s get started with getting to know HTTP error 499.

Eliminate errors and get Seamless Content Delivered

What is 499 Error Code?

The error 499 code was created by the minds behind NGINX, a high-performance web server. Being a prominent web server, NGINX created HTTP error 499 code to handle its specific error. For starters, HTTP error 499 part of a massive list of HTTP error codes, all pertaining to various requests done during online activity. Various entities connect to each other and request for certain data. HTTP error 499 basically means that the client, the request’s receiver, was not able to complete it. Compared to other error codes pertaining to forbidden requests or missing data, the 499 error code centers on errors pertaining to the client.

HTTP error 499 isn’t that specific. There are various reasons why the client wasn’t able to process the request, and ended up with a 499 error code. An example of an occurrence which led to HTTP Status 499 code is that the client got loaded up on data traffic, it had to shut down. For example, it’s highly possible that a content delivery network had to close the request because it is already loaded with other data-related concerns, like a high cache volume. HTTP error 499 happened because in the process of the request, the content delivery network had to attend to more internal problems, so as a client, it had to cancel the request.

Where does the 499 error code appear?

HTTP code 499 usually is seen in NGINX’s logs. Being a web server, NGINX 499 is able to identify that the problem is not in the server itself, or the entity which sent the request. HTTP error 499 simply means that the client shut off in the middle of processing the request through the server. The 499 error code puts better light that something happened with the client, that is why the request cannot be done. So don’t fret: HTTP response code 499 is not your fault at all.

What are other reasons why HTTP error 499 happened?

As established, HTTP code 499 is not the fault of the server or the requesting party, and maybe not even the fault of the client. HTTP code 499 can occur differently for various clients. It was established earlier that the client can be a website or an app, and these two experience errors differently. A website leading to HTTP code 499 may have been loaded with too much traffic, or the request was from faulty algorithms that created problems within the website. The HTTP error may also happen because of faulty programming. For example, some apps are cloud based, and the server will do the effort in reaching out to their cloud apps. However, there was a problem with the coding of the online app. HTTP error 499 appears because the app cannot process the request, due to faulty programming. This is another illustration of how the client, the online app, led to HTTP code 499.

More on Client Errors

HTTP code 499 is only one of many client-related error codes. In general, error codes are classified into five categories, labeled by the first number in their 3 digits. For codes 400-499, these are all client-based errors, meaning the server request cannot be completed at all because of problems on the side of the client. The most common of this group where HTTP error 499 belongs is the 404 error: File on Found. Unlike HTTP code 499, the 404 code is very straightforward and definite, whereas the 499 error code simply generalizes that the client cannot complete the request of the server.

If you are interested to know more about HTTP error 499 and other codes, it would be a good idea to study how server logs work and how you can make sense of the information stored in such logs. This will also give you more perspective in identifying specific clients, like apps and websites, that end up with HTTP code 499 the most, so that you can be more mindful of what apps and websites to visit. But in general, being familiar with the 499 error code and other codes will help you navigate the Web better.

Get rid of HTTP errors and Power up your Content Delivery

30 Day Free Trial Cancel Anytime

Источник

Understand the HTTP 499 Client Closed Request error: What are the causes and how to fix it.

Table of Contents

• What is the 499 Client Closed Request error?
• How to fix the 499 Client Closed Request error
  • 499 error when the website is behind a proxy
    • The right way to set the timeouts
  • 499 when your server closed the connection
    • How to fix the 499 error when your application dies
  • 499 when your server is under a DOS or DDOS attack
    • How to fix the 499 error when DOS/DDOS attacks:
• All HTTP Status Codes

What is the 499 Client Closed Request error?

The 499 HTTP is a non-standard status code introduced by Nginx when a client, for instance a browser, closes the connection while Nginx is processing the request.

How to fix the 499 Client Closed Request error

There are various reasons why the client would not process the request and ended up with a 499 error code. In the following sections, we will help you identify the different causes and how to fix them in each case.

499 error when the website is behind a proxy

You may find 499 errors when you have a Load Balancing service between your users and your Nginx. A similar situation occurs when your Nginx site is served by a CDN or is behind a WAF (Web Application Firewall).

The 499 error happens when the front server attending your browser request is an Nginx server in reverse proxy mode, and it sends the request to your server site, but your site process exceeds the waiting time of the front server.

To fix this error, you can:

• Increase the processing capacity of your application server. By increasing the “processing power”, you will reduce the waiting time of the Nginx clients in front of your service.
• If you cannot increase the power of your application server, then increase the timeouts of your proxies (load balancer, CDN, firewall, …).

At Wetopi you can increase the size of your server with a single click.

★ Zero-config: configuration files for all server services are transparently adjusted to the power.

The right way to set the timeouts

If there are proxies on your setup such as a “Load balancer”, a Firewall, a CDN, etc, you should set the timeouts so that you timeout first your application server and then the other proxies to the user.

Example:

User → CDN → Nginx Load Balancer → Nginx application → Php_fpm

It’s recommended to set the timeouts like this:

• n seconds to Php_fpm timeout.
  Set the php.ini max_execution_time and
  the request_terminate_timeout in your php_fpm config file.

• n+1 seconds to Nginx application timeout.
  Set the fastcgi_read_timeout in your nginx config.

• n+2 seconds to timeout to Nginx Load Balancer
  In your location doing the proxy_pass set the timeouts of:
  proxy_connect_timeout
proxy_send_timeout
proxy_read_timeout
• n+3 seconds of timeout for your CDN. NOTE: If you can’t set the timeouts of your CDN, then find what is its timeout and adjust the others according to it.

It provides a correct chain of timeouts: Setting an incremental chain of timeouts lets you find who is reaching the timeout.

499 when your server closed the connection

This could be your case, If:

1. your site is running with an Nginx server and,
2. the request is passed to an application processor e.g. php_fpm, or
3. the request is passed to your API

This setup is configured using the nginx fastcgi_pass directive.

This 499 error code is produced when your server is too slow.

e.g. your WordPress page process takes too long or freezes

To correct this error, you can:

• Increase the processing capacity of your server. By increasing “processing power”, you will reduce the period Nginx waits.
• If you cannot increase your server power, increase Nginx timeouts with the directive: fastcgi_read_timeout.

How to fix the 499 error when your application dies

• First, tell the Nginx to wait longer. Increase the timeouts of your Nginx by modifying the fastcgi_read_timeout.
• If waiting longer does not solve the problem, increase the processing capacity of your server.
• If the 499 error occurs on a specific page or request, it could be a “hung” or “code freeze” in your application or content manager. If you use WordPress, check plugin compatibility. If database queries are made, check the good status of tables and indexes.

499 when your server is under a DOS or DDOS attack

There might be a case when someone attacks, and intentionally consumes the server resources. This makes the server unable to process the request and return the result on time.

To verify if this is your case: look at your analytics, and search for spikes in traffic with requests giving the 499 status code:

How to fix the 499 error when DOS/DDOS attacks:

In this case, the best solution is a combination of security measures:

• Prevention: avoid non-legit traffic. You can filter malicious traffic with a combination of public and private blacklists.
• Add infrastructure protection against DOS (Denial of Service) and DDOS (Distributed Denial of Service). Find a hosting provider with infrastructure ready to mitigate this kind of attack.
• Add a protection layer, a security proxy, in front of your server, or
• Add an external security service. A well-known one is Cloudflare. They put a distributed infrastructure in front of your server to fight against DDOS attacks.

At Wetopi, as WordPress specialists, we know how important it is to add strong measures of security.
We apply three techniques to filter traffic:

Shared security heuristic learning,
Blacklisting from external sources and
Mitigation of DDoS attacks.

We are techies passionate about WordPress. With wetopi, a Managed WordPress Hosting, we want to minimize the friction that every professional faces when working and hosting WordPress projects.

Not a wetopi user?

Free full performance servers for your development and test.
No credit card required.

All HTTP Status Codes